Submitted by The KDE project announces the availability of the third development snapshot of the upcoming KDE 4. This snapshot is meant as a reference for developers who want to play with parts of the new technology KDE 4 will provide, those who want to start porting their applications to the new KDE 4 platform and for those that want to start to develop applications based on KDE 4. 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.
I’m anxious to try it, but I’m afraid that even though I know otherwise, the sheer unfinishedness would put me off at this early stage.
I guess I’ll wait ’til the next test, or preferably the Beta, especially since they haven’t got Phonon and Oxygen in place.
At least that’s how I read the rather confusing announcement… “While “Krash” marked the milestones initial Qt4 port, the use of DBus as inter-process-communication system, the merge of Phonon as the multimedia framework and CMake, KDE’s new buildsystem. doesn’t seem to be a complete thought.
I think it means that the “Krash” snapshot came with the, then following, list of milestones.
So from the API and infrastructure point of view the highlights of “Kludge” are Sonnet and Solid.
In case of API it should be understood that this is mainly about the code that makes the API presentable towards applications, work on the internals, e.g. Phonon backends, might still be done in separate branches and not included in this snapshot.
The idea about those developer snapshots is to have it working as far as the application develop is concerned, not necessarily as far as a user of such an application would be concerned.
DigitalAxis,
Phonon is already in KDE4 for a long time, since the second snapshot I believe.
I can’t wait for KDE4 to come out. Its good to see some of it in the wild. Keep up the good work.
I have installed on Suse 10.2 and I am having trouble getting the KDE desktop to load, I haven’t began trouble shooting so I will keep you posted!
I have installed on Suse 10.2 and I am having trouble getting the KDE desktop to load, I haven’t began trouble shooting so I will keep you posted!
That’s probably because the desktop doesn’t exist anymore (yet). It was killed off in favour of the krunner process, which does a lot of the things that kdesktop used to do: Run Dialog, CTRL-ALT-DEL handling, screensaver activation/screen locking, and so forth. This was previously part of kdesktop, but as plasma slowly comes online, kdesktop had to die (and kicker will too, eventually).
So these essential functions got moved out into their own smaller app. The reason they didn’t just go into plasma is that these functions require a certain degree of absolute stability to them… the screen locking process should not be able to fail, as this would be a security problem. Based on the planned extensibility of plasma, this would be harder to guarantee if it was bundled into this program.
So, no desktop for now, just a black screen that awaits plasma’s full arrival.
Very interesting piece of information for those like me who follow closely KDE 4 development, thanks very much !
Too bad there’s no way to mod you +6
Maybe these benchmarks will refute the unsubstantiated prejudice that KDE (Qt based) systems are slower than Xfce or GNOME (both DEs are GTK based) based systems.
http://www.phoronix.com/scan.php?page=article&item=650&num=2
…and KDE 4 is based on Qt 4.x which is significantly faster than Qt 3.x.
Well, I am talking about the GTK/Qt based systems as whole not the (mostly) subjective felt performance difference between a GTK and Qt based DE. In fact the benchmarks measure first of all just the DE independent performance of the entire system.
Edited 2007-02-24 03:33
First of all, what does that have to do with this article?
Second, unless I’m reading it wrong those benchmarks actually show Kubuntu as being the slowest, not the fastest.
Third, those benchmarks were incredibly stupid and mean nothing.
And fourth, I actually thought the common “unsubstantiated prejudice” was that KDE was faster than GNOME, not the other way around. Everyone knows how slow GTK is, don’t they? Maybe I’m wrong about that one, though.
Benchmarks or no, in all my experience with Linux across many different machines of varying performance, Qt is ALWAYS snappier than GTK+. KDE may take longer to load, but once it has, it’s not slow to use. Even on my ATI x300, there is still some slowness and non-snappiness with GTK+ based applications. But Qt applications are very responsive and redraw much faster than GTK+ ones (although I do use 2d compositing built-in to KDE, so redraw is no longer an issue, really).
Wow, those are the most silly benchmarks I’ve ever seen. Really… Whoever this guy is (didn’t bother to find out) he’s actually testing the kernel, and the differences you see are just by accident (assuming the kernel was the same, which is very likely…).
How do you test a GUI by compiling lame?!?!? WTF? You could test the startup time of the desktop, or the startup time of applications, or the responsiveness by trying to figure out how fast they redraw (tough one, btw, would be cool to see) but running a commandline tool (when the gui happens to be running)???
“http://www.phoronix.com/scan.php?page=article&item=650&num=2
…and KDE 4 is based on Qt 4.x which is significantly faster than Qt 3.x. ”
Perhaps, but there’s no way in hell you’ll come to that conclusion from that “benchmark” since:
a, the benchmark is between xubuntu, kubuntu, and ubuntu
b, it does not benchmark user interfaces components
xorg is changing at a much rapid pace now and is expected to be even easier to develop after modularization.
though ubuntu dropped out of the box support for ati and nvidia drivers, hopefully in a year they’ll be much better. esp. since demand (xcomposite and 3d effects) is growing.
kde4, when it gets out is going to have some nice companions to create a much better desktop experience.
Can Qt use libxcb for its back end instead of libx11?
This blog http://farragut.flameeyes.is-a-geek.org/articles/tag/xcb says that the next version of Kaffeine (0.8.4) is going to require xcb so that it can safely be used as a kpart. So I think it can.
It’s not Qt that’s using xcb but xinelib has been ported. In libX11 that ships with Xorg 7.2 xcb is already used internally by libX11 so all applications on 7.2 already use xcb indirectly.
Will we see some compositing in KDE 4? I’d very much like KDE4 to be able to work hand in hand with Compiz/Beryl. This possibility could lead to desktop even nicer than OS X. Btw, does QT4 rely on libcairo? Having everything drawn in accelerated mode could give some serious results!
Yes we’ll see a lot of compositing in KDE 4, Qt4 does vector graphics (SVG) but I don’t think it uses Cairo for that, I think it does on it’s own. Qt4 also supports real transparency for some part of the widgets, so we’ll have transparent panels and stuff like that, Plasma will do a lot of compositing too, and everything on the desktop shell will be based on Plasma I think (the panels, dock, widgets) and some other panels as plasmoids, and Qt4 have Arthur that will draw everything in accelerated mode I think.
Edited 2007-02-24 18:52
Yep. It doesn’t use cairo. It uses arthur which is reported to be much faster than cairo. There are a whole bunch of other nifty things that have been added to qt4 that I expect KDE4 to is since the functionality is already there.
Will we see some compositing in KDE 4?
Sure, you can already see some compositing also in KDE3
I’d very much like KDE4 to be able to work hand in hand with Compiz/Beryl
I think it already does, doesn’t it? One of the more recent KDE3 releases had improvements for interaction with the window manager part of the two mentioned “combi-managers”
KDE4 will even add a third option: its own window manager KWin can also act as a composition manager.
Btw, does QT4 rely on libcairo
No, but Qt’s respective part, i.e. the Qt drawing API is also designed to have multiple backends.
Having everything drawn in accelerated mode could give some serious results!
This is, for Cairo and Qt’s painting API “Arthur”, just a question of the available backends, i.e. the code that really implements the drawing.
Just using either API does not automatically result in accelerated drawing, in both cases it depends on the availability of such a backend and the capabilities of the underlying graphics subsystem.
if by “window composition”, there is an entire branch dedicated to working on this: kwin_composite. the kwin that comes with this snapshot does indeed do compositing and it’s a -lot- better already than what was in kde3.
however, they branched to do more experimental / less guaranteed to be stable stuff so as not to inflict that pain on everyone during that patch of devel. very thoughtful of the kwin hackers =)
from what i understand, we’re still a few weeks from that branch being merged back into trunk/ and then well start to get a better idea of the possibilities.
seli (lubos lunak) has blogged about progress in the branch in the past.
there’s also bits and pieces of the kde4 that are also composite-aware on their own; for instance krunner (which sucks in the snapshot, btw; you’ve been warned, and thank goddess this is just a devel platform release
uses an argb visual to paint its svg background into, so if the svg (loaded via Plasma::Theme from disk) has translucency it’ll be reflected in the run dialog.
moreover, we get compositing within widgets for “free” with arthur (as someone already mentioned) so we have the ability to do nice graphical effects in various contexts such as the new process list (in the process of that being integrated with krunner so that it pops up pretty much instantly, btw) and the new desktop layer.
hope that answers your question.. if not, ask more =)
Ok, I’ve got a question:
How much of KDE is actually being rewritten, as opposed to just porting to QT4?
I mean, it sounds like you’re in the middle of ripping apart and replacing the desktop- kwin, kicker, kdesktop and all; I know you guys have already dropped ARTS and are getting a new audio backend, and then there are all the rumored things you simply couldn’t do before.
I’m not a KDE developer, but I follow some of the mailinglist and developers blogs etc. So I’ll try to answer it, and I count on being corrected where I’m wrong.
How much of KDE is actually being rewritten, as opposed to just porting to QT4?
The most accurate answer are most likely, not much and lots.
It actually depends on how you define rewrite. Most of the work done in the KDE libraries are not rewrites from scratch, but changes to existing code.
Some changes are made to QT4ify, while others are fixes to known problems and such in the API. Changes and improvements delayed because they require binary incompatible changes. Other changes are based on new requirements and on knowledge gained during the KDE3 and KDE2 lifetime(Some parts are virtually unchanged since KDE2). And it’s changes KDE has to live with for a long time, so it’s important and require work to do it right. And after the changes are made, all places using it needs to get updated too. All this and the needed testing and verification takes time.
Not to forget that the developers continue to add new, and improve existing functionality to the KDE applications too. And in some cases even add whole new applications.
it sounds like you’re in the middle of ripping apart and replacing the desktop- kwin, kicker, kdesktop and all
I’ll say it’s more ripping apart and reasamble, than replacing. For kicker and kdesktop they are ripped apart and merged into the Plasma libraries, adding some inspiration from SuperKaramba. It’s mostly the visual parts being replaced, the underlying are in large parts based on the existing code. I guess aseigo could give more accurate description on that particular area
As for KWin the only thing reworked/replaced is the composite framework. You know the part of KWin in KDE3 that was responsible to bring you translucent/transparent windows. In KDE4 it will have the capabilities to deliver the fancy stuff you see in beryl/compiz.
all the rumored things you simply couldn’t do before.
Some of those would obviously be fixes breaking binary compability. Other kind of changes you can get a hint of if you look at the new or improved functionality provided by Qt 4.0, 4.1, 4.2 etc. Or if you try to see how some of the amazing new stuff Zack Rusin has bloged about in the last years can be used in KDE. I suspect much of that stuff is for KDE 4.1, 4.2 and onwards, the only thing I know is that KDE will continue to improve in an amazing way even after KDE 4.0.
Edited 2007-02-25 16:11
> How much of KDE is actually being rewritten
less than “most” and more than “a little”. =) i don’t have exact %s, but there’s been a serious amount of work ongoing.
> ripping apart and replacing the desktop-
yes.
> kwin,
no, kwin is “simply” getting a version bump. it’s not being rewritten, it’s being added to. if we were going to rewrite it, we’d probably just use beryl or something else that’s already being worked on. the huge amount of value in kwin’s development history makes it more than worth keeping and improving. the kde4 “version bump” will be pretty significant, however, what with the compositing abilities.
> kicker, kdesktop
yes, these two are headed for the bin.
> and all
a few more desktop pieces, but not nearly all of them. some will likely be re-fitted post-4.0 during the kde4 series as well.
> have already dropped ARTS
yes
> and are getting a new audio backend
no. what we’ve done is produced an API that can sit on top of any given number of existing backends. and it’s more than just audio, it’s video too. =)
> all the rumored things
more than just rumours =) sonnet’s language detection enables multi-language spell check in the same document, solid makes hardware awareness a breeze, decibel is bringing messaging integration to a new level, akonadi will help increase our mail/calendaring capacities, strigi+nepomuk get us exploring search and semantics …… etc. it’s all there in svn right now at various stages of development, but the important thing is that they are compilable and runnable right now. which puts it slightly beyond “rumour” and into “alpha”
[more than just rumours =) sonnet’s language detection enables multi-language spell check in the same document, solid makes hardware awareness a breeze, decibel is bringing messaging integration to a new level, akonadi will help increase our mail/calendaring capacities, strigi+nepomuk get us exploring search and semantics ]
Wow, a KDE dev!
Impressive.
KDE4 seems to be coming along nicely, doesn’t it?
http://dot.kde.org/1172438061/
Can you tell us a bit more (what is it and when) about strigi+nepomuk?
It seemed a bit too much like marketingspeak when I read about it here:
http://dot.kde.org/1172420257/
and I still don’t follow when I go here:
http://www.vandenoever.info/software/strigi/
or here
http://nepomuk.semanticdesktop.org/xwiki/bin/Main1/
Is strigi like the KDE4 equivalent of beagle?
http://en.wikipedia.org/wiki/Beagle_search_tool
They both seem to be part of something called Tenor in KDE4:
http://en.wikipedia.org/wiki/KDE#KDE_4
Can you shed some light what this will give us, from an end-user point of view?
I found some “thoughts” http://web.inter.nl.net/users/jospoortvliet/kde4/kde4.html
but nothing concrete as yet.
It might perhaps make for an interesting article for OSAlert, considering that desktop search is supposed to be one of the very few “must have” features of Vista.
Edited 2007-02-26 10:29