Unfortunately I’m once again fighting virtuoso-t eating CPU although the file indexer is idle and the dbus interface does not show any active queries – but that’s nothing a quick and dirty removal of all of nepomuk’s data can’t “solve”. I know, it’s not a nice solution but it worked for me in the past. I’m still trying to start using nepomuk+strigi with each release – e.g. hoping for some useful (e.g. google-like) search results that display more than a filepath when searching for a string.

Regarding openSUSE packages, you can check the build status in order to make sure all packages you have installed are available for an update. If the repo is rebuilding enable the “Last time results” checkbox at the top-right of that page to see whether the package did succeed before and was published. After that it’s as simple as (for openSUSe 12.1):

sudo zypper ar http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_12.1/ KR48
sudo zypper mr -r KR48
sudo zypper dup --from KR48

Make sure you do not add any Qt repos since the required Qt packages are included. Disable the UpdatedApps repo! You can read more about the KDE repos available for openSUSE on the wiki and drop-by on the openSUSE KDE IRC channel #opensuse-kde or the forums in case you need help.

So what you can do is query virtuoso’s status. On openSUSE it works like this: first find the .ini file currently in usage to get the port virtuoso is using, connect to virtuoso and finally query virtuoso for its status and running statements. The latter are unfortunately truncated so I would appreciate some hint on how to get around that.

ps aux | grep virtuoso

finds /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_T18122.ini +wait

cat /tmp/virtuoso_T18122.ini | grep Port

finds ServerPort=1111

isql-vt -H localhost -S 1111 -U dba -P dba

which connects to virtuoso

status('rhck');

which shows you some info and which queries are keeping the process busy. isql-vt is part of the virtuoso-server package but it might be that only recent packages have it compiled and older packages lack the tools.

trace_on ('client_sql');

will start logging every command send to virtuoso from the nepomuk service into the virtuoso.log file which should be next to your virtuoso.db, e.g. ~/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/. Use trace_off(); to stop logging. See the virtuoso manual for more options.

Further you can do the following:

• open kdebugdialog and search for nepomuk
• use the quick-search to enable debug output for nepomuk
• on a konsole do:  qdbus org.kde.NepomukServer /nepomukserver quit
• wait until nepomuk and virtuoso are gone
• restart it from the konsole: nepomukserver

UPDATE: There is yet another possibility to debug virtuoso-t, i.e. find out the currently active query. On a konsole issue the following commands:

• qdbus org.kde.nepomuk.services.nepomukqueryservice
• You will see something like /nepomukqueryservice/query64 if the query does not finish within a reasonable amount of time you can get the query string
• qdbus org.kde.nepomuk.services.nepomukqueryservice /nepomukqueryservice/query64 queryString should then give you the query.

If you have any other hints regarding this piece of software feel free to mention them and I will add them to the post.

If your camera supports shooting pictures in RAW format you might want to try that feature. However for those that are not into the details of (RAW) image processing the result is quite disappointing if you use digikam and its defaults. Pictures are too dark and colours dull. If you want to pull beginners into RAW image usage you have to either push them to read some documentation in order to get satisfying results or pull the user by providing defaults that lead to motivating results and support/feed the user’s curiosity which in return will make him search and read further information without any pushing.

RAW picture with default settings and Highlights set to "rebuild"

The beauty of RAW images is that you can do a lot of things and fine-tuning until the image fits your expectations, yet beginners’ expectation is simply to get a picture that looks the same or better than the JPG preview they see in digikam. Thus defaults should provide exactly that as a starting point for further processing.

Other RAW image processing apps like darktable do this by e.g. providing base curves for your camera that put some vibrancy and colour into the dark and dull RAW data and hence motivate the user to get deeper into the possibilities of RAW image processing. Digikam currently does not provide that feature.

Using the luminosity curve

However, with a little work one can get there. If you set digikam to open the demosaicing tool for RAW images (settings > RAW decoding > Always open the RAW Import Tool to customise settings) opening a RAW image in the editor will show you the tool in the sidebar. First thing to notice: if you set White balance > Highlights to anything but “solid white” the picture will become even darker. Not sure why this does not happen with e.g. darktable since it does also handle highlights. But I think this is also the reason why in digikam the luminosity curve has to be pushed a lot further than in darktable. I set Highlights to “rebuild” in digikam.

Now you have to move to the post processing tab. There is more than one way to get to a satisfying result and you can even combine them. You can lighten-up the picture with setting gamma to e.g. 1.4 and then play with saturation and the other settings.

Another and my preferred way is to use the luminosity curve. To start with you can try to arrange it in a way that the RAW image looks like the JPG preview. To do so you have to adjust the luminosity curve which maps the input colours to the x-axis and the output colours to the y-axis. Hence moving the curve above the linear level will brighten-up the respective colour area. If you install an app that uses base curves such as darktable you can try to mimic the curve it uses for your camera. Having the picture you are processing digikam’s album view you can quickly change between those two windows by pressing ALT+TAB and compare the pictures without having to save all the time.

RAW picture with Highlights set to "rebuild" and luminosity curve applied

Some hints regarding the handling of the curve. Moving the points can become quite tricky if they are close. So if it happens that clicking on a point to move it makes digikam move the one left to it instead, try clicking a bit to the right of the point you actually want to move. In case you want to start all over again click on the tiny icon at the origin of the curve.

You will have to test your curve on different pictures since the colour spectrum is different and your curve should fit all pictures equally well. To save a curve you have to import the picture. Obviously there is not the one curve that is perfect for everybody – not even a curve that is perfect for all one’s pictures. So there should actually be two luminosity curves in the processing. One base curve that fits as default for one’s camera and one does not fiddle with all the time. And then a second luminosity curve which one can fiddle with per picture to make slight adaptations without changing the base curve.

Saving and sharing luminosity curves

Since digikam cannot save several curves and only keeps one, you have to work around that issue. What I do is to simply copy ~/.kde4/share/config/digikamrc to a sub-folder and keep versions of the curve for different cameras. If you have a look at [RAW Import Settings] within that file you will see the curve’s settings which you can copy and paste in order to share/import it. If digikam does one day implement a feature to save/load curves and maybe even suggesting one depending on the camera manufacturer, it will need some working curves to offer – so if you have a working luminosity curve please share it and post it into the bug report that describes the feature. Don’t forget to add your camera model to the post.

The sad news is that all of this does not work with the batch queue manager since there is no possibility to set any post processing values for the automatic handling. This would be another place where it would come in handy if one could save/load curves.

So here are the settings for a Panasonic LX3 (keep in mind to set Highlights to Rebuild otherwise the curve makes the image too bright):

RawCurveChannel0Point0=0,0
RawCurveChannel0Point1=1791,4438
RawCurveChannel0Point10=-1,-1
RawCurveChannel0Point11=43263,61781
RawCurveChannel0Point12=-1,-1
RawCurveChannel0Point13=51455,63829
RawCurveChannel0Point14=-1,-1
RawCurveChannel0Point15=60159,64853
RawCurveChannel0Point16=65535,65535
RawCurveChannel0Point17=-1,-1
RawCurveChannel0Point2=6399,14337
RawCurveChannel0Point3=10495,22870
RawCurveChannel0Point4=15103,31403
RawCurveChannel0Point5=19455,40960
RawCurveChannel0Point6=24575,48128
RawCurveChannel0Point7=28671,52906
RawCurveChannel0Point8=-1,-1
RawCurveChannel0Point9=35839,58368
RawCurveChannel0Type=0
RawCurveChannel1Point0=0,0
RawCurveChannel1Point1=-1,-1
RawCurveChannel1Point10=-1,-1
RawCurveChannel1Point11=-1,-1
RawCurveChannel1Point12=-1,-1
RawCurveChannel1Point13=-1,-1
RawCurveChannel1Point14=-1,-1
RawCurveChannel1Point15=-1,-1
RawCurveChannel1Point16=65535,65535
RawCurveChannel1Point17=-1,-1
RawCurveChannel1Point2=-1,-1
RawCurveChannel1Point3=-1,-1
RawCurveChannel1Point4=-1,-1
RawCurveChannel1Point5=-1,-1
RawCurveChannel1Point6=-1,-1
RawCurveChannel1Point7=-1,-1
RawCurveChannel1Point8=-1,-1
RawCurveChannel1Point9=-1,-1
RawCurveChannel1Type=0
RawCurveChannel2Point0=0,0
RawCurveChannel2Point1=-1,-1
RawCurveChannel2Point10=-1,-1
RawCurveChannel2Point11=-1,-1
RawCurveChannel2Point12=-1,-1
RawCurveChannel2Point13=-1,-1
RawCurveChannel2Point14=-1,-1
RawCurveChannel2Point15=-1,-1
RawCurveChannel2Point16=65535,65535
RawCurveChannel2Point17=-1,-1
RawCurveChannel2Point2=-1,-1
RawCurveChannel2Point3=-1,-1
RawCurveChannel2Point4=-1,-1
RawCurveChannel2Point5=-1,-1
RawCurveChannel2Point6=-1,-1
RawCurveChannel2Point7=-1,-1
RawCurveChannel2Point8=-1,-1
RawCurveChannel2Point9=-1,-1
RawCurveChannel2Type=0
RawCurveChannel3Point0=0,0
RawCurveChannel3Point1=-1,-1
RawCurveChannel3Point10=-1,-1
RawCurveChannel3Point11=-1,-1
RawCurveChannel3Point12=-1,-1
RawCurveChannel3Point13=-1,-1
RawCurveChannel3Point14=-1,-1
RawCurveChannel3Point15=-1,-1
RawCurveChannel3Point16=65535,65535
RawCurveChannel3Point17=-1,-1
RawCurveChannel3Point2=-1,-1
RawCurveChannel3Point3=-1,-1
RawCurveChannel3Point4=-1,-1
RawCurveChannel3Point5=-1,-1
RawCurveChannel3Point6=-1,-1
RawCurveChannel3Point7=-1,-1
RawCurveChannel3Point8=-1,-1
RawCurveChannel3Point9=-1,-1
RawCurveChannel3Type=0
RawCurveChannel4Point0=0,0
RawCurveChannel4Point1=-1,-1
RawCurveChannel4Point10=-1,-1
RawCurveChannel4Point11=-1,-1
RawCurveChannel4Point12=-1,-1
RawCurveChannel4Point13=-1,-1
RawCurveChannel4Point14=-1,-1
RawCurveChannel4Point15=-1,-1
RawCurveChannel4Point16=65535,65535
RawCurveChannel4Point17=-1,-1
RawCurveChannel4Point2=-1,-1
RawCurveChannel4Point3=-1,-1
RawCurveChannel4Point4=-1,-1
RawCurveChannel4Point5=-1,-1
RawCurveChannel4Point6=-1,-1
RawCurveChannel4Point7=-1,-1
RawCurveChannel4Point8=-1,-1
RawCurveChannel4Point9=-1,-1
RawCurveChannel4Type=0

and a Nikon D90. Since I do not have that many pictures off a D90 this curve is not as tested as the one for the LX3.

RawCurveChannel0Point0=0,0
RawCurveChannel0Point1=2303,5462
RawCurveChannel0Point10=-1,-1
RawCurveChannel0Point11=-1,-1
RawCurveChannel0Point12=49663,62805
RawCurveChannel0Point13=-1,-1
RawCurveChannel0Point14=-1,-1
RawCurveChannel0Point15=-1,-1
RawCurveChannel0Point16=65535,65535
RawCurveChannel0Point17=-1,-1
RawCurveChannel0Point2=8703,16384
RawCurveChannel0Point3=-1,-1
RawCurveChannel0Point4=16895,32768
RawCurveChannel0Point5=-1,-1
RawCurveChannel0Point6=-1,-1
RawCurveChannel0Point7=29183,49834
RawCurveChannel0Point8=-1,-1
RawCurveChannel0Point9=-1,-1
RawCurveChannel0Type=0
RawCurveChannel1Point0=0,0
RawCurveChannel1Point1=-1,-1
RawCurveChannel1Point10=-1,-1
RawCurveChannel1Point11=-1,-1
RawCurveChannel1Point12=-1,-1
RawCurveChannel1Point13=-1,-1
RawCurveChannel1Point14=-1,-1
RawCurveChannel1Point15=-1,-1
RawCurveChannel1Point16=65535,65535
RawCurveChannel1Point17=-1,-1
RawCurveChannel1Point2=-1,-1
RawCurveChannel1Point3=-1,-1
RawCurveChannel1Point4=-1,-1
RawCurveChannel1Point5=-1,-1
RawCurveChannel1Point6=-1,-1
RawCurveChannel1Point7=-1,-1
RawCurveChannel1Point8=-1,-1
RawCurveChannel1Point9=-1,-1
RawCurveChannel1Type=0
RawCurveChannel2Point0=0,0
RawCurveChannel2Point1=-1,-1
RawCurveChannel2Point10=-1,-1
RawCurveChannel2Point11=-1,-1
RawCurveChannel2Point12=-1,-1
RawCurveChannel2Point13=-1,-1
RawCurveChannel2Point14=-1,-1
RawCurveChannel2Point15=-1,-1
RawCurveChannel2Point16=65535,65535
RawCurveChannel2Point17=-1,-1
RawCurveChannel2Point2=-1,-1
RawCurveChannel2Point3=-1,-1
RawCurveChannel2Point4=-1,-1
RawCurveChannel2Point5=-1,-1
RawCurveChannel2Point6=-1,-1
RawCurveChannel2Point7=-1,-1
RawCurveChannel2Point8=-1,-1
RawCurveChannel2Point9=-1,-1
RawCurveChannel2Type=0
RawCurveChannel3Point0=0,0
RawCurveChannel3Point1=-1,-1
RawCurveChannel3Point10=-1,-1
RawCurveChannel3Point11=-1,-1
RawCurveChannel3Point12=-1,-1
RawCurveChannel3Point13=-1,-1
RawCurveChannel3Point14=-1,-1
RawCurveChannel3Point15=-1,-1
RawCurveChannel3Point16=65535,65535
RawCurveChannel3Point17=-1,-1
RawCurveChannel3Point2=-1,-1
RawCurveChannel3Point3=-1,-1
RawCurveChannel3Point4=-1,-1
RawCurveChannel3Point5=-1,-1
RawCurveChannel3Point6=-1,-1
RawCurveChannel3Point7=-1,-1
RawCurveChannel3Point8=-1,-1
RawCurveChannel3Point9=-1,-1
RawCurveChannel3Type=0
RawCurveChannel4Point0=0,0
RawCurveChannel4Point1=-1,-1
RawCurveChannel4Point10=-1,-1
RawCurveChannel4Point11=-1,-1
RawCurveChannel4Point12=-1,-1
RawCurveChannel4Point13=-1,-1
RawCurveChannel4Point14=-1,-1
RawCurveChannel4Point15=-1,-1
RawCurveChannel4Point16=65535,65535
RawCurveChannel4Point17=-1,-1
RawCurveChannel4Point2=-1,-1
RawCurveChannel4Point3=-1,-1
RawCurveChannel4Point4=-1,-1
RawCurveChannel4Point5=-1,-1
RawCurveChannel4Point6=-1,-1
RawCurveChannel4Point7=-1,-1
RawCurveChannel4Point8=-1,-1
RawCurveChannel4Point9=-1,-1
RawCurveChannel4Type=0

One thing that I am not yet satisfied with is that the LX3 curve has too much green in it – but unfortunately I am unable to get it less green without either the whole picture getting too dark or yellow- and red-ish colours not being as vibrant as I want them. So if you have any hints on how to achieve that I would appreciate it. Maybe this is because digikam darkens the image when rebuilding highlights which forces the user to use a more extreme luminosity curve in order to compensate the darkness – which in other apps one does not have to do.

UPDATE: I tried with Highlights set to “solid white” and get a lot better results (oddly especially in highlight areas but also regarding details in non-highlight areas) with a curve that does not need to compensate the darkness added by “rebuild”. So for a LX3 you might want to try to set saturation to 1.09 in the post processing tab and paste the following curve into your digikamrc:

RawCurveChannel0Point0=0,0
RawCurveChannel0Point1=3327,4780
RawCurveChannel0Point10=-1,-1
RawCurveChannel0Point11=-1,-1
RawCurveChannel0Point12=49151,57344
RawCurveChannel0Point13=-1,-1
RawCurveChannel0Point14=-1,-1
RawCurveChannel0Point15=-1,-1
RawCurveChannel0Point16=65535,65535
RawCurveChannel0Point17=-1,-1
RawCurveChannel0Point2=-1,-1
RawCurveChannel0Point3=11775,15702
RawCurveChannel0Point4=17407,23552
RawCurveChannel0Point5=-1,-1
RawCurveChannel0Point6=23039,31403
RawCurveChannel0Point7=-1,-1
RawCurveChannel0Point8=33023,44373
RawCurveChannel0Point9=-1,-1
RawCurveChannel0Type=0
RawCurveChannel1Point0=0,0
RawCurveChannel1Point1=-1,-1
RawCurveChannel1Point10=-1,-1
RawCurveChannel1Point11=-1,-1
RawCurveChannel1Point12=-1,-1
RawCurveChannel1Point13=-1,-1
RawCurveChannel1Point14=-1,-1
RawCurveChannel1Point15=-1,-1
RawCurveChannel1Point16=65535,65535
RawCurveChannel1Point17=-1,-1
RawCurveChannel1Point2=-1,-1
RawCurveChannel1Point3=-1,-1
RawCurveChannel1Point4=-1,-1
RawCurveChannel1Point5=-1,-1
RawCurveChannel1Point6=-1,-1
RawCurveChannel1Point7=-1,-1
RawCurveChannel1Point8=-1,-1
RawCurveChannel1Point9=-1,-1
RawCurveChannel1Type=0
RawCurveChannel2Point0=0,0
RawCurveChannel2Point1=-1,-1
RawCurveChannel2Point10=-1,-1
RawCurveChannel2Point11=-1,-1
RawCurveChannel2Point12=-1,-1
RawCurveChannel2Point13=-1,-1
RawCurveChannel2Point14=-1,-1
RawCurveChannel2Point15=-1,-1
RawCurveChannel2Point16=65535,65535
RawCurveChannel2Point17=-1,-1
RawCurveChannel2Point2=-1,-1
RawCurveChannel2Point3=-1,-1
RawCurveChannel2Point4=-1,-1
RawCurveChannel2Point5=-1,-1
RawCurveChannel2Point6=-1,-1
RawCurveChannel2Point7=-1,-1
RawCurveChannel2Point8=-1,-1
RawCurveChannel2Point9=-1,-1
RawCurveChannel2Type=0
RawCurveChannel3Point0=0,0
RawCurveChannel3Point1=-1,-1
RawCurveChannel3Point10=-1,-1
RawCurveChannel3Point11=-1,-1
RawCurveChannel3Point12=-1,-1
RawCurveChannel3Point13=-1,-1
RawCurveChannel3Point14=-1,-1
RawCurveChannel3Point15=-1,-1
RawCurveChannel3Point16=65535,65535
RawCurveChannel3Point17=-1,-1
RawCurveChannel3Point2=-1,-1
RawCurveChannel3Point3=-1,-1
RawCurveChannel3Point4=-1,-1
RawCurveChannel3Point5=-1,-1
RawCurveChannel3Point6=-1,-1
RawCurveChannel3Point7=-1,-1
RawCurveChannel3Point8=-1,-1
RawCurveChannel3Point9=-1,-1
RawCurveChannel3Type=0
RawCurveChannel4Point0=0,0
RawCurveChannel4Point1=-1,-1
RawCurveChannel4Point10=-1,-1
RawCurveChannel4Point11=-1,-1
RawCurveChannel4Point12=-1,-1
RawCurveChannel4Point13=-1,-1
RawCurveChannel4Point14=-1,-1
RawCurveChannel4Point15=-1,-1
RawCurveChannel4Point16=65535,65535
RawCurveChannel4Point17=-1,-1
RawCurveChannel4Point2=-1,-1
RawCurveChannel4Point3=-1,-1
RawCurveChannel4Point4=-1,-1
RawCurveChannel4Point5=-1,-1
RawCurveChannel4Point6=-1,-1
RawCurveChannel4Point7=-1,-1
RawCurveChannel4Point8=-1,-1
RawCurveChannel4Point9=-1,-1
RawCurveChannel4Type=0
Saturation=1.09

RAW picture with Highlights set to "solid white" and the above luminosity curve applied plus saturation set to 1.09

If it comes to decisions there is always the aim to just do the right thing. In a lot of cases there is the one right thing. In quite a few cases there is no right thing but the consequences are small enough that it does not really matter which decision one takes. And then there are those use-cases where the only right thing to do is to ask the user because any other decision would just be guessing and lead to RAM and CPU wasting.

Yet even in the latter situations some apps are too lazy to ask the user or even claim that not asking the user – not even once – is the best solution – and even more astonishing: for the user’s good. So basically they claim to be smarter than the user or just do not care about the user’s resources or opinion.

Akonadi

In case akonadi is not running when the user starts kmail (and this example is only about that use-case) it asks the user whether it should start the service. That’s good! Tell the user that some needed service is missing and offer the means to start it. Give the user a choice instead of hiding processes. The user might have lost three seconds but he gained knowledge about a service that will consume a considerable amount of RAM and CPU-power. It’s not some small plasma or kded service!

Now if the user quits kmail akonadi will not quit automatically. Why not? Because it does not know whether it is still needed by other apps. As a result it consumes bandwith, RAM and CPU although it is not needed anymore. That’s bad! The fact that akonadi is not stopped when not needed anymore is another aspect where akonadi differs from some small plasma service that is started automatically (hidden) if the user adds the related widget. It is different because the latter also stops the service as automatically and hidden as it started it when the user removes it – thus there is no need to bother the user.

So why not simply ask the user in case of akonadi? Kmail asked the user whether to start the service, so why does it not ask whether it should stop it? If the user would want akonadi to run all the time he would autostart it with the session, would he not? And if kmail can ask the user to start akonadi why can those applications that still need it not do the same? What is wasting more resources and annoying a) to have akonadi in memory just in case there is some other app using it or b) let the user take a decision which takes two seconds? Worst case scenario would be that the application that needs akonadi tells the user to start it, as kmail did in the first place. Remember – if the user would want akonadi to run all the time he could start it as part of the session or click once on some “never quit akonadi” button.

Another approach would be to let kmail ask akonadi whether there are other applications using it. Either applications using it have to register with akonadi or respond to a “who needs me?” query by akonadi. That way the user could get a list of applications using akonadi and decide whether he wants to keep it in memory or not. He knows, the application just guesses or assumes. And it should only be the user that decides when it comes to a “do always”-kind of question. He might as well decide to “always quit akonadi when kmail quits” or “never quit akonadi when kmail quits” or “akonadi should quit as soon as there is no app answering to a ‘who needs me’ query”.

What makes it worse not to ask and just assume that staying in memory is ok is that there is no easy way to stop akonadi. There is no systray icon indicating its status and allowing interaction. There is no start/stop in systemsettings’ PIM module (as there is for e.g. nepomuk). There is no entry in systemsettings’ start/stop module. So even if the user knows about these systemsettings modules he cannot stop akonadi.

IMHO stopping something should be as easy and automatic as starting it. If that’s not the case it is an usability fail.  I know that there is akonadictl but that is out of reach for most users and just underlines that stopping is not on the same level of ease as starting. The latter implies that once started the app thinks it is better not to be stopped again.

Lancelot

An even worse example is Lancelot. Adding a plasma widget starts an application without even asking or at least notifying the user. This would be kind of ok, if that application would be stopped as easy and automatically as it was started, as plasmoids can do, yet it is not!

Removing the widget lets lancelot stay in memory just in case there are other apps using it. According to the developer asking the user is out of question because it would involve user-interaction. So in the end you add a widget and remove it and yet have some useless app left wasting megabytes of memory, CPU-time and querying e.g. akonadi. There is no way to stop it via systemsettings. Yet the latter would not help anyway since the user does not even know that some memory/CPU wasting app was started without his knowledge int he first place.

Again wasting resources just in case there might be some app that needs the service is seen as the best way instead of simply asking the user. In times of suspending instead of rebooting and mobile devices this means that lancelot will happily waste your memory and CPU-time for ages although it is not needed at all. Simply because a three second user-interaction is considered bad by the developer. What makes people think that wasting their resources is less annoying to them than interacting with them once in a while?

And of course you are right to claim that nobody forces people to use e.g. Lancelot. Absolutely true! But that is just another reason to not pest those users with your application until they restart their session. They think they stopped everything as explicitly  by removing the widget as they allegedly started it explicitly by adding the widget. Did we not all make fun of MS Windows because you had to restart it for all kinds of changes and when removing software?

So IMHO: If an application is not smart enough to know what the right thing to do is and whether it might waste RAM and CPU just for the sake of not interacting with the user – not even once: please ask the only expert regarding what the user wants – the user. Don’t try to be smarter than the user if the alternative is as easy as a single user-interaction. At an absolute minimum provide the user with the graphical means to stop whatever you thought necessary to start automatically but not stop automatically, e.g. via systemsettings as nepomuk does.

UPDATE: Since I seem to not have got that point across very well: I would also like to avoid questioning the user but that needs the service to behave as it was mentioned in some comments by others. As long as it does not do that, I prefer to decide what should be done with services that are not needed by any clients.

UPDATE 2: Since some people could not help themselves but simply claim that my figures on akonadi/kdepim’s memory consumption were wrong and would not even hint towards real memory consumption getting out of bounds, I’d like to point out that using /proc/PID/smaps one can measure the private dirty memory consumption of a process. In KDE’s system monitor you can reight-click a process and pick “detailed memory information” to get that info. So bottom line is, unfortunately my figures were real, are reproduceable on my system and reported to the devs. So for people like Nathan – please don’t get too defensive and aggressive next time – just in case you are wrong. And please do not start claiming that even smaps and private dirty memory consumption is not “real”.

Those updating from KDE 4.4 which came with openSUSE 11.3 to 4.6 – please save your plasma* files from ~/.kde4/share/config in case plasma crashes after the update. Submitting them to Novell’s bugzilla would be much appreciated in order to get those crashes fixed for openSUSE 11.4. The same applies to all other issues that come up when updating KDE 4.4 to 4.6, e.g. kdepim-related.

KDE SC 4.6

KDE 4.6 has some nice fixes, among them bko bug 163707 which prevented KDE from restoring the resolution set in systemsettings on login. This is especially important to openSUSE users since sax2 is gone and display settings moved into the desktop environment. Plasma seems to become more stable with every release – in fact I did not have any major issues with it since ages and bug fixing is pretty fast as well. Dolphin does also not suffer from buggy dbus packages anymore and with the latest strigi packages I do not encounter any crashes on close or when hovering certain files which did crash dolphin before. Thanks to remur_030 who helped the strigi people tracking the latter down for .msi files and thereby found and fixed some general issue in strigi which could cause crashes.

Desktop search

The desktop search does still not justify its name though since basics are still missing, e.g. context given for search results as all other desktop searches do and kerry + beagle already did years ago. The feature was shown some months ago but is not as such available in KDE 4.6 – thus even in KDE 4.6 all the user gets is a replacement of kfind + tagging which needs a huge database for that simple task.

On top of that there are still issues with virtuoso-t hogging the CPU, its database never decreasing in size but only increasing, even if you remove folders from the “to be indexed”-list and the systray-tool used to suspend the indexing vanished as well decreasing transparency to the user of an app which potentially keeps your hard disk and CPU busy.

Yes, I know there is always a shortage of manpower but IMHO if an app fails to provide the very basic features regarding the functionality its name advertises, it will not gain any acceptance among users and since every xth user is also a developer it will not attract developers either. Thus the extent of this manpower shortage is self-imposed in case of nepomuk aka desktop search.

I think its a bit unfortunate that strigi is always blamed for anything related to the desktop search in KDE although it is just the tool that is used by nepomuk and its usage is up to nepomuk and not strigi itself, i.e. when to start hammering the hard disk, how to handle the results within a database, what results to display when searching, giving the user control and information regarding its activities etc. From my experience strigi devs are quite responsive regarding bugs and questions – although their websites are all pretty much outdated.

Power-management

Power-management got worse in KDE 4.6, regressions such as not disabling powermanagement on desktops and thus suspending the display every 10 minutes, the brigtness slider not representing 100% of the brightness supported by the notebook and it still messes with the brightness the user has set. All these were reported some weeks ago already. Let’s hope that KDE SC 4.6.1 fixes those since that seems to be the version that openSUSE 11.4 will ship.

Further having a presentation-scheme (no suspend, no dimming etc.) is kind of useless with KDE 4.6 since it will change to the next scheme if the battery hits any limit. Thus you have to permanently watch the status and switch back to the presentation-scheme to be save of a suspending notebook while you watch a movie within the presentation or during some longer discussion which leads to you not moving the mouse for some minutes.

Ignoring the scheme the user manually set does indeed make sense but only for the last 5% of your battery and in order to avoid the notebook just turning off because there was no power left.

openSUSE 11.4 milestones also features a power-management bug that makes your hard disk suspend every few minutes, confirmed but no fix so far.

Major-mystery-32bit-NVIDIA-driver>256.53-KDE>4.4-openSUSE-bug

For openSUSE 11.4 there is still one major mystery bug to solve for openSUSE 32-bit NVIDIA users which get several apps crashing since they updated to KDE >= 4.5.

Package-management

For openSUSE 11.4 we are currently testing kpackagekit/apper as a replacement for the unmaintained kupdateapplet. Kpackagekit works ok but it seems that its zypper backend could need some improvements. And the next version of kpackagekit which will be called apper features monochrome systray icons which is fine, but the “security patch available” signal is just a tiny red dot which is hardly visible, especially if your eye-sight is not the best or you are suffering red-green colour blindness. So most issues with kpackagekit are not actually kpackagekit’s fault but either backend-related or touching artists’ taste.

Phonon-backends

Another application to test is the phonon-backend to be used in openSUSE 11.4 by default. Should we stay with xine whose backend is apparently unmaintained but has served most users well, switch to the vlc-backend or maybe use the gstreamer-backend?

Trying to play some file with amarok and the gstreamer-backend brings up some dialogue (/usr/lib/gst-install-plugins-helper) that asks whether it should search for some package, I guess codecs. If one clicks on “search” kpackagekit opens up and claims instantly that “Getting what provides” finished but does not do anything. This is on 11.3 plus KDE 4.6 from KDF, so let’s hope it works better on 11.4.

The vlc-backend consumes the double amount of CPU for playing the same mp3 via amarok. 8% instead of 4% might not be that much in absolute terms but a 100% waste nonetheless and especially on mobile devices everything that wastes battery should be avoided. Further there seem to be issues playing video via vlc, some apps like dragonplayer.

KDE-PIM

And finally there is of course the always present issue of KDE-PIM. openSUSE 11.4 will ship kdepim 4.4.10 which needs testing. There is especially one annoying bug which makes kontact crash when logging in if the last view before logging out was kmail. So let’s hope this can be fixed before 11.4 gets released.

I was really looking forward to KDE-PIM 4.6 since IMAP-support seems a lot better with akonadi, at least for my use-cases which include suspending/resuming. The latter makes KDE-PIM 4.4′s imap slave fail and not recover which works fine with KDE-PIM 4.6. You can get regularly updated packages for the latter off openSUSE’s UNSTABLE KDE repo.

Help testing

Please help testing KDE SC 4.6 from the openSUSE repos in order to make it shine in openSUSE 11.4. Feedback can go to the related wiki pages or straight to opensuse-kde@.

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/libldap-2.4.so.2: 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/strigiea_vcf.so and strigiea_ics.so.

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.

The openSUSE and thus KDE update from 11.2 with KDE from the KDE:Factory repo to 11.3 and its stock KDE packages went smoothly via zypper dup.

The most annoying issues are that the not threadsafe dbus makes dolphin crash and thus look bad. Akonadi is crashing on logout sometimes, yet I could not get a backtrace yet because drkonqi is shut down while collecting it. And using desktop effects locks-up my Intel driven netbook from time to time because of buggy drivers/Xorg/Kernel (three more bugs: 1 – 2 – 3), i.e. not KDE. I wonder how often KDE gets blamed for bugs that are actually due to e.g. buggy graphics drivers or packages not part of KDE.

If the spellchecker does not work for you with openSUSE 11.3′s kmail, you have to make sure that the dictionary selected is not just the language’s name e.g. “Deutsch” but language name plus country e.g. “Deutsch (Deutschland)”.

From the repos:

KDE SC 4.5 is available for openSUSE 11.3 users. One should be aware though that anything outside KDE:Distro:STABLE (STABLE) is not officially supported by openSUSE and thus you should know what you are doing when adding new repos. Instructions can be found here.

As you might remember the repo structure for KDE on the buildservice changed quite a bit and is now finished. A description of the new repo structure can be found in the wiki. One issue I had was that updating to the new UNSTABLE:SC repo did cause dependency issues. The reason is that while UNSTABLE did contain non-SC apps such as amarok etc. UNSTABLE:SC does not. So you have to add another repo for those or downgrade them to the version that ships with your openSUSE release. Since they should be forward compatible that should not cause any trouble. Alternatively you can choose to add the UpdatedApps repo for upstream stable versions of non-SC applications or some Playground repo for the unreleased versions.

Kdepim45 moved to KDE:Unstable:SC:kdepim45 and currently consists of KDE PIM 4.5 beta 2 compiled against KDE SC 4.5. If you want daily snapshots of KDE PIM trunk you can add tittiatcoke’s kdepim46 repo. But beware, I frequently have to remove akonadi’s and kmail2′s config or apps files because either of those get messed-up easily and cause either of them to fail or crash.

Other small issues with the packages from UNSTABLE:SC include that KDE trunk, i.e. qtdbusmenu which is used for the systray, messes-up knetworkmanager’s context menu, i.e. one get invisible and disfunctional items. wstephenson has a workaround on its way though. And I had to disable the functionality check for my Intel driven netbook in order to get the desktop-effects working again.

You might have read about bluedevil replacing kbluetooth. Thanks to tittiatcoke there are snapshots of bluedevil available in the KDE:Unstable:Playground repo.

Other new packages include Kajongg, the new multiplayer Mahjongg game which was packaged by wstephenson.

From the developers:

wstephenson’s daughter Anna seems to energise him. Helping out on mailinglists and IRC to find the bugs causing issues to openSUSE KDE users. So you might want to check the KDE STABLE repo on the buildservice to test the bugfixes that have already been added and will be released via the official later on.

So thanks to Will openSUSE now has a ‘pure upstream’ KDE SC 4.5.0 openSUSE 11.3 LiveCD which you can use for testing purposes or as installation media. Also related to the release of KDE SC 4.5 are the updated branding packages to give a seamless Ethais (KDE 4.5′s default wallpaper) branded boot on openSUSE.

Bugs he was working on include a bug in KDE PIM 4.4 preventing email address completion working – which has been tracked down to Nepomuk and fixed in STABLE.

Further fixes included a plasma packaging error affecting Plasma’s desktop themes, resulting in black panel elements or black text on black, and missing icons. Other bugs fixed were related to the JavaScript-based default configuration in Plasma Desktop, preventing accidental drag and drop of panel applets onto the desktop while arranging a panel and preventing large applets from getting stuck while dragging them to the edges of the panel.

All fixes related to KDE SC 4.4.4 which ships with openSUSE 11.3 are already in STABLE and will be released via the official update channels soon.

If you are interested in testing mobile broadband support in KDE,  BlueDevil bluetooth stack and Pulseaudio with KDE SC 4.5 in order to asses their readiness for the next openSUSE release, you can join Will and report back on the mailinglist opensuse-kde or on IRC #opensuse-kde.

IMHO renaming URLs will not solve the issue of users getting their information off some forum and mailinglists and thus ending-up with a wild mix of Qt and KDE repos and wondering why their KDE repo suddenly becomes WIP since they are using Factory. Although everything is written out nicely on the openSUSE wiki, most people still did not get the different usage of the term STABLE within the last years. The STABLE repo always contained the packages released with the last openSUSE version plus official openSUSE updates, i.e. “stable openSUSE KDE” rather than “stable KDE for openSUSE”. Hence I prefer a GUI that explains everything to and handles repos for the user, keeping him away from URLs.

Anyway, this week I installed openSUSE 11.3 RC1 from the KDE Live CD keeping my 11.2 user folder and everything went fine. I had to re-arrange a few things since I used the KDE Air desktop theme on 11.2 which is not installed by default because of openSUSE Air.

The desktop effects did not work with my NVIDIA 7600 and the nouveau driver. The tricky bit is that with the nouveau driver installed the binary NVIDIA driver failed to compile. Yet even removing the package did not help, lsmod still showed the nouveau driver in use, no matter what runlevel I chose. Finally I found a hint that one has to run mkinitrd after one removed the package in order to get rid of that failing driver. Quite annoying. So if it fails for you as well and you do not want to use KDE without desktop effects, now you know what to do.

wstephenson announced on the opensuse-kde@ mailinglist that openSUSE 11.3 will ship KDE SC 4.4.4, so you want might to test those packages.

KDE Repos:

Thanks to dirk and tittiatcoke KDE SC 4.5 RC1 has built successfully and will be published to the UNSTABLE repo as soon as it was officially announced by the KDE Community. Further we got a new version of digikam in Backports and even digikam 1.3 will be available soon for KDE SC < 4.5 although it does need some libs from 4.5′s kdegraphics. Other updates include gluon, bespin, kaffeine,  scim-qtimm, amarok-git, qoauth, nepomuk-playground-svn, kdevelop4-pg-qt, kdevelop4-extra-plugins, luckybackup, lyx, vlc and of course Qt. Thanks to jobermayer, bitshuffler, alexqwesa, Beineri, cornelisbb, tittiatcoke and dirk for those.

Update: Digikam 1.3 is available for KDE SC < 4.5 from the Community, not the Backports repo.

Also I found some fellow sufferers that experience the same plasma hangs as soon as the network connection is lost. Who would think that plasma becomes really slow without using the CPU just because my network cable slipped out of the plug.

Community:

Unfortunately I could not attend this week’s KDE IRC meeting at openSUSE thus I can only quote some things from the meeting minutes.

• nepomuk will be off by default in 11.3. Not only its indexing service aka strigi but all of it. However, the akonadi warning dialogue will get a button that starts nepomuk.

From my experience with KDE SC 4.4.3 (virtuoso soprano backend), the version that openSUSE 11.3 will ship, I would have to admit that this is the right way to go for a default setting since for me nepomuk still makes dolphin stall at file operations such as moving a lot of files etc.

Strigi’s harddisk I/O on every KDE login is apparently the only way to check for all kinds of changes to the indexed files. Yet it is known that heavy I/O makes the system and thus KDE look slow and puts off users no matter how useful the features of a tool are. According to the bug report on the issue it was solved for KDE SC 4.5, yet since openSUSE 11.3 ships KDE SC 4.4.3 this does not apply.

• KDE SC 4.4.3 will not be patched to fix a dbus issue that makes nepomuk crash because 4.4 is supposedly not affected that much and nepomuk is off by default anyway.

Repos:

Thanks to dirk and tittiatcoke I could update my netbook to KDE SC 4.5 beta 2 (.85) from UNSTABLE. The main desktop’s update to the packages from KKFD reverted kupdateapplet to the version that comes with openSUSE 11.2 since its requirements were fixed by tgoettlicher and anything <11.3 cannot meet the PackageKit 0.6.3 requirement (yet).

Further I noticed updated packages for kdepim45, NetworkManager-kde4, rekonq, kwin-fx-bedropped, akonadi-googledata, kid3, plasmoid-yawp, cocoon and and the Qt packages. Thanks to tittiatcoke, bitshuffler, plater, jobermayr and dirk for those.

Developers:

llunak found a new way of fixing krunner “command execution bugs” and created a replacement for that feature. I have not tried it yet but the delays krunner has before it actually executes a command are tempting me.

I guess it’s known that openSUSE offers so called “one-click installs” which need more than one click and whose GUI looks a bit like WIP. wstephenson told me that he is working on those issues, so I hope we see some improvements in the ease of usage soon.

From the repos:

• Thanks to dirk and tittiatcoke UNSTABLE got updated to .82
• alin’s simon package (0.3a1) was copied to Playground
• anubisg1 updated acetoneiso2 to 2.2.1 (Community)
• benstein updated kaffeine to 1.0 (Playground)
• tittiatcoke updated kdepim45 daily and amarok to 2.3.1 (UNSTABLE, Community), added bluedevil 0.0.svn1132921 (Playground) and phonon-vlc 2.0git20100601 (UNSTABLE)
• tgoettlicher updated kupdapplet to 0.9.16 (Factory)

From the community:

• cb400f has written a little HOWTO for disabling OOo’s KDE 4 integration:

The KDE 4 integration that OpenOffice.org has is a bit buggy, and it’s not really obvious how to disable it in case of problems. So here’s how you can do it in openSUSE.

Simply put “export OOO_FORCE_DESKTOP=gnome” in ~/.profile (for a single user) or /etc/profile.local (for all users). If these files don’t exist on your system, simply create them.

Setting this environment variable means OOo won’t integrate as well in KDE visually and in terms of the file dialog – but the Oxygen icons will remain, and you will get rid of the bugs. To get the KDE integration back, either revert the changes above, or change the variable from “gnome” to “kde4″.

The above should hold true for other distributions too – possibly with minor adjustments needed.

• wstephenson worked  this week on opensuse marketing, organised preparations for hack week V workshops and presented on writing plasmoids in javascript.  Further he spent time on fixing akonadi bugs and general 11.3 cleanup.