KDE 4.0 is out - a look back

KDE 4.0 is out. While I won’t have the time to give it a rough test today I do have some minutes to look back.

It’s done: KDE 4.0.0 is out.

There is a great Visual guide available, and release parties are going on or will be taking place the next days. Also, don’t miss the clearing words about expectations, features and reality Aaron has posted recently.

For me, unfortunately, KDE 4.0.0 has to wait some more weeks since I am in the final weeks of finishing my diploma thesis, and I cannot risk to alter any of the basic things on my machine. My distribution of choice, Fedora, only delivers KDE 4.0.0 packages for the devel branch, and that is too risky for me atm. Also, as regular readers might have noticed already, I simply have no time at the moment for non-study-related things, I don’t even have the time to blog.

Anyway, KDE 4.0.0 is out now, but it is “just” the final climax of a process started years ago. So here is a short retrospect:

It all started long, long ago. It was in a time when the future of Windows was still called Longhorn; it was a time when Pluto was still a planet; it was a time when I still blogged in German - and for the KDE project it was a time of wild dreams and exciting phantasies:

i’d like kicker to look nicer in general. which is why in KDE4 it will receive a new theme engine

Erm…right, that was just a bit too early. But it shows where to look at: 2005. In these days first bits about the possible KDE future were mentioned in the public for the first time. Around summer things became concrete: Qt 4.0 was released and Plasma was introduced. Some weeks later KDE 4 was already a topic at the annual KDE Conferece: talks were given about Oxygen and Phonon (which was still namend KDEMM at that time).

During fall 2005 the main KDE topic was not KDE 4 but KDE 3.5, which was released at the end of November. But in the background the developers continued their work on porting to Qt4 as well as designing concepts and libraries.

2006 Was the year of the basis: the new foundations for the future KDE found their way into live and were shaped up to become usable for developers. Solid and Decibel were introduced, KDEMM was renamed to Phonon and the first specialiced meeting, the KDE Multimedia Meeting took place. The KDE Four Core meetings followed shortly after, and in the middle of 2006 the kdelibs were finally in a state so that they were merged into the regular directory structure instead of being published as snapshots. And if that wouldn’t be enough the developers got rollicking and released a first pre-Alpha version, Krash.
During the second half of 2006 the KDE conference Akademy 2006 dominated the KDE land. Of course KDE 4 was the major topic (available as slides and videos) and numerous talks were about the new APIs and libraries.
At the end of 2006 the basic foundations for KDE 4 were laid, and it was clear what KDE 4 would leave behind.

The beginning of 2007 brought a pleasant surprise for most users: Troy Unrau started his famous “Road to KDE 4″ series and kept everyone informed about the development around KDE 4. This was one of the most important KDE 4 related PR moves and showed everyone how much development was going on and what really could be expected. This series was great. And indeed, the year 2007 was the year of polishing, shaping up - and showing! 2007 was the year of the screenshots, screencasts and reviews. But of course it was alos the year of Alphas, Betas, cooperation with Trolltech and another conference. 2007 was the year which prepared the world for the launch.

And the launch just happend - the future is now.

Nepomuk-KDE gets more attention - and better Dolphin integration

Recently Madnriva published an announcement informing about the Nepomuk-KDE project in which Mandriva is heavily involved. This lead to more press coverage of Nepomuk-KDE.

Nepomuk-KDE in the news

While aKademy 2007 took place Mandriva used the advantage to highlight their involvement with the Nepomuk-KDE project. The press release drew a line between the Nepomuk-KDE project and the article “As we may think” from Vannevar Bush. That was indeed a nice PR move.

On the technical side Mandriva also mentioned that they work at integrating semantic features with Eclipse and Mozilla’s XUL framework. Other projects for various integration tasks are involved as well:

Mandriva is also leading the implementation of similar features on top of the Eclipse RCP and the Mozilla XUL frameworks, and it is teaming up with XWiki and with the Stockholm Royal Institute of Technology to design a community semantic help desk with rich desktop extensions and P2P capabilities that will bring the knowledge sharing process within the Mandriva community to a new level of efficiency.

The term leading might upset one or two people, but the fact is that Sebastian Trüg, the lead developer of Nepomuk-KDE, is indeed paid by Mandriva to work at that project!

The press release also mentions the video I once created to show the current integration of Nepomuk-KDE with Dolphin. They actually link to my movie page, which is a bit strange because the now rely a bit on me and my page. Hey: I’m now part of a press release

Improved Dolphin integration

Things also developed on the technical front: KListView is a function used in Dolphin to sort lists. As usual you can sort by name or file type:

This function was now extended to also include sort by rating. And the rating is of course provided by Nepomuk-KDE. This means that rating is not anymore some obscure thing you can see in the information window, it is simply one more information about the file itself like everything else:

The screenshot is taken on my system - the code is already in current SVN and can be tested and used by everyone. Btw., it works for tags as well. And the files don’t have to be shown in groups, but it is more screen shot friendly.

At the moment it is however a bit slow on large directories with hundreds of files and directories. And the UI freezes in such cases. But this is still Alpha code, so I quite sure we will see improvements in that field as well

Google Desktop Search available for Linux

Google has just released the Google Desktop Search for Linux.

Google has released the Desktop Search for Linux. Packages are available in native formats (rpm and deb) for various distributions and there are even native package repositories available.

Here are two screenshots you might be interested in. The first one shows the fast search which pops up when you hit ctrl two times, the second one simply shows the system tray icon:

The feature list is nice, but could be better. For example, I’m missing Windows file formats as well as KMail mails or Akregator news. But I guess such things will be implemented over time.
What I miss however is an information if inotify is supported - the main advantage would be that after the first complete indexing Google would not need to update regularly but could rely on internal messaging services to discover if a file has been changed.

This release is an interesting move - I admit that I would have preferred Google Talk because we need free software there more than in the desktop search field were there are already plenty of tools available. Still, it is nice to see that Google really tries to push the Linux desktop by providing the Windows applications for Linux also.

As a side note I think the provided repositories also deserve attention: it looks like Linux starts providing the applications in native binaries instead of *.bin-files like Google Earth. I estimate that rpm files for Google earth can expected in the future as well, making it much easier installing these applications.
On the other hand I hope Google will now push standards which deal with easy installation of additional repositories. That is something the Linux desktop also really needs!

Current State of Xesam (former Wasabi)

Xesam is the project to create a unified API for desktop search and meta data services. The development currently focuses on finding the right way to represent the shared ontologies.

Xesam, which was announced as Wasabi in February this year and was renamed to Xesam in March aims at providing general desktop search APIs (think of D-Bus here) for desktop search and meta data services. The advantage is that you could write a search GUI without caring which search machine is actually working in the background. This would make it easier to switch your desktop from for example Beagle to Strigi.
In the long term Xesam also aims for semantic services:

Concepts like value added services, tagging, and contextual- and related information are also among the buzzwords du Jour.

In the current state the project has released software tools to check servers/services for Xesam compatibility: the xesam-tools. The tools give you the ability to access the Xesam service by command line, however, some first unit tests are also implemented and will be extended in the future.
Also, an example server is part of the tools set which forwards all queries to the yahoo search page.

However, the Xesam project has difficulties to agree on a shared representation format for ontologies. Of course the KDE folks is in favour of an RDF storage just like Nepomuk-KDE is using, but some people would prefer an ini-like system. Additionally, reviewing the different possibilities takes quite a lot of time and the search tool developers are busy enough with their own projects already.

Last but not least, the project itself has problems coordinating all efforts and people because there is a project homepage missing. The naturally best place might be freedesktop.org, however an according bug report has not been answered yet.

In this regard the main question for the near future is if and when the project will agree on the ontologiss format - if that problem is solved Xesam might again gain speed to become a real standard for Free desktops (at least).

More about Nepomuk-KDE: Soprano and KDE integration

Recently Sebastian Trüg held a presentation about Nepomuk-KDE and kindly provided me the slides. In this regard this post is an extension to the post State and Plans of Nepomuk-KDE.

More than just files

After the last post about Nepomuk-KDE many people discussed the pros and cons of a central storage of meta data. Additionally, alternative solutions like using file system capabilities (xarguments, etc.) where often mentioned and discussed.
However, most of this discussions failed to understand what meta data in the context of the semantic desktop are about: they are not only about files. Instead, the main goal of the Semantic Desktop idea is to gather all the data which cannot be connected to a single physical equivalent of a file. Think of bookmarks, e-mails (mbox format for example) and similar things. The other way around is also possible: projects often contain entire sets of files which all belong to one project. Also, in cases like address cards it doesn’t make sense to save the meta data of the file in the attributes of the physical file because in the end you would have to replicate the entire file content.

Soprano and Strigi

As already mentioned the meta data will be stored in a RDF storage - meet Soprano:

Soprano is a library which provides a QT wrapper API to different RDF storage solutions. It features named graphs (contexts) and has a modular plug-in structure which allows to use RDF backends implemented with different RDF Storage.

As the central meta data storage Soprano will be accessible to all applications through the KDE application framework

The storage itself will be filled in different ways. First, there is KMetaData: It provides easy to use functions for system developers to create and read meta data in storage. Think of applications where meta data are an essential part of the program: Digikam and Amarok are typical examples.
Second, strigi - KDE 4’s desktop search machine - will walk through the data available on the hard disk and will extract the file meta data as well as the content of the files (where it makes sense). As an example audio files often cary information about the artist in the meta data, while PDF files can contain meta data about the author but of course also the text in the PDF file itself.

KDE integration

Anyway, back to Nepomuk-KDE: to get a better picture how all the pieces like Nepomuk-KDE, Soprano, KMetaData and strigi work together Sebastian created a chart showing the different pieces:

Integrated into the programs this could look like this mockup:

This window with additional information about a sender of an e-mail contains more related information about the sender: some of information are directly aggregated from the contact data, like the e-mail address, the phone number and the web page, but there are also files displayed which the user has received by this contact, and you can see other people who are related to this person.

This is just a mockup but it gives a pretty good impression of what you can expect in the future - with much more to come.

KNepomuk, KMetaData and Nepomuk - about names

A last word about the naming: although I used the term KMetaData in this post (and particularly in the graphic), this name is actually not valid anymore: libnepomuk now contains KMetaData (together with Konto) and uses only one single namespace, “Nepomuk”. The old knepomuk became the new “Nepomuk::Middleware”.
The original plan was to change the name KMetaData to Braid, however this plan was dropped in favour of the restructuring and the fact that the term Nepomuk is already out there and pretty well known to the people.