In his lengthy and interesting blog post covering the future of Plasma, KDE's Aaron Seigo proposes Qt Quick and QML (a declarative language that embeds JavaScript) as replacement of the Graphics View architecture currently used by Plasma. This holds a promise of massive speedups and cheap effects as all paint operations become candidates for OpenGL acceleration, contrary to the aging Graphics View architecture that is still stuck with various inefficiencies caused by the underlying QPainter approach. Expressiveness and easy programmability of QML is a nice bonus, of course.

So, after 4 years of almost getting there, now we are going to see another two years of new overhault, more testing, more crashings. Just to use QML. And after those two years who knows if another change will be nessesary.

Will they ever settle up a stable API? a stable desktop?, not in the following two years.

Those same sentenses were told when QGraphicsWidget was released, now result that QML is the one. And after that who knows, Im glad you are so optimistic, im not.

first off, we're already moving to QML. some parts started on QML (e.g. the Plasma Mobile shell and some of the mobile specific components). QML renders right now on top of QGraphicsScene, so it hasn't been a shift for us in that respect. the real shift is moving away from QGraphicsScene to QSceneGraph, which in turn will require (in all practicality) all Plasma components to use QML (right now we can pick and choose which do). but that's a decision that is still 1-2 years out, and in the meantime we continue to work on what we have done right now.

it's also useful to consider QGraphicsScene's path thus far: it absolutely was a large improvement over what we had prior to it, and due to its design (and how we used it in Plasma) moving to QSceneGraph as well as QML is relatively straightforward. it is nothing like what we had to go through to get a scene based component system (aka Plasma) together in the first place.

i don't know if QML will be the "final" answer in the long term (5-10 years), but it is a move in the right direction and provides us a way to get more out of what we are already doing.

as a comparison, QGraphicsScene debuted 4 years ago and was in development for probably a full year before that. it'll still be what we're using, with improvements being made to it, for at least the next 1-2 years. so if Plasma does move to QSceneGraph, then we will have had 5+ years of service by QGraphicsScene and the benefits it brought us.

i'd expect at least that (if not more, as it embodies lessons learned from QGraphicsScene) from QSceneGraph.

given that the migration path to QSceneGraph is fairly evident at this point and can be done pretty smoothly for us, i think it's a reasonable situation.

and at the end of the day, the vast majority of API and code in plasma itself will remain untouched due to clean separations between visualization and business logic.

The fact that all plasma widgets will have to be migrated to QML eventually or not is a lot of change, a lot of work, alot of testing, a new start over, is like admiting that the things were wrong in the beginning and now have to be corrected, tha impact is not only on the visual side, but also in the python and ruby bindings and if you say is doable it may be, but not w/o a lot of work and testing before. So it feels so frustrating that now may be mandatory to write plasma widgets in QML, and throw away many invested time.

I think it sucks when you don't control the toolkit and the one who controls it makes these low moves that makes you change lots of stuff.

Time will tell, In a couple of years will see how it goes and how mutch was won or lost in that period.

The fact that all plasma widgets will have to be migrated to QML eventually or not is a lot of change, a lot of work, alot of testing,

yes, it's a fair amount of work. which is why i'm giving us up to 2 years to get there. that gives us enough room to work on other things as well and not rush.

a new start over,

it isn't a new start at all. a lot of code is re-usable, and the code that uses QPainter should get a lot simpler with QML.

is like admiting that the things were wrong in the beginning and now have to be corrected,

the design of libplasma when it comes to things like DataEngine, Service, Applet, Corona, Containment, Svg, FrameSvg, etc. all stand without change in this. it's a change in the presentation layer, and yes, it is admitting that what we have now is not as good as it could be. that also doesn't mean what we have now is crap, just that we can make that part of it better.

tha impact is not only on the visual side, but also in the python and ruby bindings

there are significant implications for the python and ruby bindings, yes. finding a way to make QML work nicely with them is not a solved matter at this point, but it also isn't a problem that anyone has looked into extensively either. that's something that is only starting to be done.

i do think it should be possible, but then again .. there is a reason i've been encouraging people to move to Javascript for Plasmoid development.

and if you say is doable it may be, but not with a lot of work and testing before.

those costs are why we are looking into this early (QSceneGraph isn't in Qt yet and its exact future is still under research; QML is brand new and libplasma will only have deep integrated support for it in KDE Platform 4.6). it's not a light set of decisions to take.

So it feels so frustrating that now may be mandatory to write plasma widgets in QML, and throw away many invested time.

the good news is that we have a couple of years to do this in. personally, if i was working on a plasmoid, i'd make the move to QML when i wanted to do some work on the user interface presentation, meaning it would be already some of the work i'd be doing.

I think it sucks when you don't control the toolkit and the one who controls it do this low moves that makes you chang lots of stuff.

we aren't forced to move to QML or to QSceneGraph. they are new options, and they are compelling enough that we are electing to use QML more and more and investigate QSceneGraph as a serious future replacement. nobody is forcing our hand. we're also involved with the toolkit below us.

similarly, people writing Plasmoids today can continue to not use QML in the near term. so these changes aren't forcing any changes in the immediate.

it's very important to me that we retain as much effort as possible put into plasmoids that exist (there are hundreds and hundreds of them out there) and make any migrations as easy as possible.

one part in achieving that is sharing our decision making processes early and openly. plasmoid developers should feel very welcome in joining in on that conversation.

Time will tell, In a couple of years will see how it goes and how mutch was won or lost in that period.

I agree with many of your concerns, however the duke nukem comparison is out of line. There is a huge difference between vaporware that never gets released, and software that is continuously improved and released.

Kde 4 today works great ... when it works. When it doesn't work, it doesn't work too well. I wouldn't describe it as unstable, maybe just less stable than other desktop environments. Part of that is just the maturity of the code base. It also concerns me that the existing core is being changed, but it sounds like a lot of the framework will remain intact. Maybe it won't be that much of a change, but it still has the possibility of removing focus from the small tweaks and bug fixes to the deeper changes.

The fact that all plasma widgets will have to be migrated to QML eventually or not is a lot of change, a lot of work, alot of testing, a new start over, is like admiting that the things were wrong in the beginning and now have to be corrected, tha impact is not only on the visual side, but also in the python and ruby bindings and if you say is doable it may be, but not w/o a lot of work and testing before. So it feels so frustrating that now may be mandatory to write plasma widgets in QML, and throw away many invested time.

QML is relatively new on the scene. It wasn't available in Qt until Qt 4.6 (released in 2009) - and even then it was an add-on that had to be installed separately, and now it's a native part of Qt as of 4.7 - released right at the end of last month (09/2010).

So to say that it's like admitting that the things were wrong in the beginning and now have to be corrected would be false since it wasn't an option when they started.

In other words, they're trying to evolve the platform as Qt evolves the platform, taking advantage of new features as they become available instead of years afterwards.

That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).

That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).

When QML is used with QSceneGraph, the performance will be really good as it will take advantage of the computer's hardware 3D acceleration. So by seperating code to manipulate data written in C++, from the visualization part in QML, you will make your app run faster.

That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).

Do you have citation for that?

Perhaps you are confusing using QML with doing heavy calculations with JavaScript inside QML. QML is being pushed specifically for high-FPS 2D user interfaces - this use case is pretty different from 3d games. You should do heavy calculations in C++, and let QML take care of the UI parts of the program.

"That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).

Do you have citation for that?

Perhaps you are confusing using QML with doing heavy calculations with JavaScript inside QML. QML is being pushed specifically for high-FPS 2D user interfaces - this use case is pretty different from 3d games. You should do heavy calculations in C++, and let QML take care of the UI parts of the program.

Plasma Mobile already uses QML and the general libplasma QML integration for use by Plasma components (e.g. plasmoids) is already being merged into trunk for 4.6.

from there we can migrate, at our own pace, one element at a time from QPainter to QML.

only once all of that is done do we need to (or can, for that matter) look at slimming out the then-unused portions of libplasma.

once that is done, we can then make the further decision of if/when to move away from QGraphicsScene and over to QSceneGraph.

it is all one step at a time, we are able to stop at any point it doesn't make sense to continue down that path and we can happily wait while using QGraphicsScene for QSceneGraph to be where we need it to be. if QSceneGraph takes longer to properly mature and move into Qt than it does for us to move Plasma components to QML, that's not a problem. (and vice versa)

that's one of the best things about this set of changes: we are able to go at our pace, migrate one item at a time (and we should get some nice improvements while doing so, even when still on QGraphicsScene) and make the hard decisions when the time is right. there is no forced decisions, no required jumps (even while we do the necessary work to be able to make such a jump) and no API breakage required until we do make that jump.

so while it will be quite a bit of work stretched out over the next 1-2 years (in addition to the usual new feature development, stability and bug fixing we do), the disturbance to the user and 3rd party developers should be very minimal.

and that's not an accidental situation, it's the result of a set of very deliberate design decisions made both in Qt and in Plasma. migration has to be uncomplicated, paced and safe. not just for Plasma, either, but for any Qt based app that wishes to do similarly.

So, after 4 years of almost getting there, now we are going to see another two years of new overhault, more testing, more crashings. Just to use QML. And after those two years who knows if another change will be nessesary.

Will they ever settle up a stable API? a stable desktop?, not in the following two years.

I couldn't agree with you more and will probably get modded down for this, but it is the very reason I moved to gnome as I was sick of the KDE team pissing about.

It might be fun for them to try out new technologies and make radical changes, but I am an end user and I need something stable to work with that doesn't crash.

KDE has a stable API. Plasma on the other hand is a moving target sometimes, but plasma is an application not an API.

Being "in motion" is both the strength and weakness of plasma, and why I love it and disapprove of the development model at the same time. Aaron has excited a lot of new developers, bringing new blood into KDE. We would never have accieved this much without this boost, but the price comes at focusing plasma on art, creativity and innovation and not the old KDE tradition of "just make it work".

Still plasma at this point works, and if the art becomes too much you have the options necessary to tune it down. It is not even the "old guard" who have installed these, the options to turn plasma down a notch mostly comes from within the plasma sub-community as they are slowly getting more and more awesome.

I could vent my fur(r)y over the young whippersnappers working on plasma, and tell them to "get of my lawn", but that is so 2007. At this point in 2010 plasma works much better than kdesktop and kicker ever did, the only minor issues have been that nvidia have moved from being 2-3 years behind in XOrg tech to now being 5-6 years behind. You can avoid that problem by using the open source nouvea drivers now.

Indeed, but the resources taken for that migration are gonna be needed in other interesting and imho parts that needs to be priority that already has been delayed to mutch.

I don't forget that QML is the "me too" answer to Adobe Air, Java FX and MS WPF, and all those three technologies stayed just on the hype, I don't think QML will be different, anyway, the best of luck.

Indeed, but the resources taken for that migration are gonna be needed in other interesting and imho parts that needs to be priority that already has been delayed to mutch.

not everyone will be working on this (in fact, just a few will be, most likely). others will continue their work on things such as activities and what not.

what parts are you concerned about not getting the necessary attention?

I don't forget that QML is the "me too" answer to Adobe Air, Java FX and MS WPF, and all those three technologies stayed just on the hype, I don't think QML will be different, anyway, the best of luck.

it's really not so much an answer to Air, WPF, etc. as it is a similar kind of solution to an increasingly common problem. one very major difference with QML is that it isn't a platform that is being created with the hopes of luring app develpers to, it's a new tool being added to a framework app developers are already using.

as a result application developers are already using QML (Kontact Mobile and Plasma Mobile to name two from KDE; i'm aware of others, but will let them announce for themselves . it's also being used by platform developers such as MeeGo. this essentially prevents it from becoming "hype only" since it already has an audience which is already starting to use it. it's a significant difference.

regardless of whether QML takes over the world or not, it is starting to give us already using Qt some much needed tools that we've been missing. and that's enough for me

Java FX, Adobe Air and WPF are also used by people, just not most people who still work with the legacy methods offered by those companies: Java, Flash, and Win32/Winforms. it wouldn't be surprising if QML is similarly underused by QT developers.

what parts are you concerned about not getting the necessary attention?

This is a bit of a late post, and I'm not the person you were replying to, but the state of kdepim does concern me. I haven't heard any updates from them on planet kde, their website (pim.kde.org) hasn't been updated since February 2008, and Gentoo is still blocking KDE 4.5 until there is a 4.5 pim release. What's going on there, anyhow?

I don't forget that QML is the "me too" answer to Adobe Air, Java FX and MS WPF, and all those three technologies stayed just on the hype, I don't think QML will be different, anyway, the best of luck.

Spoken like someone who hasn't had worked with any of those technologies.

I used to develop multimedia applications in WPF. I could build complex user interfaces in WPF in a fraction of the time it would take using a more traditional framework.

WPF, FLEX, and now QML truly allow designers to get more involved with the development process. On of the best developers I've worked with was a XAML (WPF xml) guru who couldn't write a line of code in any language.

If you want to develop ugly boring business apps, the go ahead and code in MFC or Winforms.

Is WPF needed for business applications? No, especially when most desktops are still running XP. Winforms to WPF is expected to be a very slow migration. Not only have most companies built around Winforms but a lot of small and indy developers will continue to use Winforms since it leaves the option of porting through Mono.

I don't forget that QML is the "me too" answer to Adobe Air, Java FX and MS WPF, and all those three technologies stayed just on the hype, I don't think QML will be different, anyway, the best of luck.

I can't speak for Air or FX but WPF is definitely not riding on hype. WPF vs Winforms is debated endlessly in .net forums but everyone agrees that WPF comes with discernible benefits. Very few would suggest using Winforms if the targeted audience is Windows7/Vista users.

You also can't expect an explosion of applications immediately after a new framework is released. Software takes time to develop and for a lot of applications it isn't cost effective for the company to switch over.

Some key benefits of WPF only work with Win7/Vista so WPF will become more appealing as the XP market starts to shrink. Give it some time, WPF applications are on the way.

Despite the fact that you are a huge troll and i dont like feeding trolls, i have to answer.

KDE is among biggest FOSS projects and is seriously used worldwide. However, its one of the few projects which are brave enough to be early adopters of new technologies. And also take part in developing them.

Since the beginning everyone complained why FOSS always 'follows' and never takes the lead.
Well, guess what, it takes some courage to develop new technologies and use them, before anyone else does.

Despite the fact that you are a huge troll and i dont like feeding trolls, i have to answer.

A huge troll that until the KDE4 debacle, used to enjoy KDE.

Nice to see that the standard FOSS answer to everything is still to label people as trolls. Perhaps that's why 99% of computer users are just trolls and wouldn't touch an open source desktop with a ten-foot pole.

"Despite the fact that you are a huge troll and i dont like feeding trolls, i have to answer.

A huge troll that until the KDE4 debacle, used to enjoy KDE.

Nice to see that the standard FOSS answer to everything is still to label people as trolls. Perhaps that's why 99% of computer users are just trolls and wouldn't touch an open source desktop with a ten-foot pole.

Keep it up, you're doing just great. "

If you used to enjoy KDE, then why wouldn't you enjoy it now that it is better and more powerful than it has ever been?

Your response seems like pure deflection to me. You got accused of trolling so your best method of defense is attack, hey?

People are too smart for you. If they can run great software like KDE, have great performance and functionality for free, be free from viruses and malware, run a copy on as many machines as they please without fear of being pestered about licenses or plagued by endless adware, then they will go right ahead an do so, enjoy the benefits, and pay no heed at all to your silly debating bluffs.

KDE 4.0 was problematic, and the change in attitude turned some people of. I personally believe people turned off by the first 4.x release should give the new ones a try. (Ditch the crappy nvidia drivers first though, or you will be disappointed.. but there is nothing KDE can do about NVidia's unusually crappy binary drivers).

Yer I know. It's the only open source desktop competing with the proprietary competition on development and the frameworks they have at their disposal. When it isn't done open source desktops are playthings no one can use and when someone attempts to move things forward people shout that things should stay the way they are.

It's the only open source desktop competing with the proprietary competition

Precisely. This, and this alone, is the reason why you get such a lot of spiteful hate-filled criticism of KDE ... you can tell this because when you boil it down and analyse what is actually being criticised ... it is nothing.

KDE is criticised only because commercial software interests need it to be criticised.

KDE is criticised only because commercial software interests need it to be criticised. Even F/OSS proponents who criticise KDE4 do it because commercial software wants them to do it? Lolwut?

There are a lot of people who do not have much more to say other than "me too". These people are not the ones who set the direction of what is discussed, and what is not.

There are too a number of people who pretend to be F/OSS proponents but who really are not. There is even an entire website dedicated to presenting articles about F/OSS but which somehow always seems to conclude that F/OSS is lacking in some way. I have in mind the site called Linux Insider.

All that you need to look at is what KDE is criticised for, and what about KDE is ignored. You might for example get a review and pages and pages of discussion about the design of KDE notifications and the gripe that an icon does not quite line up horizontally with the notification message or somesuch ... at yet there will be no mention at all in reviews that the KDE photo manager/editor application digikam is considerably better than FSpot in every way, or that K3b has been better for many a year than any GNOME desktop CD/DVD burner. You might get an article about the "inadequacy" of Linux PDF viewers that talks about Evince and XPDF, but entirely ignores Okular.

What gives with that? Why is it so? Who is driving the discussion along the lines of absolutely trivial and often plain incorrect criticism and bitching about KDE, and almost complete suppression of mention of its benefits and advanced features?

"KDE is criticised only because commercial software interests need it to be criticised. Even F/OSS proponents who criticise KDE4 do it because commercial software wants them to do it? Lolwut?

There are a lot of people who do not have much more to say other than "me too". These people are not the ones who set the direction of what is discussed, and what is not. There are too a number of people who pretend to be F/OSS proponents but who really are not.

All that you need to look at is what KDE is criticised for, and what about KDE is ignored. "

This article purports to be a "review" of Kubuntu 10.10 but in effect all it says is that Kubuntu 10.10 is OK I suppose but"I found these six things which I didn't like". None of the criticism is actually correct. There is much uninformed discussion that ensues about the six things. There is an almost complete oversight of the actual quite decent KDE desktop in Kubuntu 10.10.

Sigh.

The very last user comment I feel sums it up nicely even if it is worded a little clumsily:

I get only impression from this article that the person is a gnome user and a nitpicker on person preference. Just try Kubuntu. I spent years bashing this distro to come back and see the flawless work and effort put into it. In my Opinion of just not using it for little and/or being a Gnome only.I for one use equally Gnome and KDE. I found it is Ubuntu that will need to catch up to Kubuntu. Even on distrowatch kubuntu with all the negative reviews of the past has hit 1k+ 7th place mark(that with there backpast history is a milestone. All I can say is Load it. Try it. The distro Speaks for itself.

Kubuntu FTW hands down.

I am using KDE 10.10 using Firefox, Running dual moniters, EVEonline, Wow, printing service with HP since beta without a single flaw and low system resources used. Little more the Gnome, But to sweet to pass up

All that you need to look at is what KDE is criticised for, and what about KDE is ignored. You might for example get a review and pages and pages of discussion about the design of KDE notifications and the gripe that an icon does not quite line up horizontally with the notification message or somesuch ... at yet there will be no mention at all in reviews that the KDE photo manager/editor application digikam is considerably better than FSpot in every way, or that K3b has been better for many a year than any GNOME desktop CD/DVD burner. You might get an article about the "inadequacy" of Linux PDF viewers that talks about Evince and XPDF, but entirely ignores Okular.

What gives with that? Why is it so? Who is driving the discussion along the lines of absolutely trivial and often plain incorrect criticism and bitching about KDE, and almost complete suppression of mention of its benefits and advanced features?

This is something that has been bothering me for a while as well. There are many cases where KDE and/or Qt applications are clearly better than the competition but online reviewers somehow manage to completely ignore them. And despite people trying their best to set the record straight in the comments section, when one is available, these "articles" and "reviews" keep coming up with the same old glaring omissions and the same old rehashed complaints about KDE faults that in some cases no longer apply or are not even valid to begin with!

Even worse is the trend of crediting Ubuntu for *everything* that happens on the Linux desktop, completely ignoring that other Linux distros have pretty much the same feature set and in some cases, as in with Fedora, having them before Ubuntu.

From the things that actually are unique about Ubuntu, the stuff that Canonical itself actually develops, the only thing that I can think of that is worth something is Ubuntu One - which can be easily replaced with Dropbox to some extent so no biggie there - and the integration of Rhythmbox with 7Digital's music store which is nice despite me not being a Rhythmbox user and Canonical's complete failure to integrate other music players such as Amarok in the same mold.

Funny thing is that even though I find KDE the best looking and more powerful DE out there, I am not even THAT biased towards KDE/Qt applications and will happily use GNOME/GTK applications when they're clearly better - GIMP, Audacity and Inkscape for instance - but these trends I discussed above and your observation have been really disturbing...

I am not sure we're talking about the same thing here. The way I see it, there are mainly two high profile writers out there that judge KDE fairly on their reviews, giving brownie points when it gets something right and calling the developers on it when it gets something wrong. These are Joe Brockmeier and Bruce Byfield.

Byfield's reviews tend to be as neutral as possible to the point that it becomes annoying to read them sometimes, but they are usually fair, pretty balanced and reasonably accurate even though one can easily spot faults here and there every now and then. Brockmeier was formerly community manager or some such for OpenSUSE which is, by most accounts, a KDE-centric distro so he might have a little bias there but his articles related to both GNOME and KDE and its applications look reasonably fair to me, for what it is worth.

Most other reviewers and columnists appear to evaluate KDE based on what they can get from Kubuntu or Ubuntu with the kubuntu-desktop meta package which, frankly, sets the bar pretty low. It is not a big secret that KDE is not exactly loved over there in *buntu waters and it shows. Even smaller profile distros such as SimplyMEPIS can claim to be a lot better than any of the *buntus as far as KDE is concerned.

Heck, recently I engaged on an online discussion on someone's blog because he/she was claiming the upcoming GNOME Shell Activities as the pinnacle of usability and a revolution on the desktop "when it arrives" especially when compared to previous iterations of KDE's Activities disregarding completely the fact that Activities were completely revamped on KDE SC 4.5 and that the ground breaking work that the KDE developers did when taking the plunge and going ahead with their plans to implement said Activities back when KDE 4.0 came out despite the shitload of crap that was thrown on them for daring to do so did draw a blueprint for GNOME developers to know where are the usability pitfalls, what to do and what not to do when working on theirs!

It is somewhat ironic that KDE SC 4.5 actually offers something closer to a traditional desktop with taskbar on the bottom, menu launchers, (optionally) icons on the desktop for those that want it even though Plasma does offer many of the same advantages of other composited desktops and many of its own while retaining the familiar work flow whereas GNOME Shell will be much more of departure of the classic GNOME DE when it arrives.

Like Lemur said above, it is not unusual at all to find articles evaluating GNOME and its related tools and correctly finding that they leave something to be desired when compared to proprietary alternatives available on Linux and elsewhere and completely disregarding KDE and its applications which does make some of us wonder why is that so.

GNOME sppears to have a 50% larger use base right now compared to KDE according to these user-submitted survey results.

This despite the many years of continual sniping at KDE that some people have endlessly and uselessly been engaged in.

The design of KDE 4 was a very significant departure from KDE 3, and it took a fair effort to switch over, with a noteable drop in feature support during the transition. But now people may be able to see the benefits ... due to the cleaner design of KDE 4, we can now contemplate a significant change in the presentation layers, bringing with it the benefits of multi-threading and more extensive GPU acceleration, without serious impact on other parts of the desktop software.

Given that KDE can now move with the times WITHOUT significant regressions or disruptions gives the lie to your original claim.

So much so that one has to wonder at your motivations for making claims that are so obviously wrong.

>> Seigo does note, though, that eventually everything will move to OpenGL, and he's right. That's called progress, and cannot (and should not) be stopped. There's enough choice in the Linux world when it comes to less demanding (hardware-wise) desktop environments. <<

So a user should choose a *full desktop environement* according to whether he has hardware accelerated OpenGL or not??
It seems incredibly rigid!
IMHO, the users should only have to choose whether he wants to enable "shiny effects" or not, this is not progress..

While I see your point, the same could be said of bitmapped graphics and colour graphics.
Not everyone has 2D acceleration, either.
With the way xorg drivers are moving and the fact that probably 90% of bitmap graphics processing units sold today support 3D acceleration, this is a logical move.
Should it happing quickly? No.
Should it or something similar happen? Yes.

Well, I don't agree with the statement that it's the same situation. Be it only because bitmap blitting and color graphics are standard (through VESA), whereas 3D is implemented in a proprietary and generally undisclosed way, making implementation a PITA if you don't work for the relevant HW manufacturer.

While I see your point, the same could be said of bitmapped graphics and colour graphics.
Not everyone has 2D acceleration, either.
With the way xorg drivers are moving and the fact that probably 90% of bitmap graphics processing units sold today support 3D acceleration, this is a logical move.
Should it happing quickly? No.
Should it or something similar happen? Yes.

I'm completely disenchanted with OpenGL, though.

You're disenchanted because the OpenGL on Linux that is integrated into Desktop Environments is still in the 1.x era.

No, it's more that I'm... disenchanted with OpenGL.
Considering the time it took to make D3D work with Gallium3D vs how long it took to get that far with OpenGL, and their comments on it, the fact that it's really only designed to work with C-family languages, and still works with pixels and triangles, I think it's crap.
I think X is crap, too.
I can't actually think of a current windowing system that I don't think is a long-term dead-end.
I'm not a fan of über-static languages like (Obj)C(++ et al) that have no built-in means of interactive development or run-time modification.
I hate GTK.
I hate that to write a 'web app' I'm supposed to write it in 3 different languages with vastly different syntaxes.
I hate that there's still C in Emacs.
I hate that Common Lisp won't give up or improve, but instead stagnates and produces a ton of disparate efforts to extend the language, rather than remove the cruft.
I hate that Clojure doesn't care how huge the JVM is memory-wise.
I hate that OpenFirmware/OpenBIOS was ignored by the people that became LinuxBIOS/CoreBoot because they didn't like Forth, and OpenFirmware was extended to emulate enough BIOS calls in under a year, but CoreBoot works on a small handful of mobos.
I hate that FreeBSD makes a claims that are patently false, like supporting the Sun Fire V880 (the SCSI DVD-ROM doesn't work with any known version, the bug's known, it's still listed as supported. what am I supposed to do? install over USB 1.1?).
I hate that OpenBSD doesn't want to have a real installer.
I hate that NeWS was proprietary and _expensive as hell_.
I hate Ruby.
I hate George W. Bush's entire administration and everyone that backed him.
I hate homophobes, racists, and pedophiles.
I hate red Twizzlers.
I hate driving, or rather, how amazingly dangerous it is.
I hate that weed is illegal.

I'm allowed to hate things I'm well-informed on, and believe to 'be of sucks', to paraphrase Henry Rollins' impression of bad English.
So, yeah. The next time you're going to assume something, spell it out.

Then you should find the new pc-sysinstall in FreeBSD 9.0 to be almost perfect. Text-mode, answer a bunch of questions, an install script is generated, then the install script is run. Every install is a scripted install, so you can manually tweak it as you see fit. And you can build any kind of TUI/GUI over top that you desire.

So a user should choose a *full desktop environement* according to whether he has hardware accelerated OpenGL or not??
It seems incredibly rigid!

This won't happen for a while.
Right now, QML is based upon QGraphicsView, that has pluggable backends, software or opengl.
this is a blessing abd a curse, since using opengl here helps but only so much, at some point you hit a wall, where you can't improve the visual quality/effects unless a big cost in terms of performance, unless the graphics system is designed towards the opengl (or direct3d for what matters) api.
it may be sad, but you don't find modern 3d games with software rendering

Once upon a time there was only monochrome displays. I think it's incredibly rigid that todays desktops require colors. And not just something simple as 8 or 16 colors, we are talking thousands and millions of colors.

...and NeWS re-appears implemented in a combination of languages with less extensibility.
There are advantages to doing it in multiple languages/namespaces etc, but there are disadvantages, too. Mainly extensibility is dropped, but yeah.

Wow! Reading so much comments make me wonder... How many of you actually tried QML? How many of you installed the beta of QtCreator 2.1 and fiddled with it?

Just back from the Qt Developer Days in Munchen and in my perspective QML was the 'buzz of the town'. The presentation about QML (there were a lot on the different aspects and possibilities with QML) we're all ... great!

Is it just me (and Aaron I presume :-) who thinks that with QML (or correctly Qt QUICK) Nokia has developed a great technology?

QML looks cool and after installing Kubuntu 10.10 in a VM I am super impressed with KDE 4.5. After I figured out that I needed to force font dpi to 96, it looks really nice. I'm impressed with how far KDE has come, I think I like it better than GNOME at the moment. Keep up the good work.

It´s the 4.0 fiasco all over again, the same was told back then "Look, Qt has QProxyGraphicsWidgetsWhatEver, you can rotate them, you can zoom out", but you can't actually use it, if the next two years are gonna be more try and error, then these guys haven't learned anything.

I am a KDE user since the 1.x days back in '99 and it serves as my sole desktop environment for the last couple of years. I really believe that KDE SC is one of the greatest and most innovative open source projects yet.

Newest is not always best. Take the Ubuntu 10.10 release that came out on October 10th. Ubuntu users who are happy with their current release may want to hold off before taking the plunge.

The Ubuntu 10.04 release was very solid, with a lot of major improvements that made it a no-brainer for an upgrade. That, plus the fact that it’s a Long Term Support (LTS) release, which is the right time to grab an upgrade for almost all users. The 10.10 “Maverick” release brings some improvements over 10.04, but they’re so minor that it’s probably not worth making the change.

...

Kubuntu, on the other hand, is worth the upgrade to get KDE 4.5. KDE 4.4 was a good release, but KDE 4.5 finally brings KDE back (in my opinion, at least) to the state it was at with KDE 3.5. It feels much more polished, its fairly speedy, and the Kubuntu take on KDE 4.5 seems very well done.

Again, moving to KDE 4.5 means only 18 months of support — but in this case the switch is worth it. KDE 4.5 is enough of an upgrade that it merits the update right now. The updates in GNOME 2.32, due to the GNOME Project’s work towards 3.0, aren’t nearly as exciting. Which is not an insult — 2.32 is a solid release, but it’s not such a major leap that I’d spend an afternoon upgrading a stable machine.

While this article still manages somehow to have a kind of sideways ping at previous releases of KDE, it does illustrate the point nicely ... KDE is moving ahead and IMO keeping pace with advances in hardware, increases in user expectations and advances in other competing desktop operating systems. KDE cannot be accused of stagnating.

The proposed advances in the KDE/Qt rendering layers described in this thread (hopefully without impacting much on other layers of the KDE applications stack) seem to be further significant, worthwhile advancements in this vein.

I'm not too sure what i think about OpenGL being required either, but note the following:

1. Gnome 3 also has the same philosophy.

2. This won't be ready to switch over to the SceneGraph tech for 2 years, possibly 3.

3. By that time, it's entirely possible that LLVMPipe will be able to render basic desktop 3d (without effects enabled) at an acceptable speed, even if it is slow. Just like VESA can render 2D but not very fast.

4. The SceneGraph is under heavy development right now, and it's entirely possible it will be given a non-3D rendering backend.