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 445049
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: ...
by aseigo on Thu 14th Oct 2010 13:35 UTC 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