KDE Releases 4.5.1

Today, KDE updated the Applications, Platform and Plasma Workspaces to 4.5.1, new releases bringing a number of important bugfixes on top of 4.5.0. 4.5.0 was released only three weeks ago and receives monthly service updates. 4.5.1 is the first in this series of bugfix and translation updates. These releases improve stability and the user experience further, while not bringing major new features or bigger changes to the user interface. 4.5.1 is a safe upgrade for anybody running 4.5.0. 4.5.1 has been dubbed "Cronjob" as it is one of the regular releases published by KDE, just like a cronjob does.
This release will make 4.5 users lives more pleasant by adding a number of important bug fixes, bringing more stability and better functionality to the Plasma Desktop and many applications & utilities. Check the changelog for details about many of these improvements.

On a related note, on Thursday, KDE will release a third beta version of the Kontact PIM and groupware suite for testing the port to the new Akonadi infrastructure. The new version of Kontact will be released once it has reached sufficient stability for everyday production use. The next KDE SC 4.5 update is scheduled for 30th September. The next major release, 4.6.0 is planned for January, 26th 2011.

Dot Categories: 


Thanks for the update guys. Unfortunately Dolphin is still very unstable, still freezes and crashes. I was hoping that this update would fix Dolphin but it doesn't seem to be the case. A big show stopper. It's the first time since the release of KDE 4 that I have to fall back to using Konqueror as a file manager.

The root cause for this is an issue in libdbus (see https://bugs.freedesktop.org/show_bug.cgi?id=17754 for details). The issue has sideeffects not only to Dolphin, but also on other parts of KDE (e. g. Nepomuk). However it gets triggered very often in Dolphin, as since KDE 4.5 Dolphin also retrieves metadata for files if Nepomuk is disabled.

The dbus-issue has been fixed in the meantime, but AFAIK it has not been backported to the stable release branch. Until then the only workaround to bypass those hangs is to disable the Information Panel and/or tooltips in Dolphin.

I'm quite frustrated about this issue myself and of course thought about providing workarounds to bypass this issue, but those workarounds would result in new issues... :-/

Information panel is now off and no tooltips... still the lagginess seems to persist..
Can it be due to $Home being distributed by NFS? KDE 4.4 Dolphin took twice the time to display an NFS-directory compared to 4.5, but was responsive after all files were displayed. Now I experience sudden lags when using Dolphin..... (me being clueless)

It could be NFS-related, but I'm not sure... Would it be possible that you submit a bug-report at bugs.kde.org with detailed information about your configuration? (e.g. is it lagging after clicking on a file or also during scrolling? Is it also lagging if you browse through non-NFS directories? ...) By this we can assign the issue to the corresponding NFS maintainer afterwards and you'll automatically get informed if the issue has been resolved. Thanks!

I'm trying to get some reproducible lags, but it seems more or less random. I can't tell for sure, what triggers Dolphin to go into "sleep mode" for some seconds... It seems to happen more often, if Dolphin was running for a while in the background. Will try to investigate further...

For me, the problem is resolved since version 4.5.0.

I have downloaded KDE 4.5.0 packages for Slackware 13.1 from the blog of Eric Hameleers:


Those packages are already patched, but the problem is still present; indeed, the patch alone is not sufficient.
To resolve this problem, you must upgrade to DBus >= 1.3.1; after this update, for me the problem has disappeared.

Dolphin is perfectly stable and metadata always come instantly.

Dolphin is very unstable. Sometimes it's freezing for about 10-30 seconds, than suddenly it's continuing to work (very strange). When cklicking on a file to open it, it halts for about 10 seconds until it starts the application (e.g. okular for a pdf-file), in about 10-30% of cases it simply crashes either after openign the file or afterwards.
(Using Suse 11.3 with Suse supplied packages, but same behaviour with Arch)

I will hear if this bug still is in kde 4.5.1 or I can finally upgrade from kde 3.5 ?
https://bugs.kde.org/show_bug.cgi?id=156475 <-the bug

You could click on the link you've supplied yourself. If your goal is to exert public pressure for your pet bug until someone fixes it for you, that's not fair towards other bugreporters, and not motivating for me personally to work on this corner-case.

I'm wondering if somebody whom has tested 4.5.1 can confirm that Klipper is working OK again? In 4.5.0 it's not possible to select Klipper entries with either, keyboard, or left click with mouse (only right click on Klipper icon works).

It would be great to hear that this is fixed in 4.5.1...

The bug status of 246308, 245360, 244620 are not clear if this is fixed. (One is fixed, but folks report it is not; others haven't seemed to receive attention). I'm sticking with 4.4 until I'm confident since I wasted too much time with 4.5.0 .

In 4.5.1 i face problems with dolphin like when i have tooltips enabled and hover over a pdf or image file, i need to wait 10 to show tooltip with preview. Thats really bad.

Dolphin laginess
In 4.5.1 i face problems with dolphin like when i have tooltips enabled and hover over a pdf, image file or directory, i need to wait 10 to show tooltip with preview.

There is a reason why your distro doesn't carry still KDE 4.5 by default. Check your DBus package. If it's 1.2.2x, you'll certainly have delays. If you run 1.3.1, you are saved from all delays. Wait a little bit... the major distro refresh is not too far.

If you run Ubuntu, add this PPA and follow the instructions in this page.

After that, recompile it with rpmbuild --rebuild.
DO NOT DOWNLOAD A NEWER RELEASE (unless you really want to switch to Fedora 14, the dbus 1.3.2-snapshot there has support for SystemD)

If you run Arch Linux, then install this package from AUR
This is dbus 1.2.24 with the race condition bugfix patched in. It will work great, but can break another apps, so beware.

After that, your KDE will be snappy.

What about openSuse? Anything available for it?
After checking the packages I realized that I have dbus 1.2.24 but dolphin is still hanging and crashing. What is the problem then?

You realize that you have dbus 1.2.24 and Dolphin is still hanging and crashing. I say: as long as you have dbus 1.2.24 Dolphin will hang and crash for you.

The quickest one for you is to download a source RPM from Factory and rebuild it for your OpenSuSE. This link will be a great starting point. Remember: you rebuild it with rpmbuild --rebuild. Install it on OpenSuSE!

Edit: The link I gave you was a recipe for disaster. Try the Fedora package, or try to find specifically dbus-1.3.1 on Factory. DBus 1.3.2 has SystemD support, so you'll have to install SystemD and you'll surely break your init system.

Edit 2: dbus-1.4.0 has been released, so I compiled it right into my system, with good results. Now Dolphin is snappy, and since I don't have systemd, the hooks simply are not compiled.

Edit 3: You won't see any link to dbus-1.4.0. Here it is.

Uncompress, and do the ./configure --prefix=/usr; make; sudo make install dance.

by sta

I downloaded the dbus-1.4.0 ,uncompressed it, did the ./configure --prefix=/usr; make; sudo make install, but could't simply dance because there are so many problem occurred. The usb ports, bluetooth, network manager and many things don't work. The error messages are mostly about system_bus_socket: no file or directory.
How to fix this?
I tried to reinstall previous dbus with sudo apt-get install --reinstall dbus but still error.

edit: managed to uninstalled the dbus-1.4.0 and installed dbus-1.3.1 ... now everything is fine

Sorry for wrong reply

From my testing and a message coming from a KDE Developers blog that leaked through the Planet: if you use NVIDIA, you can improve a lot your perceived speed and eliminate any slowdown simply turning away from the Oxygen style/decoration to ANYTHING else. I've obtained excellent results with Bespin, with the side effects of even more eyecandy, ARGB support and XBar.

I fully recommend the switch, and I hope the performance problems between NVIDIA and Oxygen be solved soon.

The problem is particularly serious with the nVidia GeForce 8400GS (which, notoriously, has little exciting performance); the system initially is very fluid, but then starts to slow down gradually and after about half an hour becomes unusable.
At this point, the only way to remedy is to restart KDE4; probably (I suppose), Oxygen saturates the video memory with a resulting drop in performance..

With any other style/decoration, KDE4 is very fast; currently, I'm using QtCurve.

You can also use the nouveau driver. this is what i do.
But i agree that its not really satisfactory, i can't play any games and flash videos fullscreen are unusable.
at least it makes me a little more productive ;)

I didn't use Bespin for quite a while until I read your post. It has certainly improved a lot and yes everything seems to be faster. Are there colour themes for Bespin? I really like the Bespin Theme but prefer the Oxygen colours.

I discovered that the performance of Oxygen will increase significantly by disabling window animations and decoration animations.

System Settings - Look and feel - Style: Oxygen - Configure: Enable Animations [unchecked].

System Settings - Workspace - Window decorations: Oxygen - Configure: Enable Animations [unchecked].

I am not fully convinced by your workaround, specially since Bespin works here at full speed WITH animations (they are a lot like Oxygen animations, but Bespin had them first) Also, I don't have a monster card either (this is an HP laptop with a nForce430/GeForce 6150 SE, one of the lowest NVIDIA chips supported by the 256 series driver, and several orders of magnitude slower than your 8400)

I've made a stylish Bespin config to remove some of the flashiness of the style and to give me a more plain color palette, like Oxygen (well, like Whitewater, I really like that color scheme better than Oxygen). If you send me a good place to upload it to, I'll gladly do it.

EDIT: In my other computer (GeForce 8500) blur runs happily with Bespin enabled, and not so with Oxygen. Now I'll sync my Bespin installation with SVN and try ARGB.

EDIT 2: My suspicions were absolutely confirmed. My home computer (GeForce 8500) runs beautifully Bespin (SVN from today) with full ARGB transparencies and blur enabled all the way, without any major slowdown or performance penalty. The performance of Oxygen, on the other hand, deteriorated rapidly with blur enabled (I'm speaking about oxygen-transparent, stock Oxygen doesn't support ARGB).

EDIT 3: This screenie is achieved with Oxygen-Cold color scheme and some minor tweaking, Bespin SVN. The effect is dramatic and, remember, no slowdown.


I've been trying to fix this problem with oxygen+nvidia.

I wrote a blog post at http://hugo-kde.blogspot.com/2010/09/performance-issues-one-script-and-c..., notably to give instructions on how to compile oxygen from trunk, on top of your distro, and test latest changes. (I can't test myself. I've no NVIDIA card, and no problem, in fact).

Current results are promising, judging from the posted comments.
When I am sure enough about it, I'll backport to kde4.5 branch (as well as to oxygen-transparent).

So that there is hope this whole mess is fixed by the time 4.5.2 is out.

Since the reports on the blog post are pretty positive in terms of performances with oxygen+nvidia, I backported the changes made in trunk to both Oxygen-transparent and kde4.5 branch

Hopefully, soon enough NVIDIA users won't have to change from oxygen to 'anything' for any other than personal taste.

PS: posting screenshots on other styles is somewhat off-topic here, since the issue is of a 'dynamic' type rather than static. Only thing we learn is that bespin might look good to some users. Oxygen (especially in screenshots) does look good to some others. The problem is (was) more in terms of how usable it is (which *cannot* be shown with screenshots).

Hugo (oxygen developer)