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 445047
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: ...
by Hiev on Thu 14th Oct 2010 13:30 UTC in reply to "RE: ..."
Member since:

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[3]: ...
by aseigo on Thu 14th Oct 2010 13:46 in reply to "RE[2]: ..."
aseigo Member since:

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.

Reply Parent Score: 12

RE[4]: ...
by Hiev on Thu 14th Oct 2010 13:53 in reply to "RE[3]: ..."
Hiev Member since:

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.

Edited 2010-10-14 14:04 UTC

Reply Parent Score: 1