My KDE week

Archive for September 2010

Nepomuk+strigi as desktop search

In the last weeks I – once again – got fed-up with strigi/nepomuk being of no use to me. Since KDE 4.0 I long for a desktop search, i.e. some way of finding files and getting a result list such as google etc. has it, i.e. including some context around the string found in the document and not just a file list. Anything else would just be a faster version of kfind for that task. And since I do not use tags, it is the only desktop search task for me.

So the first thing why it did not work for me was that strigi+nepomuk never finished to index my files because strigi 0.7.2 crashes while it indexes several filetypes such as email, flac or rpms.  Having a look at strigi’s website the project seemed dead. No news since 2008. This is a depressing first impression. Having a look at the SF project page continues with this, i.e. the latest available tarball is version 0.6.4 and the docs point to KDE’s playground svn repo if one wants to get strigi. The latter obviously fails because strigi is part of kdesupport.

Having a look at the bug tracker I found life though! And after I found out how to track down which file crashes strigi I could even provide some files to help fix the bugs – and fixed they were! Phreedom fixed one crash after the other so in the end I  had an almost working strigi which could index my files. Almost, because some symbol lookup error (symbol lookup error: /usr/lib64/ undefined symbol: ldap_int_tls_destroy) was still crashing strigi, yet this is not strigi’s fault (same bug at Red Hat) and one can work around it by removing /usr/lib64/strigi/ and

So if you find any crashes with strigi, use xmlindexer <folder or filename> or rdfindexer (both part of strigi) to track down which file causes it and report it at SF including the file – because strigi is alive and the devs are really nice people that fix bugs quickly if they are provided with testfiles! While reading along in #strigi I also gathered something about work on clucene and strigi to make it even faster. So it seems that the next releases of strigi et al. will result in some nice improvements for us users.

All crashes fixed and now I got a 1.4GB sized index with information about 130000 files in it, yet krunner and dolphin only return a file list which is as useful as if google only returned URLs in its results. If the search returns 20 OpenOffice documents and their filename does not tell me which of them is the document I am looking for, I would have to open all of them and use the OpenOffice find functionality to find the string within the document and check whether it is the paragraph I was looking for.

So I had a look at the nepomuk mailinglist in search for a search client to use and dolphin is apparently the best choice. And despite the fact that the term  “desktop search” (used for nepomuk+strigi in KDE’s systemsettings) has already been defined by other applications such as beagle or google, nepomuk+strigi+dolphin cannot display the search results with some context around the found string. For me this is the most basic functionality of a desktop search. Yet if I understood correctly nepomuk is more than that and has different and more ambitious aims. Thus this feature does not have a high priority.

IMHO it is absolutely understandable that nepomuk aims at something different and thus sets its priorities differently, especially because of the lack of developers involved in the project. Yet maybe providing these basic features would attract users and thus developers? And of course it would help a lot to gain some acceptance for all the CPU and disk space used by strigi+nepomuk. Without a wide acceptance nepomuk+strigi will stay turned off by a lot of distros by default.  Hence IMO nepomuk+strigi has a serious search client issue. There are some clients such as the crystal plasma applet within playground and indeed it does work and provides some context around the string found but only for a few files, i.e. it does not show any context for most of its results even though all of them are e.g. OO documents. And it has other issues as well, such as showing some bogus results. But it is a start and because it can be put into the panel it is very accessible for the users. It would be even more so if it would consist of a text-field rather than a click-able button to open a text-field.

I really would like to see a search client that enables nepomuk+strigi to be useful as a simple desktop search and gain acceptance from there. Start with the basics so to say. We will see what KDE SC 4.6 brings and since its their time and project it’s up to the devs to set their own pace and goals.

UPDATE: Sebastian Trüg just blogged about new features for dolphin’s search results view and guess what – there is some context shown! Great news! Now there only needs to be a text-field in the panel to e.g. start dolphin with the search terms entered. If things progress that nicely openSUSE 11.4 might even enable nepomuk+strigi by default.

Digikam 2

Since I was curious about the versioning and face recognition in the upcoming digikam 2.0 release, I compiled libkexiv2 and libkdcraw from trunk and got everything else needed from digikam2’s branch. Everything seems quite stable, i.e. I did not get any crashes yet despite the fact that there was not even a beta release yet. The latter is scheduled for October btw.

Neither versioning nor face detection are finished yet but the devs need feedback. So if you have some spare time, try those new features and report back to digikam’s devel mailinglist. From my point of view versioning already works quite well while face detection still needs some time until one can really test it. At least for me scanning the whole collection stalls after a few pictures and I cannot add names to the faces found, so it’s hard to test anything.

However, I think that those two and the other new features of digikam 2 will give that project yet another push to more popularity. Its development seems very lively to me and its great to see it improve from release to release. The only thing missing to make me completely happy is that one can keep tools opened when applying them to a picture. As in picasa doing so saves a lot of clicks if one e.g. goes through new pictures and wants to use cropping while maintaining the aspect ratio on some of them. This cannot be done with a batch tool since the user has to set the part of the image that should be cropped manually for every picture.

openSUSE 11.3 KDE (4.5.1) reloaded

Today openSUSE’s KDE reloaded LiveCD got published. It’s basically an installable  openSUSE 11.3 LiveCD with KDE 4.5.1 packages including all openSUSE patches and branding. The latter distinguishes it from KDE Four Live which is supposed to provide almost vanilla KDE packages.

The openSUSE 11.3 KDE reloaded LiveCD/USB is available for x86 and x86_64 from here. openSUSE users can install and run the package imagewriter to get a dead easy to use GUI to put the ISO image on an USB stick. If you want to provide feedback you can contact javier_ or alin in the #opensuse-kde IRC channel on freenode.

KDEPIM 4.4 translations for KDE SC 4.5

Since there is no KDEPIM 4.5 in KDE SC 4.5 yet, there are no translations either. Users updating to KDE SC 4.5 asked for translations for their KDEPIM 4.4 used with KDE SC 4.5 and thus KDE:Release:45 as well as KDE:Distro:Factory now contain translation packages for KDE SC 4.5 which have the KDEPIM transalations from KDE SC 4.4.

Desktop effects

Another note for others with intel graphics chipset using KDE trunk. I (945GME) had to disable functionality checks to get any desktop effects at all. According to other users this is also true for the 965GM and probably others . I think this is a known issue and caused by the buggy intel drivers. The problem with this is that I can enable the blur effect yet it only paints all plasma widget’s background in a dark grey rather than blurring it. So one has to disable blurring manually to get some semi-transparent blurring from the widget theme. I guess that disabling the functionality checks does also disable the blacklisting of the intel chipsets regarding the blurring effect.