Linked by vivainio on Thu 14th Oct 2010 11:31 UTC
KDE 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.
Thread beginning with comment 445042
To read all comments associated with this story, please click here.
...
by Hiev on Thu 14th Oct 2010 13:11 UTC
Hiev
Member since:
2005-09-27

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.

Edited 2010-10-14 13:26 UTC

Reply Score: 2

RE: ...
by vaette on Thu 14th Oct 2010 13:27 in reply to "..."
vaette Member since:
2008-08-09

By the sound of things the drawing models will live side-by-side for the foreseeable future, so your worry is probably misplaced.

Better performance at a base level is often helpful to be able to write more robust code too, since less hacking to make things perform usually makes things easier to handle.

Reply Parent Score: 7

RE[2]: ...
by Hiev on Thu 14th Oct 2010 13:30 in reply to "RE: ..."
Hiev Member since:
2005-09-27

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.

Reply Parent Score: 2

RE: ...
by aseigo on Thu 14th Oct 2010 13:35 in reply to "..."
aseigo Member since:
2005-07-06

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.

Reply Parent Score: 11

RE: ...
by jibadeeha on Thu 14th Oct 2010 20:23 in reply to "..."
jibadeeha Member since:
2009-08-10

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.

Reply Parent Score: 1

RE: ...
by Carewolf on Mon 18th Oct 2010 23:36 in reply to "..."
Carewolf Member since:
2005-09-08

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.

Edited 2010-10-18 23:45 UTC

Reply Parent Score: 1