My KDE week

KDE: Week 23

Posted on: June 15, 2010

This week I tried to find the reason for yakuake taking >3 seconds before it slides down the first time. I thought that changing the default black text on white ground profile to one with white text on black ground slowed yakuake’s sliding down quite a bit. But that might have been an illusion since changing it back did not improve anything. However I guess that the graphics driver plays a part in this issue since the delay seems shorter on Intel graphics than on Nvidia (binary driver).

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.


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.


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.


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.


8 Responses to "KDE: Week 23"

The delays that krunner has before executing a command are down to the D-Bus threading issues I wrote about. With a patched D-Bus, KRunner works swimmingly.

That’s good to know. Unfortunately it seems that openSUSE 11.3 will not get the patch. Thus KDE users will see this until 11.4 or 12.0 comes out.

llunak just reported that even though his dbus has the patch applied he still sees the delays. So there might be more to it.

Do any changes (workarounds etc) in code above D-Bus need to be reverted once the D-Bus patch is in place in order to get the improved performance?

I don’t think so. I’m pretty sure KRunner doesn’t really have any workarounds. Nepomuk does, though.

I don’t think so. I’m pretty sure KRunner doesn’t have any workarounds. Nepomuk does, though.

Please, by all means, investigate this and get the patch into 11.3 since krunner not reacting is the single most annoying issue I currently have with KKFD.

D-Bus packages for 11.2 and 11.3 with the patch applied are in the home:llunak:mix repository, if you need to see for yourself that KRunner can stall even with the fix.

Yakuake being slow to pop up is indeed partly driver-related. The NVidia drivers are apparently still suffering from some painting delays. Intel drivers seem to be better, overall, making the whole experience a lot better. I’m also seeing good progress in the free radeon driver, which comes with the whole Xorg stack in 11.3.

With this new drivers, Yakuake rolls in immediately. It is still jerky though, and I think that’s a design problem. Resizing or scrolling in a window like Yakuake does can be done more efficiently and smoother using the compositing manager. You can test that by disabling the animation in Yakuake and enable some KWin plugin that animates appearing windows.

In Plasma, we’ve introduced these “specialised animations” done by KWin in 4.4, the effect is that the panel popup animations are now much smoother.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: