Today, KDE releases a first developer snapshot of the
upcoming KDE4 release. This snapshot is meant as a reference for developers
who want to play with parts of the new technology KDE4 will provide, those
who want to start porting their applications to the new KDE4 platform and
for those that want to start to develop applications based on KDE4. This
snapshot is not for end users, there is no guarantee that it will be stable,
the interfaces are subject to changes at any time. The changes that have gone
into the development version this snapshot is based on have all happened under
the hood, little is visible yet. Now it is up to application developers to use
the new possibilities. While this snapshot will probably not be what kdelibs
will finally look like, it should give a fair idea of what to expect.

Developers can start porting their applications using this snapshot and
investigate the new exciting technology. Highlights of this snapshot include:

DBus will be the
Inter-Process-Communication protocol used for KDE 4. This snapshot contains an
initial implementation. With the use of DBus, KDE will feature improved
interoperability with other applications on the Free Desktop. Porting applications to DBus is explained on the porting wiki page.

Phonon (documentation) is another central feature of KDE4 providing a
unified multimedia backend that offers an easy way for application
developers to add multimedia capabilities to their applications.

Questions about KDE4 can be answered on various mailing lists such as kde-devel and kde-buildsystem, as
well as on #kde4-devel on irc.kde.org. Documentation for getting up to speed
with KDE4 development is available from a numberof sources.

Work is continuing on other pillars of KDE4, such as our Plasma desktop, Solid hardware layer, Oxygen artwork theme and Decibel communication architecture.

KDE development has never before been as exciting as it is today, so start
hacking today!

Comments

Beware, this is a candy store only half filled and with some pretty old candies in between. Nothing, really nothing spectacular by now. Only on parts of the API. Something you see when coding, not compiling.

Before anyone goes ahead and compiles/runs this, please be aware that it will look exactly like KDE 3.5 - except for being broken in lots of places.

The good news for developers is that this is a reasonably solid code base for diving into KDE / Qt 4 hacking. By solid I mean that it actually compiles reliably and most programs at least start without crashing ;)

I remember that the "Tenor" Contexual Linking Engine (http://dot.kde.org/1113428593/) was at one point going to be one of the cornerstones of KDE4. Is there any progress on that, or has it been (un)officially canned? It would be a shame if that were the case :(

There's a 'strigi' desktop search project that seems to be advancing fast, but contextual linkage is more than full-text search. Actually a full-text index doesn't contain explicit contextual information of any kind, and it can only be used to infer textual resemblances.

What I mean is you can notice that two files contain similar words, but you can't, for instance, notice that they are usually edited simultaneously. (Which would be nice to know within 'Open...' stuff).

Didn't knew about that. On the other hand its still the only information that looks relevant. The official kde.org site does not give any hint on the status of neither Kat, nor Tenor; the latest information I found is dated 2005. SVN activity is at a low level (latest update 4 month ago).

IMHO, the fact that Scott leaves a Linux related job in favor of a more multimedia related one (whatever this means in detail), _may_ be more relevant than it looks at a first glance. In his blog he wrote: "KDE has slipped to the background of late and like many aging ... F/OSS hackers I'm left wondering if that's a real transformation -- a shift in priorities -- or simply a phase that will be revisited once life settles down a bit..." (http://www.kdedevelopers.org/blog/72, 06/29/2006), even if it just means that instead of Tenor he prevers to work on Phonon (http://www.kdedevelopers.org/node/2007) or something else any time in the near future.

Daniel was correct that SAP never significantly supported my personal KDE related projects. (There were however a few times that there were features or fixes that SAP needed inside of KDE that I was allowed to work on, but we're talking about maybe one week of KDE work per year.)

At my current job I'm doing cross-platform pro-audio stuff, which also has nothing to do with KDE, but for the moment I rather enjoy.

Sponsorship for my KDE work has never been something that I've sought. KDE is one of my hobbies and I'm fine with it staying that way. (Not to mention that I have to have normal full-time employment to remain in Germany where I've been for several years.)

So, then what's with Tenor?

Like I said above, KDE is my hobby. Sometimes I feel like working on it, sometimes I don't. (My life has also been really busy in the last few months, but really it's more of a matter of motivation than time.) When I don't feel like working on it, I don't. It's really that simple.

The desire to work on Tenor for me comes in waves. A couple months back I spent a few weeks hacking on it again. I haven't touched it since then.

So, will Tenor be in KDE 4?

Maybe. Really it depends on if and when I feel like hacking on it or if someone else decides to pick it up and run with it. Think of it as a surprise. ;-)

One thing that some people who ask me about this find interesting is this graph:

That, aside from being my first (and likely only) time to play with the Perl bindings for Qt, was the number of changes going into TagLib before I moved it into KDE's CVS. Every line is about a month (30 days). The main difference between how I've hacked on TagLib vs. Tenor is just that I kept very quiet about TagLib before I was ready to release. That's been my modus oparandi for most of what I have developed. (For instance, I was already using JuK as my day-to-day player before anyone else knew it existed.)

However, just from a searching perspective, I'm pretty excited about Strigi. I've talked a bit with the developers and almost all of the work that they're doing is orthogonal to the interesting parts of Tenor and the design of Strigi impresses me more than Kat did (both from an API and information retrieval perspective). They've got multiple backends and building one that used the Tenor store would not be terribly difficult.

Hmm, I'll probably blog this as well since most of the activity on this article is from a couple days back. Hopefully this clears up some of the current Tenor ambiguity.

Many thanks for your response. I'm really happy and delighted to read that Tenor is definitely not dead, as some people claim ;-)

One thing I am wondering about is, whether it is too early to change KDE apps to support Tenor, as soon as it is there.

I don't know if the API is already there, but even if not, it may be interresting to see what happens, if there's a DCOP (or DBUS) service that accepts notifications (e.g. from KMail saying that 'this' document has been 'sent' from 'xy' by 'email'), so everyone (may it be Tenor or any program else) is able to connect to that service for listening what happens on the K desktop.

E.g., someone may find that it would be a good thing if KDE apps would also send notifications on what documents they are now going to open, and which one they are going to close (and to utilize this in some kind of 'task menu', that shows currently open documents, instead of 'tasks').

I'm not sure if this is the way to go. Is DCOP/DBUS a viable solution for this kind of task? Or is a library better? Is it too early to create an API now or does it already exist?

Ok, its been a while since I've posted here, what the HECK is with that crazy anti-spam thing? Thats funny...

It isn't at the moment, but it should be. Unfortunately the three most used fileystsme (Ext3, XFS, and my favorite, ReiserFS) don't support this, and don't support plugins. Reiser4 does, but nobody uses it since it's not in the kernel yet.

But then someone would still have to write a plugin for Reiser4 to make it handle contextual linkage, which would majorly increase read/write time for the filesystem and also increase the filesystem's footprint.

For now its best left to userspace, where we can pick and choose what gets what kind of information.

No, Tenor was meant to be able to search in ways such as 'file John sent me' and be able to see all files that you received from 'John' (whether you got them via an email in KMail, or over IM in Kopete). Stuff like that beagle can't do without lots of help, because the programs (in this case, kmail and kopete) would need to include the functionality to say either in the extended attributes of the file, or tell some central DB that 'John sent this file'. The file system has no way to know which program created/modified the file, much less that it was John that sent the file to you.

So the difference:
With Beagle you search for stuff in the file (eg, contains the phrase "the dogs are weird!"), with Tenor you would search for stuff ABOUT the file(eg, "file I sent John" or "file I downloaded from svn.kde.org").

Personally, I don't want to even touch that Mono thing. In Gnome camp they are desperate to use Mono because it's clear that GTK and C are not leading them anywhere, but KDE has already a very nice and not encumbered development framework. Beagle solves an interesting problem, but a pure KDE solution is still needed IMHO.

GLScube sounds good and appears more elaborate than Strigi, but as other posters note, the issue is getting the semantic details to the search subsystem automatically. If I save an attachment from an e-mail message, I want "the system" to set all the "Sent by John" and "Subject of original e-mail" metadata; there's no way I'm going to enter all that metadata myself every time I click Save.

Also: "glscubefs... is a user-level file system that encapsulates the features of GLS³ in a traditional file system interface". Another day, another VFS!

Eventually there will have to be standard APIs for apps to provide metadata on save and other events.

is there a chance, that one glory day we'll see KDE running natively on Windows? because I miss it every time I am forced (you know, *the evil forces*) to use a Windowsmachine. i miss Koffice and Knotes and Kalarm and Kontact and most of all I miss my beloved Konqueror, because it is much better, faster and much more convenient than Firefox.