Submitted by Ars takes a look at the new RC2 release of KDE 4.0. “Transitions are always hard, but when the dust settles, a clean break between versions and an opportunity to introduce some innovative new ideas should lead to a stronger user experience. After years of development, unnecessary cruft builds up and things tend to get disorganized. The KDE 4 transition, though it will definitely be rocky at first, gives developers the ability to cut away the cruft and reorganize code in a manner that makes the whole environment more future-proof and easier to maintain.”
Ok, the window isn’t maximised, but looking at the screenshot of koffice, the working area of the document is 1/3 of the area of the window. Also, the Kontakt window is a mess of different zones that aren’t properly demarcated, I have to stop, and mentally draw in the dividing lines before the layout becomes understandable.
Apart from that, and the obvious text-box size issue, KDE4 is looking a lot more promising than KDE3
Well Koffice 2.0 is still in Alpha. [Insert lame, unfair, and gratuitous joke about KDE 4.0.0 being the same.] I’ve been toying around with the RC 2 and things are looking good– I’d definitely call the article fair.
The more interesting news for the day is the ‘official talk’ about an abbreviated KDE 4.1 cycle, and formally moving the 4.x releases to a time based schedule.
See:
http://lists.kde.org/?t=119756294400002&r=1&w=2
The discussion stated here:
http://lists.kde.org/?t=119732711500007&r=1&w=2
Realistically, the 4.0.x releases will all be transitional as the big 3rd party apps aren’t KDE 4 ready:
http://techbase.kde.org/Schedules/KDE4/Application_Porting_Status
and there are a number of apps waiting to go into KDE proper:
http://techbase.kde.org/Schedules/KDE4/4.0_Module_Status
(And you can tack on much of KDE Webdev, and KDE Pim as not for 4.0.0.)
With that being said, I’m still practically salivating for KDE 4.0.0…
Well I guess most times you’d have Kword maximised and than this would be a non-issue imo.
Why you may ask?
If you have a document in portrait format often a lot of space is wasted on the sides, while the top and bottom are cluttered with icons, menus etc.
The KWord-way still a lot of space is cluttered, but less is wasted. Though I see myself disabling the bar with the icons to open save … a document. I use shortcuts anyway.
Using the dimensions shown in the screenshots, and assuming that kword doesnt’ go into compact-mode when maximised (why would it?) a maximised window still has under 1/2 the Window area available for actual work. Add the sizeable taskbar/dock/thingie in, and you only have 45% of the total screen dedicated to work. Compared to Office 2007 where you get a 63% working area (going up to 68% when you zoom in to fill the working area).
That’s a 70% increase in working area, something that I appreciate greatly.
And yes, I did make sure that the Word2007 window was measured at the same resolution as the screenshot. Everything else was left to defaults.
Edited 2007-12-14 14:47 UTC
I have to admit that I never used Word 2007 so far and judging from screenshots Word 2007 still does waste a lot of space on the top and does not use the space to boths sides of the document.
Though I guess you are right, there is a lot of space for improvement.
But I’m confident.
Now look again. Then think. If you have one document open in a maximized window, the limiting factor is vertical space, not horizontal, especially on a widescreen. MS Office made the wrong call – save vertical space, and finally make good use of the horizontal space – this is what KOffice is going to do.
And it’s all resizable, stackable, dockable, floatable, hidable, whatever your needs and wants are. It’s the most flexible system you’ve ever seen, promise.
Flexibility doesn’t interest 90% people, me included. It takes too long to modify something to how you want it.
The trouble with kwrite is that it sacrifices both horizontal AND vertical space, with a mixture of toolbars, dodgy-dock, and panels.
“The trouble with kwrite is that it sacrifices both horizontal AND vertical space, with a mixture of toolbars, dodgy-dock, and panels.”
kwrite? you meant kate? Well, I think kate is fine. I am a fan of its multiple-document interface, but the hidable panels are extremely useful when you hack.
If you just need a text editor, kwrite will do.
EDIT:
oh, I missed the context. You meant kword!
superstone has commented nicely on that matter.
Edited 2007-12-14 22:00
The thing that really struck me is that the main K menu button isn’t in the very corner of the screen. From a usability perspective this makes no sense as the corners are the easiest places to click on a screen. Is the aesthetic appearance going to be affected that greatly just by making this simple usability change?
Yes, it looks like they went for a cross between a taskbar and a dock, and ended up with the worst of both
. Oh well, there is hope yet that they will fix KDE before the release
When KDE will feature WebKit instead the old and unmaintained KHTML+KJS? WebKit is the hot thing and is being ported to a lot of platforms, including Gnome and more exotic ones (BeOS/Haiku, MorphOS, AROS, SkyOS…).
I consider it a killer app and can help WebKit to being more ported to even more platforms, and making Firefox to improve a lot more or maybe change the engine to WebKit (I doubt it).
It has been posted over and over again KHTML is NOT unmaintained, is NOT dead. So would you guys stop spreading myths please?
It has been posted over and over again KHTML is NOT unmaintained, is NOT dead. So would you guys stop spreading myths please?
The trouble is KHTML is simply not going to render an awful lot of web pages out there, bugs have been closed basically asking web developers to change (which isn’t going to happen) and it simply isn’t the way forward.
That’s the material point that affects KDE’s userbase, and also KDE and Qt’s developers. In WebKit, most of the testing is done as part of a wider community that has some clout in terms of userbase and market share.
Edited 2007-12-14 21:30
I keep hearing conflicting information about what, if anything, is going to be done with webkit. There was a kpart that went unupdated, and unusable, for a while. That was about three or four months back if I’m remembering correctly. I stopped following the story sometime around then, and in the time since I’ve heard everything from it being moved into the official html rendering engine to it being pretty much tossed to the side, to almost nobody in the KDE project knowing either.
That’s because half of the KDE developers have decided it’s going in, and half that it’s not. I’ve never seen the KDE community so divided over a project before. It will definitely be in Qt4.4, though, which means it will almost certainly be included some ways in KDE4.1. I think Aaron Seigo mentioned it would be used in Plasma so that the OSX applets could be rendered. There are a lot of Konqueror developers who are dead set against it, though, and I don’t think anything is going to change their minds. In the end, I think you may have somebody fork Konqueror, unless they end up making the backend swappable. Then users will decide which one gets used.
Through KParts, the backend is already swappable. The webkit kpart isn’t quite ready to replace KHTML yet though. Eventually the users will decide what works best for them.
That’s because half of the KDE developers have decided it’s going in, and half that it’s not. I’ve never seen the KDE community so divided over a project before. It will definitely be in Qt4.4, though, which means it will almost certainly be included some ways in KDE4.1. I think Aaron Seigo mentioned it would be used in Plasma so that the OSX applets could be rendered. There are a lot of Konqueror developers who are dead set against it, though, and I don’t think anything is going to change their minds. In the end, I think you may have somebody fork Konqueror, unless they end up making the backend swappable. Then users will decide which one gets used.
I’m typing this from a KHTML Konqueror window, and yeah, the KHTML situation is a mess:
1) Because Apple’s PR talked a far better game then their ‘minimal licence compliance’ INITIALLY delivered. (That’s gotten better. See: http://lists.kde.org/?t=119647157600003&r=1&w=2 )
2) Some KDE developers announced plans very publically about KDE’s glorious Webkit based future before a consensus was reached. That lead to hurt feelings.
I think a ‘Dolphin Like’ plan for Webkit could be in order. Something like:
KDE 4.1: A non-default Webkit Kpart for Konqueror.
KDE 4.2: A standalone (like Dolphin) KDE Webkit browser based on the part.
KDE 4.3: Assess if Apple’s proclamations have lived up to reality and assuaged the fears of the KHTML developers enough to warrent making the Webkit Kpart and Browser Bits the default in Konqueror. If apple is playing nice, and the KDE Webkit supporters aren’t talking out of school too much, this shouldn’t be a problem for reasonable people.
With that being said, I don’t want my KDE based Web Browser held captive by a non-responsive upstream entity. (Be it Apple or Trolltech or Whomever.) KHTML works well for me. But yeah, the issue has ‘powder keg’ written all over it for those who’ve been following the bouncing ball…
Edited 2007-12-14 04:52
Pretty sensible. And as far as I can tell this is most likely the path which will be taken
I believe Zack Rusin mentioned that it will be in KDE 4.1
I must admit I don’t really get the concept of desklets (or call them whatever you want). Isn’t the desktop for something that you use, such as windows? It’s very good that we have them, but most of them would be very happy sitting on the panel (as they do in KDE3), taking very little space (or none, if the panel is hidden), and being there just a mouse click away?
I understand that it may make sense for 19+ monitors, so I am not speaking against them. I just found strange to support only them in the first release.
Also, I am not really familiar with the KDE 4 architecture, but wouldn’t it have been easier for them to define a “container” plasmoid type? The panel (and the desktop too) could be such a container, there is a way to resize the plasmoids anyway, so they would almost get the functionality of the panel in KDE 3 for free.
If this is possible, why is the panel so lame? If not… well, I hope there is a “hackless” way to get the proper panel back later.
Edited 2007-12-14 00:25
That’s actually exactly what they have done. In some of the screenshots that turn up people have asked why there are two battery monitors, why is that worth showing? Well, the answer is because if you look closely it’s actually the same plasmoid, one on the desktop and one on the taskbar.
AFAIK the container is also a Plasmoid in its own right, as well as being able to contain other plasmoids.
As far as I can tell, the panel currently being demonstrated has been knocked together quickly as a native plasmoid that does the basic panel stuff. It’s not the case that they intend the official KDE panel to be highly simplified, as the current one is, rather they haven’t spent much time coding on it so far.
Part of the benefit of Plasma is supposed to be that it exposes enough of the machinery of the desktop to make it easy for developers to extend the panel, so there should also be a decent selection of panel mods available to improve / change functionality and appearance, once themers / developers get a chance to hack on a released version a bit.
> I must admit I don’t really get the concept of
> desklets (or call them whatever you want). Isn’t
one day you will, probably when you actually see them in action on a plasma desktop and go, “omg, now i get it!” it’s one of those things that probably needs to be experienced for most people =)
“the desktop for something that you use, such as windows? It’s very good that we have them, but most of them would be very happy sitting on the panel (as they do in KDE3), taking very little space (or none, if the panel is hidden), and being there just a mouse click away?”
ah, but panels have many, many problems.
first, they are panels. they aren’t media centers, they are often too big for small form factor devices and they aren’t easily swappable about. widgets on canvases give us all of that… and more.
“I understand that it may make sense for 19+ monitors, so I am not speaking against them. I just found strange to support only them in the first release. ”
well, they aren’t supported “only” at all. and moreover, to support them at all with the flexibility and potential we have done so with, requires that this is built into the very frameworks themselves.
it’s like asking why a wheel must be round if all you want to do is turn it easily.
“Also, I am not really familiar with the KDE 4 architecture, but wouldn’t it have been easier for them to define a “container” plasmoid type?”
they are called “containments”, and they are also plasmoids and yes, that’s what we’ve done. and then some.
“The panel (and the desktop too) could be such a container,”
you really need to watch my screencasts. because then a month or so ago you would’ve gasped in delight.
“there is a way to resize the plasmoids anyway, so they would almost get the functionality of the panel in KDE 3 for free.”
yes and no. see, resizing a panel is a bit different. you don’t want to simply resize it freely (no, not really): you want to define an anchor point and expansion directions. it’s similar, but different. so the applet handles are being reworked to be panel appropriate.
otherwise, you’re on the right track.
“If this is possible, why is the panel so lame?”
it isn’t. you just think it is. seriously.
” If not… well, I hope there is a “hackless” way to get the proper panel back later.”
+5 obvious.
I used to be a devout KDE fan, but, lately I moved over to Gnome. At first I thought it was the simplicity of Gnome that got me, but looking at them screenshots, I now remember….. KDE is fugly.
And it is getting worse. Whats going on guys ?
Calm down.
Looks nice to me. I can’t live without the functionality of KDE anyway though. Even if I didn’t like the looks.
I assume it is an art and design mess because those things have been done by programmers thus far instead of skilled artists
You assume wrong. It has been done by artists for the most part. Here’s one of them:
http://pinheiro-kde.blogspot.com/
“KDE is fugly.
And it is getting worse. Whats going on guys ? ”
let me turn it around: you have no taste.
see? easy and fun.
realistically? artwork for the panel, dialogs, etc are in process this month. otherwise, i’m not sure what you think is more ugly. perhaps you could be useful and provide specifics.
I wouldn’t go as far as calling it plain ugly, but there are things that could be improved, both from usability and beauty perspective.
One thing that really hurt my eyes, is the lack of space between the K-button and the other icons in the panel. We can assume that this button will be used quite a lot, and a little more space around it would make it stand out more, and it would be less likely that people hit the icon beside it by mistake.
Why not add a descriptive text to such e.g “Controls” just like you have on other icons in the panel.
Another thing that disturbs me is that there is too little contrast between the window decorations and the application. I’m sure this can be changed in some setting, but it is always better to have good defaults.
I’m also not so sure that the borders of the plasmoids should look all that different from the borders of the window mangers window decorations. It is true the plasmoids and windows are different things from a developer/computer perspective. However, the question is if the computer illiterate user will see it that way.
No, I do not need to provide hints, after all, they are not designing it for me personally.
Instead, they need to have a plain framework that people can add to, these people can make their desktop fugly, but the default should be the building block.
I really like what I see in RC2, in that what is there is shaping up very nicely. I do want to see several things:
1) Centrally-defined cross-application shortcuts that really work. KDE3 did this better than any other environment I’ve used except OSX, with minor snafus. If it took what it did and then implemented consistent shortcuts for manipulating, say, tabbed windows, and preference options for that matter, it’d rise to the top.
2) More drag and drop control of the toolbar. I really want to just throw plasmoids into there without a second thought.
3) I want the old Mac-style menubar at the top. It is nicely consistent and wastes less screen real estate.
4) The plasmoid’s borders should only appear when you hit that wrench icon. They also need resize handles. Speaking of, the wrench icon could use some work itself.
That’s what jumped out at me. For an RC of a x.0 release, I find Coenig a bit too buggy – but also full of exciting potential. I expect this train to be gaining steam from this point on. The fact that KDE4 apps and the environment itself will be natively ported to OSX and Windows will net it a lot of extra fans.
Cheers, devteam!
Plasmoids in toolbars? You mean the panel? That’s coming. But I’d really like to see easier toolbar editing in apps as well. Something like what Firefox does in all apps would be nice.
> 1) Centrally-defined cross-application shortcuts
> that really work.
being worked on. probably 4.1 stuff at this point, though.
> 2) More drag and drop control of the toolbar.
*urrgggg* yes, it’s coming. that was actually the original seed idea that started me down the plasma path.
> 3) I want the old Mac-style menubar at the top. It
> is nicely consistent and wastes less screen real
> estate.
afaik, kwin still supports this. however, your “wastes less screen real estate” comment is completely bogus. i’l leave it up to the reader to determine why.
> 4) The plasmoid’s borders should only appear when
> you hit that wrench icon.
and then how would you get to those borders? or discover them? or turn them off? hover interfaces are the future.
> They also need resize handles.
there’s already a resize tool right there.
> Speaking of, the wrench icon could use some work
> itself.
yeah.
“afaik, kwin still supports this. however, your “wastes less screen real estate” comment is completely bogus. i’l leave it up to the reader to determine why.”
Well, it wastes less space because you don’t need another line in every window with the menus
I hardly use the menus, everything is done by key shortcuts so… what do I need the menus for?
Damnshock
Then you should probably use that shortcut as well: Crtl + M
(if it has been set)
There, you have even more space!
Use than in kmail and see what happens… guess what… nothing!
OK, Kmail as well as a lot of other programs as I see do not support that, Konqueror, KDevelop etc. do. I only stumbled over that command by accident.
Maybe they’d implement that if we would ask them.
I know it’s more a hack, but you could save space if you’d use the programs in full screen mode and force those that do not support that to be in full screen.
You could even deactivate the window border for some programs/windows (for moving around windows without border press Alt + left mouse, with Alt + right mouse you can make the window smaller/larger).
For that right click on the border choose “advanced” (my KDE is not in English
) and there “special settings for the window”. Now you can choose fullscreen on initialise (do not forget to tick it).
If you want to change that open kcontroll go to “Desktop”? and “window specific settings” now you can either delete or modify the settings.
“Well, it wastes less space because you don’t need another line in every window with the menus
”
Well, it does not matter where the menu is, it takes the same amount of vertical space. So, unless you tile two window vertically, it does not make a difference.
Plus, you can hide the window bar by pressing ctrl-M if you put it in a window. However, if you put the menu on the top, when pressing ctrl-M, the menu is hidden, but the space is not reclaimed.
God, I’m getting tired of repeating.
Not all apps support hidding the menus!
And, in fact, you DO waste less space if you don’t have any panel, just the menubar with a systray or whatever you want on it
Thanks for the reply, aseigo, I do really like KDE.
As to this, open up three or more windows of any type that would have their own menubar, especially if they’re all the same, and compare the space involved to a single strip at the top. Also consider the relative speed of putting the mouse pointer at a corner of the screen. I don’t say imitate the Mac for the sake of imitating the Mac, but KDE’s support for this thus far has been a plus.
http://www.thecodingstudio.com/opensource/linux/screenshots/index.p…
This is the list of code name candidates for the next release:
* Vista Wanna be
* Over hyped
* Nice Try (My favorite)
* Terrible faillure
* Misserable Faillure
* Not really, waith another 6 months.
* My ego is bigger than yours.
Vote for your favorite at: dot.kde.org.
hey don’t vote him down, is just a joke:
here is the repost.
This is the list of code name candidates for the next release:
* Vista Wanna be
* Over hyped
* Nice Try (My favorite)
* Terrible faillure
* Misserable Faillure
* Not really, waith another 6 months.
* My ego is bigger than yours.
Vote for your favorite at: dot.kde.org.
Edited 2007-12-14 02:46
People in here are not in favour of sockpuppets…
At least as far as the interface is concerned, this is not a *bad* start. It’s certainly a lot better than what I saw in earlier screenshots, but it still has quite a ways to go. The icon theme at least, though still not my taste, is a lot better and a lot more complete, and the interface theme is… usable.
I always preferred KDE to look as plain as possible: a square theme and simple shading always worked better than the fancier themes. There were always icons or text cut off in my experience, and it just didn’t *mesh* as well as a square theme. Maybe it’s just one of the tradeoffs of having such a flexible desktop, where almost anything can be embedded in something else.
KDE 4 (SVN) from some days ago
http://img133.imageshack.us/img133/6977/kde4svngr5.png
Just release 4.0 in january. Then really complete it in the next few months and have 4.1 ready for all the distro realeases from april onward.
Then adopt a 6 month release cycle so that all the distros become testers of your releases.
I think that would be a good thing(tm) even if releases have less features because it is better to have 3 releases with 10 new features than have two with 15 because the 30 features from the 6 month cycle will be way better tested.
Release early and release often
Just my 0.02EUR
(BTW Mighty Mark Shuttleworth said so too )
apart from not being *nice* in the beginning, what did apple do to make khtml’s situation worse than if apple had never taken khtml as the basis for webkit? did they attract away developers?
It’s obvious that the plasma stuff looks really good. The sshot posted earlier: http://img133.imageshack.us/img133/6977/kde4svngr5.png shows that.
However, the new Oxygen theme DOES NOT. And I’m not the only one to think so. Will you guys take care of it? It looks really ugly with ALL applications I tried. It’s just a bad theme and you guys have to admit it. Keeping this theme around is a huge mistake. It’s too white, it lacks proper contrast and it doesn’t look good at all. Please do something about it. Maybe you should unify the look of the plasma stuff and the theme? I mean, the plasma stuff looks really good. Why not create something around it? I’m not saying that it should look like the plasma stuff because it really shouldn’t (it would use too much black). But…
Use a different colour scheme. The default colour scheme is still going to change before release.
Did that. However, with the 2 color shemes I tried (the 2 that don’t use unusual colors for widgets), it didn’t help.
And the choice of colors isn’t the only problem of Oxygen. It’s just not sexy. The widgets are dull and boring.
I think again it becomes clear how much a matter of taste this really is. Personally, I’ve really felt in love with Oxygen. Imho, it’s the best looking theme available on the computer desktop right now – even with its still very apparent flaws (contrast being one of them).
agreed.
aim for 4.1 in the May-June timeframe, because I want to be running KDE 4.1 in opensuse 11.0 when it comes out in June-July.
We do aim for 6 months after the 4.0 release, yes.
I know it’s futile but it would looks so much better if the theme was more integrated (white/grey windows with everything else black? eww). It needs some more antialising on fonts and windows corner/widgets, and window/cursor diffused shadows would give it a far more polished aspect (whatever you think about it, look at what OSX does in this concern, it looks really good)
Not a bad start at all
(as far as bling is concerned hehe)
After following the development for KDE4 and the sites which usually cover development related news (e.g. dot.kde.org, osnews) for some time I’ve come under the strong impression that many people outside the developer community expect 4.1 to contain all the missing pieces to reach feature parity with 3.5 or even surpass it. I doubt that all the missing features can and will be implemented in 2-3 months of feature development time. What was once planned for the next big release will be suddenly delayed to 4.2 due to the short release cycle and the same people now pushing for an early release of 4.1 will be the ones complaing that 4.1 didn’t deliver again what was promised.
The arguments on the release mailing list for a 9 months release cycle sound far more sensible from a development point of view (more time for feature development/testing, being in sync with Qt development) than trying to let distributions dictate the release dates. Of course, Qt 4.4 is scheduled for early 2008 so I guess they would have to make an exemption for 4.1 and start the new release cycle afterwards (4.2 released about the time of Qt 4.5).
I think a 6 months schedule makes sense. KDE 4.1 will be based on Qt 4.4, which have been available by then for a while. Syncing with Qt, releasing 4.1 at or around the time Qt 4.5 is out doesn’t sound very easy to me – we would have to track Qt development very closely, with all the bugs it might contain blocking us from doing what we need to do. I’d rather build upon a released Qt version, and release a new KDE version shortly before a new Qt comes out so it can then be used for the next KDE version.
I do get your point about “you guys won’t have time to implement what you want for 4.1” and I think it makes sense, but on the other hand – I think with all the help we’re getting (KDE’s developer base is growing very fast right now) we might make it. And if not, a small delay won’t hurt
I want KDE and Gnome to be successfully having options is what OpenSource is all about. KDE is a nice desktop manager, I mostly use Gnome but sometimes I switch depending on what I am doing.
Plus, KDE has some really slick tools such as krdc for starters, and serveral others I could not name them all…
I’m a GNOME user that will probably _never_ user KDE, not even KDE4, because I personally think it’s ugly and not very usable. That’s a personal opinion, mind you.
None the less, I admire KDE’s work and I think it is a great addition to the Free Software desktop. KDE 4.0 may be less fuctional than KDE 3.x, but with time that will change. If you remember GNOME’s transition to 2.0, this is the same. GNOME 2.0 is one of the worst Desktop Environments _ever_, but it opened the door to the beauty that is GNOME 2.x now.
KDE4 is _not_ KDE 4.0. KDE 4.0 is just the beginning to a very pleasant journey towards the _real_ KDE4.
I just hope it won’t take us 4 or 5 years to make KDE 4 as good as 3.5 was
Hopefully, we’ll match 3.5 in 6 months, and start kicking some corporate asses (think MS and Apple) soon after that. With the surge of new developers joining KDE lately (eg during the last year there was and still is a rush of new hackers) the Free Desktop will finally be able to surpass the proprietary competition in a meaningful way. Finally…
Surprisingly the mock-ups for windows 7 look very KDE4 like. Is this a coincidence?
I’m pretty sure they’re watching us closely – during the period of brainstorming about KDE 4 (little over a year ago, I guess) it happened frequently ideas we were talking about appeared in Longhorn and Mac OS tiger a week later. Aaron even stopped talking about some stuff…
Yep I’m sure ideas you were talking about managed to get implemented in a week.
Some stuff not, some, yes. Not everything takes months to write, even for MS and Apple…
A good example is the ‘layer’ Apple has for its widgets (though I wouldn’t say they stole it). We’re gonna hear we copied their stuff, while Aaron has been talking about bringing the widgets via a transparant layer on top of the windows long before Apple came up with it…
FTFA: “Although the release candidate has many rough edges and is significantly lacking in polish”
How can this be a release candidate with this as the case?!
The same way that Apple released Mac OS 10.0 as little more than a public beta and continued to ship Mac OS 9.x alongside it and I believe that Apple actually defaulted to OS9 when booting their computers until the release of OS 10.1. The same will likely happen with KDE 4.0. It will ship alongside KDE 3.5.x and in fact I believe that you will be able to run KDE 4.0 applications alongside KDE3 apps the same way that you can run GTK+ and GNOME applications alongside QT and KDE apps. So you won’t even have to have separate boots to gain some advantages from the new version.
KDE 4.0, just like Mac OS 10.0, is showcasing the advanced technology that will be used to build up the KDE4 and likely KDE5 series over the next 5-10 years. It will be similar to the path that OS X has taken starting out as not much more than a public beta and eventually becoming something extraordinary and outstanding and capable of winning the masses over to GNU/Linux/FOSS. Also like Mac OS X and GNOME the KDE devs will be able to add APIs without needing a drastic overall thanks to some very wise but painful changes that have been implemented in KDE4 such as the Phonon and Solid APIs.
The only thing big piece left is for a FOSS Direct X equivalent.
There is SDL.
http://libsdl.org/
I like the layout in Dolphin. Very much like NeXTSTEP (or Openstep or GNUstep). Only the scrollbars are still positioned in the wrong side