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.

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.