Category Archives: Uncategorized

Akademy 2021

It’s the second day of Akademy (for the second year, in an online form, for obvious reasons) and still a full week of goodness to come with a lot of interesting bofs and social events.

I gave a talk about the future of Plasma and what to expect from Plasma 6 as an architectural standpoint. How we can make things simpler, faster, more stable and more intuitive to develp against. (Sorry, no pretty pictures here ðŸĪŠ)

Here is a synopsis of my talk (slides here), I hope it’s clear enough to the occasional reader:

The topic of this talk will be unfortunately very far removed from pretty pictures, I’m going to talk about the non visible aspects of Plasma: The structure of Plasma Framework, how the desktop is loaded, what basic api a developer can use to write a plasmoid.
For those who attended yersterday training by Kevin, the first part will have some repetitions, but let’s refresh it a moment, then i will talk about some deas on how to streamline it and what changes we would like to have for KF6/Plasma6

First of all, a bit of history: Plasma was introduced with KDE 4.0, in those “interesting” times 🙂

Back then, the structure was as follows:
It was based on a Qt technology called QGraphicsView, which nowdays is kinda deprecated. Plasma doesn’t use it anymore, some apps still do, like the Dolphin icon view, still used a lot in Gwenview, and something will need to be done about it.

The center was a QGraphicsScene, called the Corona, which seems incredible nowdays but it was a complete innocent name back then! (referring to the Sun Corona, where the Plasma lives)

The Corona loads inside its scene QGraphicsWidgets objects called Containments, and manages views for each containment: every containment that is associanted to a phisical screen, will have a correspondece 1:1 with a view and views can be eother of Desktop type or Panel type

Each Containment can contain many Applets, which will be either desktop widgets or panel components like the start menu, task manager and so on, and containment itself is a particular type of Applet, so it’s a subclass of it.

Applets own a Package of files, together they form a Plasmoid. Plasma::Package was then splitted out of Plasma-framework and became the KPackage framework

In this way is possible for the user to build its own perfect desktop ui out of a vast choice of pieces.

In KDE4 times, Plasma supported a wide variety of bindigs, even if most of the applets were implemented in C++
We had pure javascript (before QML wasa thing), Python, Ruby and later we added QML support.

In Plasma5 things changed quite a lot, as it was obvious that QML was going to be the future, and qgraphicsview was having huge performance problems (when resizing large applets it could go down even to 4-5 fps)

So we went all with the QML scenegraph, having much faster and hardware accelerated things in the process.
Corona, Containment and Applet are no more graphical objects but judt QObjects that manage only logic, not the visualization having a better separation
On the downside that meant that the qml binding became the only way to write plasmoids, losing the possibility for using Python and Ruby, but all the binding infrastructure remained there, which became a significant overhead without a real reason.

So now with KF6 coming: What parts of the Plasma architecture are still needed and mostly ok? what are kinda redundant and not necessary anymore? should we split something? how we can improve things in general?

A thing we should split is the Plasma Svg support, just like KPackage can be really useful elsewhere for apps as well. Even if is just for basic svgs, due to QtSvg it’s based on, It adds some nice features on top: caching of the rendered images which helps a lot with load times, it can optionally color svgs with stylesheets and offers support for those nine patch rounded rectanles rendering with sone support for hardwaare acceleration when used on QtQuick. IT has both QtQuick and classic QPainter based API

One that should probably instead be dropped are Dataengines: they were designed with the limited JavaScript api in mind and had quite a hefty goal: to give a common async job based api to access all kind of information, even remotely, to stream informations also on widgets of another computer (KDE4 had thins kinda working)
However in the end the implementations ended up being not so good with pretty ugly code.
With QML it became way easier to just bind QObjects with properties, signals and slots for the logic instead.
They can go in a Plasma5Support porting aid in Workspace

The parts that loads the layout from disk to a Loading the layout from disk to a qobject representation are pretty good right now, and save for some API fixes it can be very similar in Plasma6 as well.
The layout is saved in the appletsrc file, which at startup is read by the Corona and reads the first level of the config file, which represents the containments, that will be instantiated from the plugins.
Corona will check what containments are assigned to a screen which is connected, and those will get a QQuickView, both panels and desktops.
At this point containments will load all the applets in them and instantiate also the corresponding QML and use their oown internal logic to layout the applets, as linear layouts in panels, flee floating in desktops.

Another important part are shell packages
They were born in Plasma Active to do a mobile optimized shell, then the shell of Plasma Active basically became the Plasma5 unified shell for every device and the shell packages are here too, to allow some personalization to adapt the shell to a different kind of device, ad desktops, phones, mediacenters and so on have different ui requirements
In Plasma6 i would like them to be a bit more powerful.

ScriptEngines are a way to wrap the Api of Applet Containment and so on, in a more “limited” way, so that the kde4 times javascript bindings could use them without being “dangerous” Unfortunately those are still used in the QML plasmoids nowdays, but the whole infrastructure should be removed. I would still like some way to bring back Python in plasmoids, but with a different mechanism compared to old scriptengines

I made a prototype as a Plasma-framework fork in my personal area on invent: is still not completely functional, but i do have a very simpleshell loading a qml containment and a plasmoid inside it which removes all of the AppletScript intermediary, and the “plasmoid” object is directly the Applet* instance, not a wrapper anymore.

The first phase of loading works in the same way, corona reads appletsrc, instantiates the Containments and in turn the containments instantiate the Applets.
The shell creates the actualwindows, a view for each containment which is associated to a screen, the view when gets assigned to a containment ensures the QML ui for the containment is loaded.
The QML part of the containment, when it gets a new Applet*, it creates an object of type AppletContainer which will take care of making sure that the qml part of the applet is loaded, and this will go in whatever layout manager the Containment implements.

The QML part of an Applet is as is now, shipped in a KPackage.
Now, the root element instead of being an arbitrary item, is forces to be a particular one: AppletRepresentation (error if that’s not the case) its api is purely providing components property for the compact and full representation.

This is a very basic example:

import QtQuick 2.15 //3
     import QtQuick.Layouts 1.0
     import org.kde.plasma.core 6.0 as PlasmaCore
     import org.kde.kirigami 2.15 as Kirigami
     18 – 25 June 2021
     PlasmaCore.AppletRepresentation { // This non graphical element is the mandatory root, won't load with a different one
         // As is today, 99% on the times shouldn't need a compactrepresentation
         compactRepresentation: Kirigami.Icon { // Hopefully this can replace PlasmaCore.IconItem
             source: "start-here"
             TapHandler {
                 onTapped: PlasmaCore.Plasmoid.expanded = !PlasmaCore.Plasmoid.expanded
         fullRepresentation: Item {
             Layout.minimumWidth: Kirigami.Units.gridUnit * 10 //plasmacore units should be migrated to Kirigami
             Layout.minimumHeight: Kirigami.Units.gridUnit * 22
             Text {
                 text: PlasmaCore.Plasmoid.title // all accesses to PlasmaCore.Plasmoid are pointers to the same Applet* instance

Most on the times, compactRepresentation is not needed, the default shell-provided icon will be used but can be overridden if needed (or explicitly be set to null if we want applets to not be collapsible, like the task manager)

The shell packages may become more powerful if we instead of providing root items for the views, which are desktops, panels and config dialogs, they can provide the view window themselves, so that those views can be custom provided plugins as well, perhaps also useful for very custom panel containments, like Latte Dock, to be able to be loaded in the same Plasmashell process.

KF6 Sprint in Berlin


From the 21st to 24st of Novemember, a bunch of KDE people gathered in Berlin graciously hosted by the MBition offices to discuss about the next big iteration of the KDE frameworks.

Work on Qt6 started, and it will be a big refactor that makes the api quite better, solve some architectural problems in some Qt5 areas (one of my personal favorites is the new QGuiAction class coming out of the split of QAction in a QWidget-less implementation). In order to have that, it needs to be binary incompatible with Qt5 tough.

As it will be incompatible, we need to adapt our software and our frameworks.. a lot of work ahead, but big opportunities as well, so… It’s time for KF6, where we can do the same thing: polish our API and solve some problems we couldn’t do in KF5 in a binary compatible way.

We worked in groups, assisted remotely by David Faure and looked at the frameworks we were less happy and need more a refactor.. The first obvious candidate are those tier 3.

Our fancy Kanban board

The Tier system in frameworks means that frameworks of tier 1 don’t depend from other things than Qt modules and base system libraries. Tier 2 frameworks can also depend from tier 1 frameworks, and tier 3 from tier 2.

In reality there are some tier 3 frameworks which “real” tier would be 5 or 6 as may depend from multiple other tier 3 frameworks. Those of course are the first that need to be looked at. Ideally we should manage to lower the tier of frameworks as much as possible and at least having tier 3 ones that are actually tier 3, and not 4 or 5.

Some typical examples are KIO, KDeclarative, KXmlGui, and Plasma-framework.

For the KDeclarative case, the reason is that its genesis was quite peculiar. When in late KDE4 – early KF5 was starting to be apparent that the focus of the future in GUI programming in Qt was probably going to shift towards QML, we chosen at first to put the bindings to QML of the frameworks we needed in a single umbrella repository, ending up with a git repo full of many tiny QML plugins that depended from one framework or another… ending up with a framework that depended from just about all the others. It will be split out and every useful QML binding will go into the proper framework: as QML is now a super central part of Qt, frameworks need to play well with it to be an important citizen of the Qt ecosystem.

Plasma framework

Now talking about a part that is really near to my hearth: Plasma-framework. It’s a pretty high tier because it depends from KXmlGui and KDeclarative. As we seen, both of those dependencies will be not too hard to remove (famous last words :).

My plan is to have the main plasma library splitted in 3 smaller frameworks, each one tier2 maximum:

  • libplasma: the part that manages load and save of your desktop layout, all that is related of loading a plasmoid and the api that palsmoids will use to interact with the Plasma workspace
  • theming: Plasma uses svg-based themes with significant optimizations like disk-caching of the rendered bits, which support stylesheets for dynamic colors based on your system ones: this should be a framework in itself, usable by any app: probably tier 2
  • dataengines: that’s a technology not much used anymore and is kinda being phased out. Should exist standalone as a “porting aid”

With this, hopefully Plasma will be even leaner, further improving startup time and memory usage, while on the same time applications gains a framework for doing light weight and feature rich svg based graphics theming.

Plasma Edit Mode refinements


Editing, moving and customizing widgets in Plasma Desktop improved a lot in 5.17, and then in 5.18 it will get a brand new edit mode, to be really efficient editing your desktop layout (and have less visual noise by default).

This week another new feature landed in the edit mode for 5.18: it’s possible to set some plasmoids without background and a nice drop shadow, for an extra clean and modern look for your desktop.

In addition, a plasmoid can specify this backgroundless shadowed mode as its new default, like the digital clock now does (when is on the deskop)

Applet developers will have to opt in this feature: doesn’t always make sense everywhere and some may still be buggy. Some default plasmoids, especially in kdeplasma-addons have been set to support it.

If you are writing a plasmoid and want to support this background removal, in the main QML item of your plasmoid you can do:

Item {
    id: root   
    Plasmoid.backgroundHints: PlasmaCore.Types.DefaultBackground
                             | PlasmaCore.Types.ConfigurableBackground

Or, if you want to default toi the new background-less, automatic shadow:

Item {
    id: root   
    Plasmoid.backgroundHints: PlasmaCore.Types.ShadowBackground
                             | PlasmaCore.Types.ConfigurableBackground

Of course the NoBackground option is still there if a shadow isn’t what the graphic style of the plasmoid needs.

A notice that needs to be kept in mind, is that for color inversion to work automatically, one should never do:

    color: theme.textColor

But rather

    color: PlasmaCore.ColorScope.textColor

Which is a good way to get ready for Qt6 anyways, as context properties are going to be removed in the next Qt major release.

Choose Your Own Experience in Plasma 5.8 and beyond


One of the key points of Plasma is while giving a simple default desktop experience, not limiting the user to that single, pre-packed one size fits all UI.
Its strength is to be flexible to greatly different user needs, “Simple by default, powerful when needed”.
Several years ago, the Visual Design Group had the idea of making easy to build and share desktop layouts to make easy to test wildly different user interfaces, see this old post by Thomas on the topic.
Since then, work on it has been going on, mostly on the infrastructure needed to make it a reality, and in Plasma 5.8 the first pieces are there, tough still far from the complete experience we want to offer.

The support for Look and Feel packages is there since a while (5.3 or so) that’s what one of those package can do:

  • Provide a default layout for when Plasma starts for the first time, it was used for distributions to personalise their UI, but now is easier for users as well.
  • Provide some default look options, like what color scheme to use, what icon theme etc
  • (advanced) provide the actual implementation of some UI, such as KRunner, the Alt+Tab window switcher dialog, the lock screen

So far the default Plasma layout provided by the Look and Feel theme was used only when starting up for the first time, on a clean user home (therefore very useful for distributions) but sice Plasma 5.8, in the Workspace theme -> Look & Feel section of system settings there is an option to load the new layout when switching the look and feel theme. Not as default as is a destructive action that will remove your current Desktop setup.


The other component is a tiny little application shipped in the “Plasma Sdk” package that’s called lookandfeelexplorer.
With this applciation you can:

  • Create a new Look and Feel theme
  • Edit the metadata and thumbnail of a locally created/installed theme
  • Create a default javascript desktop layout based upon your current Plasma setup
  • Create a defaults file based upon your current setup as well, such as color scheme and icon theme

The last two are the central part of sharing your idea of “the perfect desktop” with others, linked with the integration between the Look & Feel systemsetting module and the KDE store, also new in Plasma 5.8.

It’s still a preliminary feature, as ideally in the future if your shared Look & Feel theme depends for instance from a particular icon theme or a particular 3rd party plasmoid, the store integration will download those dependencies as well.

Systemtray, Plasma Next and GTK


You may have heard that KDE Plasma Next won’t support anymore the old X11,Xembed-based systemtray icons.
(More information here)

Years ago, we developed a nicer, model/view based alternative in which is the shell that actually draws the systemtray icon, allowing better integration with the workspace, it’s a specification that is now shared between KDE and Ubuntu Unity.
All KDE applications use it already, Qt4/Qt5-only application will use it depending on a small patch (and soon Qt5 will do out of the box)

But also GTK has some options: until today I was aware only about the Ubuntu’s appindicator library, but I have just been contacted by the author of another neat library, that can be found here on GitHub.
It’s a very small, few dependencies GObject-based library that allows a GTK3 application to export and control a statusnotifier-based systemtray icon. I just tested it on KDE4 and Plasma Next and seems to work quite well.
So if you have a GTK application that is using a systemtray icon, and you would like the icon to be integrated in the next version of Plasma as well, now you have an option more (and of course, the author will be happy of any patch/bugreport/bugfix).

KDE on improv, now with videos

I’m finishing the images of the OS that will be shipped by default on the Improv. As soon they are finished they will be available for download, alongside recipes on how to build new ones from scratch.
So at this point, I tought it was a good time to take some videos.
The default os, will be a kind of “tasting plate” for developers, it will be possible to try many combinations of software.
By default it will start with a normal console login, so very fast and ready for “small server” duties.
By going to graphical mode (init 5) it will start the SDDM login manager, from which several sessions will be available:
It will be possible to chose between OpenBox or a full KDE Plasma Desktop or KDE Plasma Active sessions (the latter two being completely independednt saving their settings separately).
Here is a video showing the 3 environments running on the Improv (the little board itself is visible in the bottom right corner of the screen)

Another important thing that is available there is Qt 5 (at the moment 5.1, upgradable in any moment newer packages will land on Mer)
This will give a very convenient development environment for Qt5 and QML2 based applications, to test their performance on a mobile/ARM based device.

Plasma Workspace: present and future

We saw last week the release of the first beta of KDE Plasma Workspace and applications 4.11

From my side, that’s a very important milestone, because it’s pretty much the coronation of what we intended the 4.x series of the workspace to be. It was a long ride, but I think this future release will be pretty stable and “defined” in its own identity.

The 4.11 release of the Workspace will be supported for years to come, marking in fact the last big feature release of the 4.x series.

This sounds pretty scary, but it indicates a lot of maturity, 4.11 will be a release you can count on being maintained abd bugs fixed for a long time. Nice for home users, utterly awesome for bigger deployments.

Just to clarify: this regards only Plasma Workspace so far. Applications will continue feature releases as usual, after all KDE is not a software, is a community that releases a lot of eterogeneous pieces of software.

So, were are now?

  • The desktop shell is useful by default. A default setup has all the typical functionality that a typical desktop usage needs, but.. one size does not fit all.
  • The desktop shell is very flexible, trying to not force a paradigm on you, assemmble it at your liking.
  • We have at least 5 different shells: Desktop, Netbook, Plamsa Active, Media center, part for application dashboards. Because one size does not fit all, on different devices we try to give you the best experience given the particular device.
  • QML: It’s very easy to write new components for your desktop/tablet/mediacenter/whatever with an easy scripting language.

But of course we never are happy: we want to do new things and have new features in the future..

  • We are porting to Qt5 and QML2
  • The whole workspace will be rendered by the GPU: faster and will be possible to have beautiful effects.
  • We will have one shell to rule them all: the actual Plasma Shell becomes just a generic “viewer” with no UI whatsoever by itself. Since all the UI elements will be done by QML, they can be loaded and unloaded, so a different device experience can be dynamically loaded when for instance you plug your tablet to a docking station, the full Desktop shell starts.
  • Even tough it will mean a quite big technology change, since we are quite happy with the overall direction of each one of our shells, there won’t be radical UI changes, except of course the usual incremental upgrades and refinements.

I’ll do a talk about Plasma2 at Akademy, going a bit more in deep about the technology, the big picture concept and how to get involved in, so see you there 🙂

I'm going to Akademy