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

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.


QML is relatively new on the scene. It wasn't available in Qt until Qt 4.6 (released in 2009) - and even then it was an add-on that had to be installed separately, and now it's a native part of Qt as of 4.7 - released right at the end of last month (09/2010).

So to say that it's like admitting that the things were wrong in the beginning and now have to be corrected would be false since it wasn't an option when they started.

In other words, they're trying to evolve the platform as Qt evolves the platform, taking advantage of new features as they become available instead of years afterwards.

That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).

Reply Parent Score: 9

RE[6]: ...
by Richard Dale on Thu 14th Oct 2010 18:40 in reply to "RE[5]: ..."
Richard Dale Member since:
2005-07-22

That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).


When QML is used with QSceneGraph, the performance will be really good as it will take advantage of the computer's hardware 3D acceleration. So by seperating code to manipulate data written in C++, from the visualization part in QML, you will make your app run faster.

Reply Parent Score: 6

RE[6]: ...
by vivainio on Thu 14th Oct 2010 19:12 in reply to "RE[5]: ..."
vivainio Member since:
2008-12-26

That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).


Do you have citation for that?

Perhaps you are confusing using QML with doing heavy calculations with JavaScript inside QML. QML is being pushed specifically for high-FPS 2D user interfaces - this use case is pretty different from 3d games. You should do heavy calculations in C++, and let QML take care of the UI parts of the program.

If you are into 3d, you may find this QML video interesting:

http://www.youtube.com/watch?v=OXcxFZbKUNI

It's pretty cool stuff, even if with very little practical applications for now.

Edited 2010-10-14 19:22 UTC

Reply Parent Score: 6

RE[7]: ...
by TemporalBeing on Thu 14th Oct 2010 21:06 in reply to "RE[6]: ..."
TemporalBeing Member since:
2007-08-22

"That said, I do wonder how the performance of QML will come into play. Even the Qt guys don't recommend it for all things - only things that do not need quick response (e.g. high FPS video players would not be good to do in QML).


Do you have citation for that?

Perhaps you are confusing using QML with doing heavy calculations with JavaScript inside QML. QML is being pushed specifically for high-FPS 2D user interfaces - this use case is pretty different from 3d games. You should do heavy calculations in C++, and let QML take care of the UI parts of the program.

If you are into 3d, you may find this QML video interesting:

http://www.youtube.com/watch?v=OXcxFZbKUNI

It's pretty cool stuff, even if with very little practical applications for now.
"

Check the archives for the Qt-Interests and Qt QML mailing lists (see qt.nokia.com). There's a number of e-mail discussing what to do and not to do under QML. I might have just picked a bad example.

Reply Parent Score: 2