KDE 4.0.3 Released With Extragear Applications

The third bugfix release of the KDE 4.0 series is available. KDE 4.0 is mainly targeted at users who live on the bleeding edge. As a dot-oh release it might have its rough edges. The KDE Community releases a service update for this series once a month to make those bleeding edge users' lives easier. The changelog for KDE 4.0.3 is, although not complete, quite impressive. Especially KHTML and with it the Konqueror webbrowser have seen great improvements in both, stability and performance.

Since KDE 4.0, some Extragear applications form part of the release. Extragear applications can choose to follow their own release cycle, which is what for example Amarok and K3b do. There is also the option to have extragear applications released with KDE. Applications such as RSIBreak (a program to save your health), KGrab (an advanced screenshot-taking tool), KPovModeler (a 3D modelling application). Tom Albers, responsible for the release of the Extragear package says, "The new item in this release is kio_gopher. It's really great that this protocol is still not dead and we now have support for it in KDE4. New technology meets ancient protocol ;-)".

The KDE Team also uses this release to highlight some gems of the KDE package. This time, a closer look is being taken at the KDE Educational software. The KDE Edu project has also recently done some work on their website, which is surely worth a visit. We hope you enjoy this release and notice our commitment to making progress in stability and usability of the KDE 4.0 series while development of KDE 4.1 is going on at more than full speed.


By Matt Williams at Wed, 2008/04/02 - 5:00am

Now it makes sense why opensuse will release their "special" kde 4.0.x branch,

by the way, the last kde 4.0.67 for windows rocks, happy to read pdf by okular. Thanks pino ;-)

By mimoune djouallah at Wed, 2008/04/02 - 5:00am

AFAIK, there are also some new features, but as they didn't make it into the changelog, they didn't make it into the announcement. That's why I wrote "not complete" about it. Trying to get everybody to fill the changelog is quite a challenge. *hint*

By Sebastian Kuegler at Wed, 2008/04/02 - 5:00am

As in my experience the openSUSE 4.0.x releases had at least as much bugs as the supposedely "unstable" 4.1pre Packages, I happily switched to the more feature-rich 4.1 and never looked back to 4.0.x. If you get bugs as well with 4.0 as 4.1, you might as well learn to cope with 4.1's bugs ;).

While this is basically a good sign for the upcoming KDE4.1, it nevertheless leaves one with a dull taste concerning the release policy which lead to 4.0. Here something went wrong IMHO.

By anon at Wed, 2008/04/02 - 5:00am

Well, actually my experience has been quite different. While the 4.0.x releases are stable I've already had lots of problems with the 4.1 svn version - both using opensuse 10.3.

Plasma crashing on every startup, lots of apps not even loading - I'm glad I haven't seen that in the 4.0.x versions. :) Anyway, I agree that there are some nifty features waiting for us in current svn. Looking forward to it!

By WPosche at Wed, 2008/04/02 - 5:00am

"Well, actually my experience has been quite different. While the 4.0.x releases are stable I've already had lots of problems with the 4.1 svn version - both using opensuse 10.3"

perhaps you are mixing the two repositories stable and unstable, remove all kde 4.0.x and delete .kde4 , and just install the last kde 4.0.67, you will be surprised.


By mimoune djouallah at Wed, 2008/04/02 - 5:00am

I used to have the stable packages on that machine, then I upgraded to the unstable packages and had these problems. Just deleted .kde4 and checked that there were no more old packages installed. Still some apps don't work (games, amarok). Still nice to see the default settings again in KDE4.

By WPosche at Wed, 2008/04/02 - 5:00am

Probably there were something wrong from your side because games were/are in a very nice shape.they were never broken.

By Emil Sedgh at Wed, 2008/04/02 - 5:00am

> Plasma crashing on every startup,

with BIC changes to libplasma happening for 4.1, you have to be really careful to keep your plugins in step with libplasma. that's been the only known source of start up crashes to date. so this is an installation issue, not something in our code.

By Aaron Seigo at Thu, 2008/04/03 - 5:00am

Absolutely, please can you explain to me, why a distribution can't ship kde 4.1 alpha if it is quite stable, because right now (imho) kde trunk is more stable and has more feature (of course) then branch.

Strange days, the unstable branch is more stable then the stable branch.

By mimoune djouallah at Wed, 2008/04/02 - 5:00am

>Strange days, the unstable branch is more stable then the stable branch.

This one made my day, and the funny part is that it's probably true :D

By Iuri Fiedoruk at Wed, 2008/04/02 - 5:00am

openSUSE does. You can choose between stable and development version of KDE4.

However, I had a problem with the dev version: it needs Qt 4.4 beta and LyX didn't work with that.

By Grósz Dániel at Wed, 2008/04/02 - 5:00am

I guess you don't know what "Alpha" state means in software development.

By Anonymous at Wed, 2008/04/02 - 5:00am

I agree. It feels like 4.0.x is a waste of time both for developer and users.

They should keep it as close as possible to KDE 4.1, so stuff get tested and we get a quality release in summer. There is no point in developers wasting time to maintain 4.0.x and backport stuff to it. Nobody uses 4.0 in a production environment and it's not a real stable release. As you say, if users can cope with 4.0, they'll cope with 4.1 alpha and beta.

By anon at Wed, 2008/04/02 - 5:00am

The first time I read your post, it seemed kinda harsh.

But the more I think about it, the more truth I see: Nobody wanting to use a stable desktop will use KDE 4.0.x - in this case KDE 3.5.9 is the way to go. KDE 4.0.x is a beta version (there's no flaming here, as that's more or less the official line, can be read in various blogs of developpers).

So basically, we're talking about a work-in-progress, and maintaining a KDE 4.0.x besides developping KDE4 seems as sensible as maintaining an early beta version of a program.

By Anon2 at Wed, 2008/04/02 - 5:00am

Oops, something lost here:
Maintaining KDE 4.0.x besides developping KDE 4.1 seems as sensible as maintaining an early beta version parallel to a newer beta version.

By Anon2 at Wed, 2008/04/02 - 5:00am

Anons do we have? We have Anon (original afaik) then we have anon and now Anon2. What's next? Anon reloaded?

By Bobby at Wed, 2008/04/02 - 5:00am

We are Legion.

By Anon Reloaded at Wed, 2008/04/02 - 5:00am

Just want to say: LOL

By fred at Wed, 2008/04/02 - 5:00am

How did you know?

By Anon reloaded at Wed, 2008/04/02 - 5:00am

We always know everything since we control this Matrix.

By Anon Revolutions at Thu, 2008/04/03 - 5:00am

Well, your mileage may vary... I've been using KDE4 nonstop since 4.0.1 (4.0.0 was too unstable for me). Apart from the obvious defects, 4.0.2 is quite stable. My biggest annoyances are krunner (after executing successfully a command it complains it couldn't do it) and kwin (way too slow in composite mode).

By NabLa at Thu, 2008/04/03 - 5:00am

I see on 4.0.3's changelog that some effort has been made to optimise kwin on nvidia, let's see how it goes :)

By NabLa at Thu, 2008/04/03 - 5:00am

Seems smoother here on my GeForce 4 MX 440. (It wasn't half bad before either)

By Jonathan Thomas at Thu, 2008/04/03 - 5:00am

Not smooth at all on my Geforce 6600GT. Drives me nuts, have to use compiz.

By MarcG at Thu, 2008/04/03 - 5:00am

Since the MX 440 is much older, slower and have less memory,
it's another driver you have to use.

By reihal at Thu, 2008/04/03 - 5:00am

Still slow for me, no improvement :? I have a similar card with latest nvidia drivers...

By NabLa at Thu, 2008/04/03 - 5:00am

I read your post and decided to install 4.0.3

Surprising result when measuring frame rate on 8400GT using glxgears:

kde 4.0.2: 8300 frames in 5.0 seconds
kde 4.0.3: 4617 frames in 5.0 seconds

half the performance.

I have to file a bug report on that...

By Sebastian at Thu, 2008/04/03 - 5:00am

No, even less. The first reduction appeared after installing 4.0.3, killing kwin4.0.2 and starting kwin 4.0.3.

After restarting the session I am at 1500 frames per 5.0 seconds...

wow! this is as fast as my old ATI wothout 3d support! May somebody explain this? Shall I see this as a sign (I will exeggerate) that kwin is making the gpu busy or is it a good sign (in terms that kwin now uses the gpu at all)?

By Sebastian at Thu, 2008/04/03 - 5:00am

> krunner (after executing successfully a command it complains it couldn't do it)

for the record, this bug is not in krunner but elsewhere =)

By Aaron Seigo at Thu, 2008/04/03 - 5:00am

The debian KDE packagers agree with you. They are skipping 4.0.X>2 entirely and packaging KDE trunk builds until 4.1 is released.


By Leo S at Fri, 2008/04/04 - 5:00am

i think (imho) as a user, it is the right decision, i am really concerned about the reaction of users after using kde 4.0.x specially plasma (btw the most important piece in kde), let's wait and see their reaction to fedora 9, ubuntu 8.04-kde4 and in less extend opensuse 11 ( i really hope they postponed their release date and ship kde 4.1 bata )

it is always hard to forget the first impression ;)

By mimoune djouallah at Fri, 2008/04/04 - 5:00am

I tought the contrary.
But as most bugfixes are NOT being ported to 4.0 series, and plasma just crashes everyday for me (on logout and sometimes on login), I just want 4.1 stable and with more features. Having to maintain 4.0 series does not help to improve 4.1, so please, kde tem, do not work on 4.0.4-beta, we want 4.1-stable!

By Iuri Fiedoruk at Sun, 2008/04/06 - 5:00am

> please, kde tem, do not work on 4.0.4-beta

I disagree, please do backport bugfixes! I really don't want to have to backport dozens of bugfixes from 4.1 all alone for Fedora 9's KDE 4.0.4 update which is going to come a few days after the release. Please keep users of the stable branch in mind and backport bugfixes to the stable branch whenever possible. With that logic, i.e. if all the bugfixes go to the unstable trunk only, we'll never have a stable release.

> most bugfixes are NOT being ported to 4.0 series
if it's true (I don't have any metrics to decide either way), is the real problem and should really not happen. But dropping 4.0 entirely is not the solution, actually backporting bugfixes is!

By Kevin Kofler at Sun, 2008/04/06 - 5:00am

The question is how trunk get more stable ?
By all users testing and using what is kde 4.0.
So the state of kde 4.1 is so good because some use kde 4.0.

By phD student tha... at Wed, 2008/04/02 - 5:00am

and the answer is: i think developers are users too :)

By Emil Sedgh at Thu, 2008/04/03 - 5:00am

it's a numbers thing: both the number of users as well as the number of different ways the system is used. developers involved with a system tend to use the software in repeated, predictable patterns. introduce new users (even if they are also developers, but of some other software) and issues start to arise pretty naturally / obviously.

that said, i'm happy to see the 4.0.x releases rolling. it's a good practice and the improvements are welcome by many.

counterballancing that, yes, i'm very much of the "concentrate on 4.1 as much as possible (but no more)" opinion as well.

By Aaron Seigo at Thu, 2008/04/03 - 5:00am

That is because 4.0 is in essence a Beta release. And as a Beta release it is, it doesn't make that much sense for it to have bugfix releases, the best way to make it stable is to continue development towards a Release Candidate state, which is being done in the 4.1 branch.

If you look at Plasma in 4.0 for, which is central to the end user experience, it is far from done, that's why it is allowed to introduce new features in supposedly bugfix releases. Libplasma won't even remain binary compatible until 4.1. All this are characteristics of Beta releases.

Of course 4.1 is more prone to break than 4.0 but, since so many improvements have been done over that old Beta state, it's natural that overall it is better quality.

I know this is beating a dead horse. In any case it is the natural answer for these kind of comments. From the moment that you keep in mind that 4.0 is Beta, lots of strange things suddenly make sense.

By ad at Thu, 2008/04/03 - 5:00am

I noticed that now there is a divider line on the right click menus between the containment configuration and applet configuration buttons.

By Jonathan Thomas at Wed, 2008/04/02 - 5:00am

Very impressive changelog. Seeing forward to using 4.0.3 in a couple of days!

BTW, anybody in the know whether the annoying https problem ("SSL negotiation failed") is fixed?


By Uwe Thiem at Wed, 2008/04/02 - 5:00am

That bug is Qt's fault, not KDE's.

See these for the gory details:
Also be warned that SHLIB_VERSION_NUMBER as used in this patch doesn't necessarily work on your distribution. (It's broken at least in Fedora 7 and 8, we got that fixed in Fedora 9.)

By Kevin Kofler at Wed, 2008/04/02 - 5:00am

Uh well, so I have to wait for 4.1 (with Qt 4.4) and use Firefox for https sites meanwhile. Annoying but certainly manageable. ;-)


By Uwe Thiem at Wed, 2008/04/02 - 5:00am

Well, if the bug report is correct, you can add a symlink to get openssl found...

By SadEagle at Wed, 2008/04/02 - 5:00am

Or install the openssl-devel package or whatever your distro calls it, which contains that symlink.

By Kevin Kofler at Wed, 2008/04/02 - 5:00am

Well, if you're building from source, you can patch your Qt, if not, try getting your distro to fix it.
I hope Trolltech will fix it for 4.4, I'm not sure whether they know about it yet though (we just figured out what was wrong a few hours ago, it was filed as KDE bugs in Konqueror and Kopete and not recognized as a Qt bug).

By Kevin Kofler at Wed, 2008/04/02 - 5:00am

Already fixed about a month and a half ago.

By Thiago Macieira at Wed, 2008/04/02 - 5:00am

To be fair, a few sites only work with a specific version of the SSL protocol and it was KDE that needed to be fixed. The fix is to try SSL versions in turn (this means 3.1 and then 3.0). I dont't know if the fix has made it into 4.0.x but it is in trunk which will become 4.1.x.

By Andreas at Thu, 2008/04/03 - 5:00am

Sad to say no it has not been fixed.

By taurnil at Wed, 2008/04/02 - 5:00am

"Seeing forward to using 4.0.3 in a couple of days!"

I think you mean 'Looking forward...' :) Made me smile anyway... I was once asked to write an 10,000 word essay on the difference between 'looking and seeing'. If I can spend that long discussing it I think I'll allow you the confusion... ;)

I not entirely sure but I think in this context 'looking' is active but 'seeing' would be considered passive.

By Martin Fitzpatrick at Wed, 2008/04/02 - 5:00am