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 445054
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: ...
by aseigo on Thu 14th Oct 2010 14:08 UTC in reply to "RE[4]: ..."
aseigo
Member since:
2005-07-06

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.


indeed ;)

Reply Parent Score: 8

v RE[6]: ...
by Hiev on Thu 14th Oct 2010 14:16 in reply to "RE[5]: ..."
RE[7]: ...
by Bill Shooter of Bul on Thu 14th Oct 2010 14:28 in reply to "RE[6]: ..."
Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Parent Score: 5

RE[7]: ...
by segedunum on Thu 14th Oct 2010 15:34 in reply to "RE[6]: ..."
segedunum Member since:
2005-07-06

Duke Nukem forever? Wishful thinking.

We've been through several releases of KDE4 and it's no different to when Microsoft moves people from Winforms to WPF or Apple with their terrible framework churn - and a damnsight less painful.

But, whatever.

Reply Parent Score: 6

RE[7]: ...
by kolmyo on Fri 15th Oct 2010 09:40 in reply to "RE[6]: ..."
kolmyo Member since:
2005-07-11

I just can't avoid to compare KDE4 with with DukeNukem Forever.

Peace, and I wish you a flawless migration.


I understand completely you Gnome fanboys aren't used to changes.

Reply Parent Score: 3

RE[6]: ...
by TheGZeus on Thu 14th Oct 2010 15:30 in reply to "RE[5]: ..."
TheGZeus Member since:
2010-05-19

Now let me write plasmoids in PostScript, and your journey to the dark side will be complete.
NeWS for eh VER.

Reply Parent Score: 2

RE[7]: ...
by jgagnon on Thu 14th Oct 2010 15:44 in reply to "RE[6]: ..."
jgagnon Member since:
2008-06-24

Why not just use PDFs instead? :p

Wait, better idea, have the UI generated with Flash. ;)

Reply Parent Score: 2

RE[7]: ...
by oiaohm on Sat 16th Oct 2010 12:59 in reply to "RE[6]: ..."
oiaohm Member since:
2009-05-30

Now let me write plasmoids in PostScript, and your journey to the dark side will be complete.
NeWS for eh VER.


Ok TheGZeus where have you been. PostScript is a dieing breed. The printing stack on Linux and others is moving over to PDF. Now a PDF plasmoid could be scary.

Reply Parent Score: 1