Pretty busy days here at Randa. On the Plasma front some important decisions have been taken and a lot of work is now being done in this direction.
There is now a big traction in rewriting our current plasmoids in QML, such as the notifications I talked about some days ago, and many more that are coming.
The plan for the future is to have 100% QML-based workspaces, with as little changes as possible feature-wise compared to the current one, just with a smoother feeling 😉
This is only the first part of the road, and this is arriving already today, with each release of the Desktop workspace more complete, while Active is already 100% QML from day one.
What will happen next? Together with Qt5, there will also be the release of the next major revision of QML, that expands the language and changes the technology behind. Among the other things, everything will be on an opengl scene and the JavaScript bits will be managed by V8.
This comes at a price: only pieces of the user interface that are written in QML can be loaded in an environment based off QML2. hat means the old code based on QGraphicsView (and part of the old C++ API) has to go.
This wasn’t an easy decision, but it will make things dramatically easier in the future.
- On QML2, we’ll have a lot more performance, guaranteeing a way smoother experience (with QML2 you can get 60fps in 1080p on an humble raspberry pi after all)
- More stable, because most user facing code (especially most 3rd party) becomes scripted
- Easier to write plasmoids: lowers the barrier for contributions and lowers the barrier in experimenting new innovative approaches for the UX
- Also the internal library will be way easier to approach for new developers, because it will be way smaller and simpler
- It will also be simpler to take and use the Plasma library for new things, like in application’s dashboards, or just using its QML components.
This is a long term plan: The work on the new Plasma library version started now, and we expect a working shell based on the new framewok and Qt5 in about 18 months or so.
I’ve just got a first preliminary version of libplasma building without QGraphicsView dependencies, and the binary is about two thirds of the size it had before, so this is an encouraging start 😉
It’s again an exciting time when we can design a new architecture, have crazy ideas, trying them out, and any input or help is very appreciated.
You can see the progress of the tasks that are added as the work proceeds here, and talk or claim some tasks for yourself at the usual channels of communication, plasma-devel@kde.org or the #plasma freenode IRC channel.
Sounds like KDE 5 will be something to look forward to. 🙂
This sounds like the ideal way to go and I assume that you were undecided only due to the amount of work involved. I am glad you chose this way and wish it may go as smoothly as you imagine. 🙂
Scripting languages might have their benifits, but stability normally is not one of them. In practice there or normally two outstanding differences when using scripting languages:
1.) There is no compiler and thus less error checking is done.
2.) There normally is no (good) type system. Types are nothing else than implicit tests, which you all could do by separate testing. In practice the missing tests are not all done when using a scripting language.
Of course some scripting languages are higher level than some compiled languages, but overall there is a clear decrease in stability when using scripting languages (examples: JavaScript in Webpages, PHP-Scripts on Webserver, Matlab-Scripts, …).
Actually, writing plugins, or in general UI elements in QML improves stability, since it makes it a lot easier to shield the shell from problems in plugins. With C++ plugins, a crash in one component can bring down the whole desktop. This risk is hugely reduced with QML, so (modulo bugs in the scripting runtime or imported C++ functionality), plugins written in QML cannot crash the whole shell, or app.
A downside is, indeed that errors only show up at runtime.
The typing system in QML is quite a bit more strict than you normally find in JavaScript, so errors are more visible during development stage. Over the past years, we also gained a lot of experience in this scripted runtime we’re moving towards, and code is very actively being reviewed and tested. Overall, my impression is that moving to a pure QML runtime will increase perceived quality for the user. The components we have already moved to QML (and those are becoming quite a few) behave nicer, show less bugs, and are generally more pleasant to use, let alone quicker to develop.
Replying to MMM.
JavaScript in Webpages and PHP scripts on Webservers are actually good examples of the *improved* stability that a managed (or scripted) language and run time can bring over something like C or C++. When a PHP script goes wrong, the whole server doesn’t crash. When Javascript on a page goes wrong, the whole web browser doesn’t crash. And hopefully, when a plasmoid goes wrong, the whole desktop doesn’t crash. This containment property is extremely useful for a system like plasma which is a composite of many smaller independent parts and plugins.
A general comment to all:
V8 is a blazing fast JS run time. I’m working with it most days this year. I’m glad to see it in Qt. The only thing I don’t like about it is the very old Javascript version is uses. oh well.
Replying to MMM.
JavaScript in Webpages and PHP scripts on Webservers are actually good examples of the *improved* stability that a managed (or scripted) language and run time can bring over something like C or C++. When a PHP script goes wrong, the whole server doesn’t crash. When Javascript on a page goes wrong, the whole web browser doesn’t crash. And hopefully, when a plasmoid goes wrong, the whole desktop doesn’t crash. This containment property is extremely useful for a system like plasma which is a composite of many smaller independent parts and plugins.
There normally is no (good) type system. Types are nothing else than implicit tests, which you all could do by separate testing. In practice the missing tests are not all done when using a scripting language.
This sounds like the ideal way to go and I assume that you were undecided only due to the amount of work involved.
http://www.haomei-aluminium.com