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.


Does anyone use Gopher or is kio_gopher more like some kind of nerdfun? ;-)

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

There are a few gopher enthusiasts still out there that painfully refuse to let the protocol die; but the same could be said about any old protocols... anyone remember FIDO-net? It's still (barely) alive these days too! :P

Early in its history, KDE had gopher support, but even then the protocol was mostly dead. The protocol is simple though, and easy for open source hackers to have some fun writing kio plugins :) Open source is half motivated by having fun anyway :)

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

I was actually expecting more bugfixes (bugs missing is what NOT happening), but I'm really happy the blank desktop and double click where fixed. This together with the quick-launch plasmoid from kde-look makes KDE4 usable to me (but still far from kde3.x).
Now if I could get a stable port of k3b, amarok and kmplayer...

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

As said in the article the changelog is not complete.

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

The full automatic changelogs are linked from the manual crafted one btw...

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

No, that's not a full, automatic changelog. It's done by hand, and as that, it's not complete.

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

I thought KDE was going to switch to Webkit for Konq? Or was that only for plasmoids?

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

Right now, the KPart that uses webkit for Konqueror is not ready for consumption. It's somewhere in playground/. Until that one is ready, KHTML will stay Konqueror's default engine for sure. We'll see what happens afterwards, in the end the user will be able to decide.

Webkit is used in Plasma, though, for example for OS X Dashboard widget support.

By Sebastian Kügler at Wed, 2008/04/02 - 5:00am

And just to clarify sebas's comment, KDE won't have WebKit at all until KDE 4.1, when it starts to depend on the (still unreleased) Qt 4.4.

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

>in the end the user will be able to decide

Once I have a webkit part, bye-bye firefox (yeah, because right now khtml does match my needs).

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

You were misled

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

You know, I really admire you KHTML guys to keep chugging on despite the ignorance and negativity.

And for giving us such a wonderful HTML engine cum working complete kpart.

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

Yeap, thanks for your work and your patience! :)

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

"I thought KDE was going to switch to Webkit for Konq? Or was that only for plasmoids?"

That all depends on what engine the vast majority of developers want to use, and what applications that vast majority of users want to use. That's the direction things will naturally head in, and the bottom line is if WebKit provides better day-to-day web browsing than KHTML, with bug-for-bug compatibility with Safari being useful, then that's what people will use. Alas, web developers are not going to change and are not going to test with KHTML - just as they have never done.

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

> bug-for-bug compatibility with Safari

QtWebKit is not WebKit and does not provide Safari compatibility. Saying such a thing is not even a joke, it is a fraud.

In order to build a webkit backend, developers have to fill hundreds of undocumented stubs with a non-trivial meaning, especially for people who are very new to the internals.
Each one of this stub is an occasion for a new bug, or for a missing feature when left unimplemented.

So on the surface, you have a working engine, as regression tests allow you to check that you match the very basics - but at every corner things will fail, because of poorly understood limit conditions and undocumented requirements, or because of vastly different under-pinnings, different network layer exhibiting undiscovered race-conditions in CSS loading, whatever.

Hell, I can already single out QtWebKit with a goddam *CSS* statement because of such bugs. That's just ridiculous.

The only people able to build a fully working backend with WebKit, are the Apple developers, that have full knowledge of the code base - it will always be so, and that's exactly how Apple likes it:
Free advertisement, mind share, and competitors under tight dependance.

But anyway, you just have to try the demo browser for 5 minutes to realize that : a web browser is much, much more than just a rendering engine.

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

"QtWebKit is not WebKit and does not provide Safari compatibility. Saying such a thing is not even a joke, it is a fraud."

I know certain people like to go around perpetuating this impression for their own ends, but this is false. WebKit, and henceforth QtWebKit, opens the door very much for bug-for-bug Safari compatibility and between other WebKit browsers to create a bigger target for web developers. This counts for a lot, because no web developer is going to change their ways and start testing with KHTML this side of the next ice age. As you say elsewhere, there are corner cases to every web rendering engine, and that's why KDE is still devoid of a native browser people can count on.

"In order to build a webkit backend, developers have to fill hundreds of undocumented stubs with a non-trivial meaning, especially for people who are very new to the internals.
Each one of this stub is an occasion for a new bug......."

Blah, blah, blah, blah, it's too difficult. We get the picture. Taking the above, why do you think most KDE users use Firefox rather than Konqueror?

"The only people able to build a fully working backend with WebKit, are the Apple developers, that have full knowledge of the code base - it will always be so, and that's exactly how Apple likes it"

The source code for WebKit is there. It's taken a while to get there, but it is there, Trolltech are using it in Qt and devoting lots of resources to it, as are Nokia, Apple of course and lots of others. Economies of scale are always better.

Repeating the above is not going to make this true, but my main point still stands - if a QtWebKit based browser renders the vast majority of web sites people visit better then KHTML, people will use the WebKit based browser. That's the way it is.

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

KHTML or WebKit does it really matter? Most web developers seem to test for browser not engine. And that would still be Konqueror.

For the record, in my browsing I have minimal need for other browsers. The few sites I wistit where Konqueror/KHTML is not up to the task, usually works when changing browser identification. Not that I have any strong feelings either way when it comes to WebKit, but I doubt it will revolutionize my browsing experience.

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

"KHTML or WebKit does it really matter?"

It does because if we use QtWebKit, (even if it is not absolutely compatible with the Safari WebKit) the websites tested in Safary will be likely to work in Konqueror as well, and Safari has much bigger market share than Konqueror.

I think Konqueror should be rewritten (in the same powerful but more flexible way) because developers often say that Konqueror code is such a mess that adding even small features is painful. If KHTML improves (as it continually does) and a decent web browser based on it is written that runs on Windows and Mac OS X as well, it could enter the browser war and gain enough market share to be noticed by website developers.

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

"the websites tested in Safary will be likely to work in Konqueror as well"

That may be, but the waste majority of sites I see that Konqueror has serious problems works when changing user agent. It's not the testing by web developers and the rendering of KHTML that is the issue, so changing to WebKit will not change this.

By Morty at Sat, 2008/04/05 - 5:00am

nothing to see here, moving along

By Dmitriy Kropivn... at Thu, 2008/04/03 - 5:00am

yeah that's very bad, a lot of people still use proxy to access the net, in my country nearly all cybercafé and companies network use proxy to share net acces, unfortunately many valuable kde applications can't be used due to this limitation.

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

Odd, I thought that was what setting proxy settings under systemsettings -> Network Settings were for.

By Morten Sjøgren at Fri, 2008/04/04 - 5:00am

"systemsettings -> Network Settings were for" eh sorry, i forget to mention i was speaking about kde apps under windows,

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

Just upgraded using the Kubuntu packages and I must say I'm quite impressed. There are rough edges here and there (obviously) like some bizarre funkiness when logging out and then back in (all KDE3 apps create windows instead of tray icons, and Kwallet, IMAP, etc. processes are "not found") but to be honest it's completely useable.

So... question is... is it worth filing bug reports for 4.0.3? Or is this stuff getting fixed elsewhere (i.e. should I be running from the latest branch to help with bugfixing?)

Anyway, ta very much like. Good job folks.

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

yes, you can and should report bugs. After all, next month we'll release the 4.0.4 bugfix release, and the more bugs are fixed, the better it'll be ;-)

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

Thanks :) Just wanted to check... Things are moving along so quickly I was concerned any bugs would be behind the current status.

I'll get on with it then.... :)

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

It would be useful if upstream developers at least read/answer the bugs. I've opened since 4.0.1 a bug for Kopete not working correctly with my Jabber server (while Kopete KDE3 works flawlessy) and I've still got no answer. I don't want the bug fixed, but at least someone telling me "we care 'bout your bug reports".

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

I'm still downloading, but very impatient...

Were any new compiz effects added since 4.0.2?

(yes, yes, I know. They're not essential, but I do enjoy looking forward to new eye candy with each release. It makes computing more fun :D )

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

i wouldn't think so. 4.0.x releases are bugfix releases only. new features likely introduce new bugs. plasma is the only kde 'project' that i'm aware that was allowed to introduce new features with a bugfix release.

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

Makes sense.

Still. :(

I guess I'll have to wait a few more months until KDE 4.1.
Hopefully there will be lots of effects by then.

Maybe "feature parity" with compiz fusion. *dreaming* I know...

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

You can install KDE 4 from trunk, that gets you some new and enhanced effects, such as the CoverSwitch [alt][tab] switcher. Instructions how you do that are to be found on techbase.

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

I see a lot of this "feature parity" with compiz fusion about, but nobody ever gives any indication of wich particular feture they are missing in KWin. You can not expect the KWin devlopers or others to hunt trough Compiz fetures to find things to implement.

And Kwin even have original effects, and they may even be better solutions than the effects Compiz uses. In that case perhaps one should drream of the day Compiz fusion reaches "feature parity" with KWin.

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

Probably the most visible and common feature that still seems to be missing is the rotate cube functionality for switching desktops. Its flashy and provides clear visual feedback for desktop switching. And it always surprises shoulder surfers who want to know what cool software you're using on your laptop.

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

To be honnest I can't see what all the fuzz is about, do people actually use that? Or is it just a show-off toy, turned off when real work should be done? And it's not soo cool either, afterall I have seen much the same effect as browser plugin when switching tabs. When your browser does it, it kind of looses some cool :-)

IMHO, KWin's Desktop Grid gives a clearer visual feedback for desktop switching. That you see all desktops at once gives a better overview, and the ability to move applications from one desktop to another are all parts that gives it much better usability than the rotating cube.

But it's true KWin does not seem to have the cube yet, but that's only one feature. If that's the only thing missing, the "feature parity" should not be such a big issue.

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

It was only after playing with compiz that I realised what a good window manager kwin is, while compiz has the bling bling looks after a while its poor window management got on my nerves.

I do miss the wobbly windows though!

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

Wobbly windows is beeing worked on, but I'm not sure of the current status regarding release.


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

Poor window management, and the fact that most of its effects are pretty much useless. Well, useless as in not being of any practical use that is. Great for showing of or playing with...

I much prefer the more sensible effects available in KWin (well, okay. The explode effect may not be all that sensible...).

Still, there are a few Compiz things I would love to have in KWin:

*The wobbly windows. Don't know why I like them...
*A better minimize-effect. IIRC, Compiz calls it the magic lamp or something like that (or was it MacOS X that called it that? They use the same effect for the dock at least). It provides a much better visualization when minimizing windows.
*A win-deco that can import and use Emerald themes.

Okay, kinda silly things to miss maybe...

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

"Feature parity" means that both have "the same" features.
It does not include a meaning of which one is better or which one had the features first.

Just wanted to clarify that.

I also think the original poster meant that to be a noble goal, not a strict requirement.

By Mike at Mon, 2008/04/07 - 5:00am

Here are some of the effects I'm missing:
(this list includes effects currently under development, or already done.)

Desktop Cube (both normal and inverse) Win Fish/KDE gears "swimming" in it.
(please add "wet floor" and fish swimming outside of the cube. As if the Cube were a fishtank, but strangely the fish swim on the outside. Maybe make some of the fish 3d Penguin "Tux's". I think that would be cool.)

A Compiz effect screensaver/"relaxation effect" for when people are "brainstorming" and would love their desktop cube interact with virtual environments. (i.e.: Snowy hill -rolling down, or stuck on the side, floating in the ocean - like a message in a bittle, in a tropical setting - small lonely island with a lonely palmtree. Desktop is perched against the tree.)

A "paper plane"/origami effect for minimizing applications or desktops.

An effect similar to "magic lamp" on minimizing applications.

A "wet floor" effect - Have fun with it, surprise us.

Expose - better than desktop cube, it allows all desktops to be seen side by side on a nice glossy surface. (aka.: "wet floor")

Effects such as "Fire" for when programmers/writers are frustrated and need to get rid of some frustrations.

Maybe another effect like the above where I can throw Toasters, red swingline staplers, Mice, calculators, notepads, sharpies, and lots of other typical "office equipment" at the desktop, which then has dents in it. -- That effect needs to clear easily and quickly, should the muse strike again and I'm ready to do work again.

A "shuffle" effect, where windows bump each other out of the way, when moved violently or brought to foreground.

A compositioning effect that reacts to the music that's playing using KDE's Amarok/Phonom engine. (could also be a screensaver) Make it do something cool with the desktop.

Effects that entertain the user - when he asks for them to be loaded. (DON'T BE "CLIPPY" and show up without asking)

A random effects generator. - for people who can't decide.

A way for emerald window decorations to work - or a similar easy to use engine for getting additional window decorations, mouse effects, etc.

I realize many of these effects are less useful and more "fun", but that's what linux and desktop computing should be: FUN!!!!!!
Linux/KDE computing should be more fun than the gray on gray computing world that we have to deal with Windows.

Others please add effects you would like to see. Describe them as best you can, so creative 3d animators/3d effects programmers can incorporate them.

And yes.. the "over the shoulder look" when using a Compiz enabled laptop is VERY, VERY necessary and important. I've recruited at least 5 people in the last three months to the world of Linux and some to KDE because of "DESKTOP - EYECANDY".

People like to be visually stimulated. Why do you think french food is prepared in such a nice way. The eye enjoys the meal too, so to speak.
Don't be wasteful with screen real estate either. Notice how big plates are when serving french food, and how little space is used by the actual food, leaving tons of room for "whitespace"?

By Max . at Mon, 2008/04/07 - 5:00am

Correct me if I'm wrong, but the idea of Plasma wasn't having a (stable) API where developers could work into, and that would make possible to release independent updates of plasma desktop and plasmoids, as those whould be only script not needing compilation?

I remember Aaron talking about something like that (or I am terrible mistake and sorry) and was curious if Plasma (not the lib part). It would be much batter for users indeed, but nowdays I only see C++ plasmoids.
Is there a plan to make plasmoids stop using C++ (and stoping crashing my whole desktop) and plasma API stop receiving changes so that KDE 4.1 plasmoids work on KDE 4.2 and vice-versa?

THAT would be the true nirvana for plasma and users. A nice goal to plasma project, in my opinion, making plasmoids more than simple widgets in the desktop and panel.

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

I'm pretty sure python-plasma exists now.

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

What about pony-plasma? That's been promised for aaaaaages.

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

> those whould be only script not needing compilation

correct; and right now we have support for ecma script (updated), python and html/css all coming together. hopefully they'll all be ready for 4.1 (they all currently work, it's just a matter of details).

> Is there a plan to make plasmoids stop using C++

for technical reasons, certain widgets will remain C++.

> and plasma API stop receiving changes so that KDE 4.1 plasmoids work on KDE 4.2
> and vice-versa?

as i said long before 4.0 came out: libplasma will not be binary compatible between 4.0 and 4.1, the goal is to move to binary compatibility once 4.1 is out.

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

>libplasma will not be binary compatible between 4.0 and 4.1, the goal is to move to binary compatibility once 4.1 is out.

That was what I thought, and really will be very-very good thing indeed sir! :D

I just hope there is a kind of incentive to people avoid C++ in the non-official plasmoids. I know they can be even more stable than the ones from the KDE team, but I do not like the idea of getting a new plasmoid that crashes all my desktop and on restart I loose a lot of plasmd configuration (in 4.0 series it seems like plasmoids geometric are saved only in logout, a bad thing because plasma crashes on logout for me, so basically I never have new applets saved) ;)

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

I thought that Konq was moving to webkit and they were dropping the KHTML support, and am I incorrect? Or did plans change?

By KDE User at Fri, 2008/04/04 - 5:00am

This never was the plan, is not the plan and will not be the plan.
KHTML is maintained and developed so fast, there is no reason to drop it.
there might be some Webkit support, so you could choose you want KHTML or Webkit, but KHTML is never going to be dropped.
about the webkit, there is currently noone working on intergration with Konqueror right now, so i think Konqueror + Webkit is a post-4.1 thing.

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

>KHTML is maintained and developed so fast, there is no reason to drop it.

Sorry to tell you, but what about the users?
I do not want to be bad at KHTML developers, but those are the facts:
- webkit is today, much (much, much, much in case you do not see it) better than khtml (a thousand times sorry, but.. it's true)
- webkit is becoming a standard with support from industry key players like apple, nokia and google.
- If KHTML development is fast, webkit development is twice faster :-P

C'mon guys! I know it's hard to drop your ego because letting khtml goes means admiting the the fork is better, but look at xfree86 and xorg! Sometimes evolving means forking and letting the old die alone in peace. :D

Well, if KDE 4.1 do not come with a webkit kpart, I'll start a browser from zero using webkit/qt/kdelibs!!

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

> webkit is today, much (much, much, much in case you do not see it) better than khtml

it's much harder to spread such lies and vapored hype when people can actually try the demo browser in Qt 4.4 RC and see what it is up to.

KHTML majorly kicks WekitQt's ass in about every domains,
and is ridiculously faster.

I'm not talking about beliefs here, you just have to *use* the software to see it.

> I know it's hard to drop your ego

if KHTML developers had any inflated ego problem, they would have dropped
the project long ago - it takes quite a bit of selflessness to endure the nauseating corporate-loving drivel from people who have forgotten their history or are just plain malevolent.

By w. at Fri, 2008/04/04 - 5:00am

Did I said webkit or qt/webkit?
Let me se.. no, webkit, there it is!! webkit, no qt mentioned :D

Tryied ipod touch, safari for windows and safari for mac with webkit nighties.
All of them kick khtml ass, and I am using khtml from kde4 that is way better than kde3 was ;)

The only advantage khtml have is that kde developers are more used to the code and integration is easier, I give you/them that.

By Iuri Fiedoruk at Sat, 2008/04/05 - 5:00am

> Did I said webkit or qt/webkit?
> Let me se.. no, webkit, there it is!! webkit, no qt mentioned :D

You should have, because if konqueror is to use webkit it will be qtwebkit.

By Renaud at Sat, 2008/04/05 - 5:00am