A look in on Plasma 2

On the first day of Akademy 2013, Marco Martin gave a status report on the Plasma 2 project. Plasma is the umbrella term for KDE's user experience layer, which encompasses the window manager (KWin) and desktop shell. In his talk, Martin looked at where things stand today and where they are headed for the future.

Martin began by noting that much of the recent planning for the next few years of Plasma development was done at a meeting in Nuremberg earlier this year. His talk was focused on reporting on those plans, but also explaining which parts had been implemented and what still remains to be done.

Plasma today

The existing Plasma is a library and five different shells that are targeted at specific kinds of devices (netbook, tablet, media center, desktop, and KPart—which is used by KDevelop for its dashboard, but is not exactly a "device"). Plasma is not meant to be a "one size fits all" model, but to be customized for different devices as well as for different types of users.

It is "very easy to build very different-looking desktop interfaces" with Plasma, by assembling various plugins (called "plasmoids") into the interface. He counted 71 plasmoids available in the latest KDE Software Compilation (SC) and there are many more in other places.

As far as features go, "we are pretty happy right now" with Plasma. After the 4.11 KDE SC release, feature development for Plasma 1 will cease and only bug fixes will be made for the next several years. That will be a good opportunity to improve the quality of Plasma 1, he said.

Plasma tomorrow

Though the team is happy with the current feature set, that doesn't mean that it is time to "go home" as there are many ways to improve Plasma for the future, Martin said. More flexibility to make it easier for third parties to create their own plasmoids and user experiences is one area for improvement. Doing more of what has been done right—while fixing things that haven't been done right—is the overall idea. But there is a "big elephant in the room"—in fact, there are four of them.

The elephants are big changes to the underlying technology that need to be addressed by Plasma 2: Qt 5, QML 2, KDE Frameworks 5, and Wayland. All of the elephants are technical, "which means fun", he said. Of the four, the switch to QML 2 will require the most work. Wayland requires quite a bit of work in KWin to adapt to the new display server, but the QML switch is the largest piece. QML is the JavaScript-based language that can be used to develop Qt-based user interface elements.

Given that everything runs in QML 1 just fine, he said, why switch to QML 2? To start with, QML 2 has support for more modern hardware. In addition, it has a better JavaScript engine and can use C++ code without requiring plugins. Beyond that, though, QML 1 is "on life support" and all of the development effort is going into QML 2. There is also a "promising ecosystem" of third-party plugins that can be imported into QML 2 code, which means a bigger toolbox is available.

Another change will be to slim down the libplasma library by moving all of the user-interface-related features to other components. That is how it should have been from the beginning, Martin said. What's left is a logical description of where the graphics are on the screen, the asynchronous data engines, runners, and services, and the logic for loading the shell. All of the QML-related code ends up in the shell. That results in a libplasma that went from roughly 3M in size to around 700K.

One shell to rule them all

Currently, there are separate executables for each shell, but that won't be the case for Plasma 2. The shell executable will instead just have code to load the user interface from QML files. So, none of the shell will be in C++, it will be a purely runtime environment loaded from two new kinds of packages: "shell" and "look and feel". The shell package will describe the activity switcher, the "chrome" in the view (backgrounds, animations, etc.), and the configuration interface for the desktop and panels.

The look and feel package defines most of the functionality the user regularly interacts with including the login manager, lock and logout screens, user switching, desktop switching, Alt+Tab, window decorations, and so on. Most of those are not managed by the shell directly, but that doesn't really matter to the user as it is all "workspace" to them. All of those user interface elements should have a consistent look and feel that can be changed through themes.

Different devices or distributions will have their own customized shell and look and feel packages to provide different user experiences. All of that will be possible without changing any of the C++ code. In addition, those packages can be changed on the fly to switch to a different user experience. For example, when a tablet is plugged into a docking station, the tablet interface could shut down and start a desktop that is geared toward mouse and keyboard use. What that means for the applications and plasmoids running at the time of the switch is up in the air, Martin said in response to a question from the audience.

Current status

So far, the team has gotten a basic shell running that uses Qt 5, QML 2, and Frameworks 5. The libplasma restructuring is nearly done, so the library is smaller and more manageable. Some QML 2 plasmoids, containments, and shell packages have been started, but the existing Plasma 1 code will need to be ported. For pieces written in QML, the port will not require much work, but those written in C++ will need some work to port them to Plasma 2. Martin summed it up by saying that the "ground work is done", but there is still plenty of work to do.

[Thanks to KDE e.V. for travel assistance to Bilbao for Akademy.]