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: https://invent.kde.org/mart/Plasma-framework 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.