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.

This blog post at Qt Labs describes the plans surrounding QML and (eventual) benefits from aggressive GPU acceleration.

KDE has always been on the cutting edge of Qt, and they already have a significant QML buy-in (Plasma Mobile is implemented in QML). Continuing this process with desktop Plasma overhaul, while not yet a committed goal, would seem like a natural progression.

Additional notes from Thom

The process of moving Plasma over from the Graphics View architecture over to Qt Quick and QML won’t be completed in a few snaps of the fingers. The plan is to make the transition over a number of KDE releases, during which more and more parts of Plasma are moved over to the new framework.

“Every Plasmoid, Containment, popup and window dressing (e.g. the add widgets interface, the panel controller, the activity manager, …) that does direct painting needs to be moved over to QML,” Seigo explains, “Thankfully we can do these one at a time with the results working very nicely with the current QGraphicsView based libplasma. This means we don’t need to do a ‘massive porting effort with a huge pause between releases’; each release can contain more and more QML driven elements and fewer and fewer uses of QPainter.”

Some breakage may occur in the process of moving from libplasma to the binary and source incompatible libplasma2, but Seigo explains the impact will be very small. “The good news is that this is an almost completely internal set of changes. The design of Plasma lends itself very nicely to this set of changes, and the C++ classes in libplasma are nicely aligned as well,” he notes, “So the external impact looks like it will be surprisingly small for anything written in Javascript or which uses QML for its user interface.”

One concern raised in the comments is that these changes mandate the use of OpenGL. Seigo hopes they’ll end up with a non-GPU render path as well. “This is all still work-in-progress and the plain CPU-rendered path is valuable to us in many use cases,” he states, “I’m hoping that we’ll end up with a proper OpenGL path (scene graph; OpenGL backend for QPainter just isn’t a full solution) as well as a QGrapicsScene fallback.”

Seigo does note, though, that eventually everything will move to OpenGL, and he’s right. That’s called progress, and cannot (and should not) be stopped. There’s enough choice in the Linux world when it comes to less demanding (hardware-wise) desktop environments.