The image on the left is a new (example) plasmoid that marks an important change… this is going to be a quite massive blog post, with pretty technical details about what I think is going to be a feature of an higly important strategic relevance on the road towards Plasma as a mature and powerful platform.
The Plasma declarative bindings have landed into kdebase! This means it will be possible to use the new QML language part on Qt 4.7.
As Aaron noted some days ago, QML in conjunction with now in heavy development technologies like QtComponents (and in the future Qt cene-graph) will play a key role in the creation of user interfaces in the future, and gives us a very important puzzle piece we were still sorta missing.
So we deceided to be (as usual 😉 erly adopters of the technology and with the KDE Plasma workspace 4.6 the first pieces will be in place for the roadmap that will lead us basically to this path:
- Separate the implementation of the logic from the user interface
- Avoid C++ (and well, any imperative language) as much as possible for the UI
- Be flexible, an application should be able to jump between different devices as easily as possible
- do applications that can chose the proper ui amond different choiced depending on the device used, the screen size, the input methods and what not
- With QtComponents, use what will be the native set of widgets/components for the given platform: on a MeeGo phone, use its own widgets, theme and UI paradigms, but a different interface somewhere else
- Performance, perforance, performance, enter Qt scene graph
So, what will have the KDE Plasma platform 4.6 of all of this?
Use QML from C++ Plasma widgets
The first pass (needed to do the following one) is to have a way to easily load a QML file into a normal C++ plasmoid. Now, loading a QML file into a QGraphicsScene (and making it well behave inside the QGraphicsLayout based Plasma widgets) is a quite simple operation, however it is a bit long and repetitive amount of boilerplate code… enter Plasma::DeclarativeWidget.
This is a normal QGraphicsWidget just like the other Plasma widgets, all you have to do is to add it in the QGraphicsLayout of the applet, set the path of a QML file in it et voil
Madness!? THIS. IS… K.. D.. E.!!!!
WOOOOOORRRRRLD DOOOO-MIIIIIN-AAAAA-TIONNNNNN!
*ahem*
I think KDE’s going to do very nicely with this. 🙂
Impressive!
I see that plasma (and KDE) is moving toward scripting in several places, and I’m wondering if I should be worried. Obviously it’s easier and safer to download a plasmoid written in javascript via GetHotNewStuff, as opposed to a potentially sourceless compiled binary.
With this trend, will plasma become slower? I can’t imagine a python-interpreted or javascript widget being faster than a native compiled Qt4 plasmoid.
I use Kubuntu on my netbook, which has very limited hardware with its Intel integrated graphics. So performance is high on my list of priorities.
As a sidenote, currently KTorrent is pretty much unusable on that machine – the GUI is unreasonably unresponsive, even with the update interval set to 5000ms. It’s probably fine on faster machines, hence why noone else seems to get the same behavior. I just don’t want plasma (desktop) to end up the same.
One of the reasons of this move is done is exactly for performance reasons.
while is true that the scripting bits can’t be faster than c++, most of the things that require speed, like pages scrolling or animations, even in QML there is no scripting involved. With Javascript/qml you say for instace what must be the taregt of your animation, and the backend, in C++ will do it.
When there will be the transition to scene graph, all the possible performance hits taken by the scripting language bits will be largely compensated by the greatly increased speed of the new graphics backend
One of the aspects that I really miss in most of the Plasma posts on planetkde is the security aspect. Can a malicious plasmoid I downloaded take over my system? Those plasmoids don’t run in a sandbox, do they?
the JavaScript and QML ones no, they don’t have access to any potentially dangerous function, like filesystem manipulation