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:
- An initial port of kdelibs, kdebase and kdepimlibs to Qt 4,
providing the developer with a wealth
This snapshot uses a preview of the upcoming Qt
- 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.
- CMake (FAQ) is the new buildsystem used for KDE4.
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 number of 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
I feel like a kid in a candy store, time to start compiling ;)
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.
> Beware, this is a candy store only half filled and with some pretty old candies in between.
LOL. Well put.
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 ;)
Can I see some screenshot anywhere?
Given that the GUI looks essentially the same as the current 3.5.x release, I don't think screenshots would show you anything interesting.
Imagine KDE 3 with more crash dialogs.
ooops, so what's for plasma I hope aaron are making real progress
I think you might be interested in latest Aaron's blog entry: http://aseigo.blogspot.com/2006/08/cooking-belaying-delaying.html , he talks about plasma toward the end.
Just look at a 3.5 install.. there you go..
They stated that the eye candy has not changed, yet... its all underneath.
What is it? I never heard of this project before..
Not sure if there are more uptodate news anywhere:
Yeah, that link was also in the posting, but it has nothing for users, only developers, and that information is kind of unclear to me :(
Tapioca is a Voip framework developed by Nokia. Using the "example" application I was able to use Google Talk voice for the first time on my GNU/Linux system. :)
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).
To answer your question, yes, contextual linkage in KDE 4 is dead, unless somebody can tell us more...
well, dead is a big word, there is still some thinking about it. but nothing concrete, no.
Something like this for KDE4 will come. But I would bet not for KDE 4.0.
All that I found with Google is that Tenor "Chief Architect" Scott Wheeler is leaving SAP Linux Labs...
Which is hardly relevant given that SAP never paid him to work on KDE.
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.
Maybe this is the time to look for some assistance for Scott?
I suppose I can drop in some details here:
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?
However, thank you for answering, and for your work.
Seems like Tenor is not so important now that there's a decent KDE frontend to Beagle. I've been using it in SuSE and it's quite nice.
This is not the point at all. Beagle is a desktop search engine. Tenor is/was supposed to be a contextual linkage engine, see my previous post for the difference among the two.
Isn't that a file system job?
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.
C is not THAT bad, and mono uses gtk# for it's gui.
the only real benifit i see is that this will give you a object orientated langauge.
http://www.glscube.org/ is a good alternative, because it's real.
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.
Re: Also: "glscubefs... is a user-level file system that encapsulates the features of GLS³ in a traditional file system interface". Another day, another VFS!
What's wrong with that? It only allows application that doesn't use directly GLS3' interface to use search functionality in it's file open dialogs...
The GLS doesn't use Fuse for indexing files.
How about a Win32 snapshot? I think I heard that mingw and MSVC compile kdelibs fine at this point (although D-BUS might still be an issue)
hehe, without really knowing it, I would think the source is all you need to compile it in a windows environment.
Take a look at http://www.kdelibs.com/wiki/index.php/Main_Page
kdelibs4 compiles out of the box with msvc and mingw (there may be errors due to some commits, but normally fixed in a few days).
Currently the biggest problem is dbus (http://sf.net/projects/windbus) - when this works all kdelibs-test need to be fixed for win32.
Does the Krash preview already implement the new Portland intergration stuff?
This stuff is implemented by the XDG utils not by the desktop itself. The utils are currently in beta and can be downloaded from the portland site.
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.
Yes, this is planned for KDE 4. The development code already compiles on win32.
thank you. :-))
Are we talking Cygwin here or is it the real deal?
i meant "the real deal" and if I got it right, Richard meant the same.
Yes, that's right. TrollTech released a GPL version of Qt 4 for win32 which makes it possible for us to support it natively in KDE too.
my english ist poor, but wouldn't that be a nice name for the Windows-KDE: "KDE 4 The real deal"? ,-)
No! That would imply that the original KDE was inferior somehow.
I wish it will never happen, there is enough work to do on kde4 itself and porting to win32 is sabotage. Here is a short list of reasons for those who still doubt http://www.fefe.de/nowindows/
And if it ever happened, the win32 version would always remain a second-class citizen with more bugs, which would give bad publicity to the whole KDE project.