KDE is delighted to announce its latest releases—Version 4.7—providing major updates to the KDE Plasma Workspaces, KDE Applications, and the KDE Platform. Check out the highlights below, or read the full announcement.

Plasma Workspaces Are More Portable

With extensive work on KDE’s compositing window manager, KWin, and new Qt technologies such as Qt Quick, the most advanced user interface is available in more places and on more kinds of devices. Read more...

Akonadi Positions Kontact for the Future

KDE's groupware solution, Kontact, rejoins the main KDE release cycle with all major components ported to Akonadi, a leading personal information management storage service. The Digikam Software Collections comes with a new major version, 2.0. Read more...

Improved Multimedia and Semantic Capabilities

There are major improvements to Phonon and social semantic desktop components in the KDE Platform. Enriched APIs and better stability offer significant benefits to developers. Read more...

New, integrated Instant Messaging

The KDE-Telepathy team is proud to announce the technical preview and historic first release of the new Instant Messaging solution for KDE...still in its early stages. All sorts of accounts are supported, such as GTalk and Facebook Chat. The Presence Plasma widget drops right into the panel for managing online status. As this project is not yet mature enough to be part of the big KDE family, it has been packaged and released separately, and has installation instructions. Give it a try!

Stability + Features

In addition to the many new features described in the detailed release announcements, KDE contributors have closed over 12,000 bug reports since the last major releases of KDE software in January 2011. As a result, KDE software is more stable than ever before.

Help Spread the Word

While it's easy to think of the KDE team as mostly developers, non-technical users are also critical to success. Please help spread the word. Report bugs. Encourage others to join the KDE Community.

Follow what's happening with the new releases on the social web at buzz.kde.org.

1. KWin performance is GREAT. It's brutally kicking ass. Believe it or not, Martin Gräßlin managed to squeeze in more performance between RC2 and this. My poor 6150 has blur, and has it while running great. Blurring the Dashboard still doesn't work, but that is a minor regression compared to a (finally) working blur.

Also, my desktop PC (8500 GT) has now Lanczos filtering. Same story: effects that bogged down my system with KDE 4.5 or 4.6 now run GREAT. Infinite kudos for KWin team and their OpenGL 2 backend, with graceful fallbacks.

2. DO NOT ENABLE STRIGI INDEXING, LIMIT YOUR NEPOMUK INDEXING, I'M SERIOUS. Between 4.7 RC2 and 4.7.0, Strigi and Nepomuk indexing code was heavily refactored. The new code lacks any form of testing, and my preliminary tests show a massive memory leak in nepomukstorage service. This, and some regressions in Strigi, can OOM any system with a significant number of files (specially PDFs and some MP3, varies) This was present before, but is somewhat magnified by the fact Strigi doesn't remember what was indexed and what wasn't, so, it simply reindexes all. BTW, I've already voted in the relevant bug report and reported the leak as another bug (and, if Sebastian or Vishesh are here, please give me instructions of how to test Nepomuk for memory leaks, I'm willing to test)

3. The rest of the changes are minor. However, those of you with constantly changing monitor setups (and me with my swiveling TX1000 ;)) will notice a sharp decrease in Plasma bugs. Now Plasma behaves more correctly than never before.

4. The new featurettes of Plasma Addons are nice. KDE Microblog can do full retweets and mark tweets as favourite, and Now Playing now supports Bangarang.

I really hope the Nepomuk crew is listening, because this is serious. The new framework is technically much better, but buggier, and I'm afraid that we'll have to endure a buggy Nepomuk during the entire 4.7 cycle. I expect some bugfixing sessions from your part, and I'm willing to help, testing (I don't know how to code...)

If you disable Strigi indexing and keep Nepomuk usage to minimums, then this is a great release, and stability is better than never before.

> Between 4.7 RC2 and 4.7.0, Strigi and Nepomuk indexing code was heavily refactored. The new code lacks any form of testing, and my preliminary tests show a massive memory leak in nepomukstorage service.

Could someone else confirm?
I think that Strigi and Nepomuk indexing is enabled by default, no?
If yes, then this is really shocking: I think that we can expect a lot of negative reviews of KDE; again..

We've honestly tried to fix most of the issues. The massive rewrite done after RC2 was done to address the memory leaks.

There are going to be some files which will not get indexed, as with 4.7 we do not accept incorrect data from Strigi. The solution is that the Strigi indexers need to be fixed. Trueg has fixed a number of bugs in the indexers. We can only hope that the distros upgrade Strigi regularly.

I forgot to backport the bug where Nepomuk does not remember what it indexed. Fortunately someone pointed it out and I management to contact the release team in time. The fix is present in 4.7.

While I have not experienced impaired performance for as long as I can remember using KDE SC 4.x, I agree to some extent in that the development of Nepomuk and Strigi worries me a bit.

My files are well organized and I never search for anything (except for e-mail in KMail ocassionally) or use that rating and tagging functionality. I wonder what the performance impact of Strigi and Nepomuk is, and I'd be interested to see benchmarks. i know that it's possible to disable Strigi and Nepomuk through System Settings → Desktop Search (possibly that it was you need Anonymous?), but does that really negate all the potential performance impact of these two?

Well in this case, you should be upset that KDE devs chose to release this feature without tests: untested code is broken code (most of time).

Look this is not a strigi/nepomuk specific issue, this is a software development process issue.

If you read about the Linux 3.0 development history[1], you'll see that they had a late bugs, that they finally understood and fixed with a 15 line patch, yet Linus *still* made another RC release to check that the patch was correct (and it wasn't 100% correct).

So a rewriting of not so small portion of code *activated by default in KDE*, *integrated after the last RC*??
Why do you think that this time they would have caught all the bugs even though they weren't able to do it the time before?

> Well in this case, you should be upset that KDE devs chose to release this feature without tests: untested code is broken code (most of time).

The new Nepomuk bits come with a lot of unit teests to check functionality of the internals and prevent regressions with development. Please, at least get your facts straight before going with unsubstantiated claims.

> The new Nepomuk bits come with a lot of unit tests to check functionality of the internals and prevent regressions with development. Please, at least get your facts straight before going with unsubstantiated claims.

I don't claim that Nepomuk is untested, unit test are nice, but the "Release Candidate" test is a much more thorough test to pass (assuming there're are enough users willing to use the RC): that's why Release Candidate exist!

That new code was integrated after the last RC which means that de facto, the RC wasn't a real RC, IMHO the KDE project should have the courage of naming things properly: either they do RC and call them RC, either they don't and they call it beta-1, beta-2, etc and then release.

Unit tests are not a valid replacement to widespread testing, when it comes to memory leaks. The unit test will pass, because the functionality is there, and the memory leak will be small and so will get unnoticed, because the function generating the leak is only used once. However, if you want to test seriously a program, you don't need only unit tests; you need torture tests. For instance:

1. Select 12,000 audio clips from FreeSound and index them with Strigi.
2. Repeat with 1,000 complex PDFs.
3. Repeat with 1,000 MP3.
4. Monitor memory consumption. Are there any leaks? How is every service in the Nepomuk chain working?

I've been working with some law documents (statute histories, they are LOOOOOONG) and I proposed them as torture tests to exercise one specific Nepomuk feature: PDF text indexing. I'm amazed that you don't know that: I'm finishing a law thesis, I don't know a bit about coding, but, as you can see, I don't need to be a computer scientist to know a bit about testing.

PS: Better yet: why don't you turn your unit test into a test that exercises 50,000 times the same function, and see the result (and you can also time it, measuring performance increases)?. This *COULD* be better, but still cannot replace torture tests (e.g. cleaning memory properly in the test, but not in the real world). Unit tests built this way + torture tests = the way to go ;)

Unfortunately, the KDE project abuse the term "release candidate" in strange ways. Then they release an RC, it's explicitly *not* a candidate for release, i.e., something that they consider releasing unchanged as the final version. KDE used to have proper release candidates in the old days, but these days we see major rewrites even after the *second* "release candidate", creating problems in the actual release. I wish they would reconsider this practice. On the other hand, though the path is rocky, what comes out at long last is a great product, so I can't really complain.

I'm watching closely this, because I'm sick of watching my favourite desktop being botched down by a buggy implementation of an interesting technology, like Nepomuk. I see the heavy Nepomuk refactoring that is taking place in KDE 4.8 trunk, the rationale behind it and I suggest:

Why don't you just backport the whole thing? After all, despite all of those leaks, they a) were present before (I can attest that, KDE 4.6 exhibited similar behaviour with nepomukstorage, but I only suffered it once, since Strigi remembered what was indexed, so it was bearable) and b) they need anyway a refactoring for a proper fix (the infamous dbus CPU and memory leak bug was indeed killed by the refactoring in KDE 4.7.0)

There are users, like myself, willing to test the final fix of Nepomuk.

After filing a bug in Fedora, I got experimental Strigi 0.7.5 packages, I installed them, and I discovered that my Strigi install was broken. There were duplicate files in Nepomuk database, and after I purged the old install and installed Rex's packages, some of my issues (Strigi indexer not remembering what was indexed, incorrect PDF indexing, for instance) were corrected.

However, the memory leak remains while indexing, and I suspect this leak haunted us since forever. Reindexing with the new Strigi binaries, Virtuoso is at 1 GB and counting. Fortunately, Vishesh Handa told me he can reproduce the leak, and he's working on it. Let's hope for the best :)

It's totally fine to use the GNOME Shell as your primary desktop shell if it suits your usage pattern better. All your favorite KDE applications are still very well supported though you lose the features provided by our KDE Plasma Workspaces.

Is it just me, or am I the only one who thinks the new folder icon isn't better than the previous one? In itself the new one isn't bad, it's the strange dark blue line which is so odd. Also the new icon seems to be mixed with the old icon, in the screenshot here the 'Documents' directory still uses the old icon which makes the iconset inconsistent. Maybe this is a trivial issue and you can't argue about taste, but why was design decision made I wonder?

What I really like about this release (based on what I see from the screenshots) is the new user interface for Dolphin. Just like with web browsers, I barely ever use the menu in a file manager, so it's nice to have it hidden under a button so it doesn't eat up vertical space.

The announcement mentions that 'KwebkitPart, integrating WebKit into KDE applications, has improved ad-blocking support, making browsing with a KDE WebKit browser a more pleasant experience'. But I wonder if anything else has changed to improve web browsing? Asking the question differently, I still need to fall back to Chromium because rekonq doesn't work well with some websites. Are problems when web browsing with rekonq caused by rekonq itself, KWebKitPart or QtWebKit?

I'm grateful for the new Akonadi-based KDE PIM, but unfortunately I still experience many problems – http://bit.ly/olg5mQ – when I use it. What worrying me even more is that I've been testing the new KMail for months before it was released and that I reported many bugs, of which the majority are still waiting to be investigated. I don't blame the developers because their time and the amount of developers working on KDE PIM are in short supply, But still, I think Evolution was more pleasant to use when I was still using GNOME. KMail 2 will probably improve in the future though, now that the developers can focus on polish since the port to Akonadi has been completed.

Hey thanks for the comments.
The folder that is not finished is the HTML folder not the documents one. Need to come up with a better metaphor than a proto web browser that does not scale all that well...

I tested this folders alot and, I'm fully aware many people wont like them specially at the beginning, but we decided it was a step that we needed to take for several reasons, and from the vast feedback i get in this things people seam to grow an increasing love for this new folder.

There are more than a few reasons we changed the folder and in the end we believe it was the right thing to do.... BTW that screenshoot was not the happiest one as its shows some icons that should not be there and way to less empty space between icons making it look crowded a bit better would be http://wstaw.org/m/2011/07/28/plasma-desktopjI4451.jpg

Dear Nuno,
Is there a chance we'll see the "Classic" Oxygen Icons as an icon theme by itself???
I like the new Oxygen Icons, but I have to say I'm deeply in love with the old ones, so, I'd like to see them in a different theme, something like "Classic" and "New" oxygen.
Cheers, Migue Chanhttp://blueleaflinux.blogspot.com/

Asking the question differently, I still need to fall back to Chromium because rekonq doesn't work well with some websites. Are problems when web browsing with rekonq caused by rekonq itself, KWebKitPart or QtWebKit?

Nope. That is caued by the way QtWebKit releases are currently done which is beyond the control of reKonq or any webkit based KDE browser for that matter. Since a more up to date version of QtWebKit is bundled with major feature released of Qt (4.6.0, 4.7.0, 4.8.0), users have to wait until the next cycle of a major Qt release to see any tangible improvement, other than critical bug fixes, in QtWebKit based browsers. For example, the version of QtWebKit (v2.0) that comes bundled with all of the Qt 4.7.x releases is based on a snapshot webkit from over a year ago.

Unfortunately this problem cannot be addressed until QtWebKit releases are independent of Qt release which is something that is like not going to happen until Qt 5. The good news is the work on Qt 5 and Qt modularization is underway. Until then I am afraid the only way to get an up to date webkit based browser for Qt based platforms is for either you or your distribution to compile one of the new stable branches of QtWebKit from source, http://trac.webkit.org/wiki/QtWebKitReleases.

Strange... many users and devs had complains about khtml in the past, argueing that webkit was more advanced. But now that webkit is available, it looks like that the situation is not better: QtWebkit is not up to date.
For now, I'm still using khtml because it works better for me.

Strange... many users and devs had complains about khtml in the past, argueing that webkit was more advanced. But now that webkit is available, it looks like that the situation is not better: QtWebkit is not up to date.

QtWebkit WAS more advanced than khtml at the time that discussion took place. And it still is if you compare apples to apples, i.e. the current versions of QtWebkit and khtml from their respective sources.

As I already explained what hinders QtWebkit is how it is being distributed right now. More recent versions are only included on major Qt releases. Anyhow, nothing stops distros or even you from compiling a more recent stable version version of QtWebkit and using that instead of what comes bundled with Qt [1][2]. You cannot say the same about

Having said that, there are more than a few things in khtml that do not exist in QtWebkit because no one has yet implemented them. Spell checker for input boxes and access keys support are two things at come to mind right away. However, on most prominent things like speed of the JavaScript engine or rendering more sites like the major browsers, there simply is no comparison.

>Anyhow, nothing stops distros or even you from compiling a more recent stable version version of QtWebkit

The sheer size of qtwebkit 663 mb (downoad as source at git), and the time and configurations required to install; where are the clear and lucid documentation to compile and install qtwebkit for a distro?

Actually, I did compile and installed qt-4.8tp1, but it did not fix any promised issues, like java applets etc., becuase no clear instructions to compile and install the qt-4.8 or qtwebkit 2.2 are given.

Just like kde extracted phonon from qt and included in KDE SC, why can't KDE extract qtwebkit into kdewebkit??? Because khtml abhors its own child webkit?

The sheer size of qtwebkit 663 mb (downoad as source at git), and the time and configurations required to install; where are the clear and lucid documentation to compile and install qtwebkit for a distro?

First, why exactly would distros need anymore special documentation than the one provided at https://trac.webkit.org/wiki/QtWebKit#BuildInstructions to compile QtWebKit ? If you want to compile your own up to date version of QtWebKit all you have to do is build Qt without webkit support by passing --no-webkit. Then you can compile and install your own QtWebKit version [1].

Second, the actual size of the tar ball you can download from the links I posted in the earlier reply (there is a link for downloading a tar ball) is about half the size of what you mentioned above.

Actually, I did compile and installed qt-4.8tp1, but it did not fix any promised issues, like java applets etc., becuase no clear instructions to compile and install the qt-4.8 or qtwebkit 2.2 are given.

I have no idea what you did, but java applet support has been working since QtWebKit 2.1. See https://bugs.webkit.org/show_bug.cgi?id=33044. On Linux you need to install the offical Sun/Oracle jre or java sdk for applets to work properly. The icedtea plugin will not work properly and no one has had the time nor the inclination to look into why. I know I haven't.

Just like kde extracted phonon from qt and included in KDE SC, why can't KDE extract qtwebkit into kdewebkit??? Because khtml abhors its own child webkit?

Do you have any idea how much work that is ?? The amount of work required to maintain the QtWebKit port is more than enough to keep several folks in the Qt division of Nokia busy on a daily basis let along the one or two people working on kdewebkit. Not to mention the fact that KDE is in the process of getting some of the core things merged upstream for Qt 5 which would be completely counter intutive to what you are suggesting here. But then again you seem to think that the reason for this has something to do with the very old khtml vs webkit conflict...

Oh and KDE did not exactly extract phonon from Qt. It was the Qt folks that sucked Phonon in and then changed their mind later because they had their own specific needs that they claimed cannot be satisified through the collaborative effort of working on Phonon.

To be honest, I think that the new folder icon looks a bit out of place. Not just on that screenshot, but everywhere. I don't know if its the color composition or the drawing style, but it somehow visually it doesn't mix perfectly. Maybe it's just me being used to the old icon, let's see.

Of course, a crash isn't a feature. I haven't tried the opensuse rpm's yet, so I don't know whether it's a bug in packaging. But it's most likely something weird locally to your installation. Try moving the .kde or .kde4 directory to a backup place and then login; it might be some setting in there that's causing trouble.

1. KWin - just behaves as a window manager should (compositing, wobbly, invert effect)
2. System Tray - Really nice widget which does not disturb the work flow
3. KWrite - very nice editor
4. Okular - best pdf reader
5. Dolphin - ok and better than rest but not the best
6. Yakuake - best terminal reduces clutter
7. smplayer - 2nd best video player but 1st in features and ease of use (filters, subtitle downloading)
8. Vlc - 1st best video player but 2nd in features
9. Qbittorrent - best feature wise
10. speedcrunch - best calculator
11. Goldendict - best dictionary application
12. qt-recordmydesktop
13. recoll - awesome desktop search which strigi strives to be

All the above look coherent in KDE because of
14. Oxygen style - the best mac os like polished interface
15. Oxygen icons - again the best mac os like polished icons

And thanks to oxygen-gtk, most feature rich and useful programs are consistent in KDE 4; like gnome-mixer, gnumeric, libreoffice, firefox (with oxygen-kde)

As can be observed, I'm using mostly QT only or GTK applications more for my entertainment and productivity;

most default applications do not go to the point of "wow" factor like smplayer, goldendict, speedcrunch. here's a list