Category Archives: Uncategorized

Akademy 2023, Plasma 6 and Plasmoids

Software

During this week Akademy 2023 is going on in Thessaloniki, Greece. It’s always awesome, to see many old friends and getting together with that amazing hacker community which is KDE.

There, me and Niccolò gave a talk about what;s happening in Plasma 6 and what will change, Noccolò on more visual things, about some changes we are cooking on the UI and on the visual themes. Here you can find a recording of the talk (alongside all the others of the day)

I talked more about the work I’ve bein doing in the Plasma shell during the last couple of months: code rafactors and how the API for writing plasmoids will change.

There were many things we were not quite happy about and now with the major release is the occasion for streamlining many things.

Now, It’s very important those changes are are well communicated, and easy to do for developes, because there are *a lot* of 3rd party plasmoids on the KDE store, which people are using and enjoying.

Let’s go trough the most important changes:

Dataengines

Dataengines were an API designed in early KDE 4 times, especially one of for our first offereings of Plasmoid API which was the pure JavaScript API, which existed long before the QML existed.

But now in a QML world, their API doesn’t really fit, instead is a much better fit having a QML extension which offers classes with all the needed properties, data models and signals that provide access to the needed data, such as tasks, notifications etc.

Dataengines are now deprecated and moved into a separed library, called “plasma5support” which will be still available for the time being, but consider porting away from it as we plan to eventually drop it.

Base Plasmoid API

The way plasmoids are declared in QML changed a bit: we used to have a magical “plasmoid” context property available from anywhere. This was an instance of a QQuickItem which was both the item where all the plasmoid contents were *and* a wrapper for some of the api for the central plasmoid object: the C++ class Plasma::Applet.

Now the access to plasmoid is an attahced property, the (uppercase) “Plasmoid”, which is directly the access to the instance of the central Plasma::Applet, without an in-between wrapper anymore.

The central QQuickItem is now called “PlasmoidItem”, and must be the root item of the plasmoid, just alike ApplicationWindow is for applications.

PlasmoidItem will have the purely graphical properties, such as the “compactRepresentation” or “fullRepresentation”

Here is a very minimal example of a plasmoid main file under plasma6:

import org.kde.plasma.plasmoid 2.0
PlasmoidItem {
    Plasmoid.title: i18n("hello")
    fullRepresentation: Item {....}
}

Actions

Plasmoids can export actions to their right mouse button menu, such as “mute” for the mixer plasmoid and so on.

In Plasma 5 we had an imperative API to add those actions, which was again coming from that old pure JS API, which really looked a bit out of tune in QML. In Plasma 6 the API has been replaced with a completely declarative API, in this form:

PlasmoidItem {
    Plasmoid.contextualActions: [
        PlasmaCore.Action {
            text: i18n("Foo")
            icon.name: "back"
            onTriggered: {...}
        },
        PlasmaCore.Action {
             ...
        }
    ]
}

PlasmaCore.Action is actually a binding to QAction (not the internal QML action type), so that it can be shared between C++ and QML easily

SVG theming

Plasma Themes don’t really have changed for now (and you can expect any old theme from the store to keep working), but the C++ and QML API for them has been moved to a standalone framework called KSvg. Plasma Svgs have quite some interesting features over the pure QtSvg API, such as disk caching of the rendered images, stylesheet recoloring to system colors and the 9 patch rectangular stretched images of FrameSvg.

Some applications were interested in using that, but couldn’t due to the long dependency chain of plasma-framework, so now they can be used as a much more manageable compact framework, offering both the usual C++, QPainter based api and QML bindings.

import org.kde.ksvg 1.0 as KSvg
FrameSvg {
    imagePath: "widgets/background"
}

Kirigami all the way down

Designing Kirigami in the beginning we lifted two concept from the Plasma API (which again we couldn’t use directly due to the dependency chain) Theme and Units

Theme gives access to the named system colors, and Units to standard spacing and animation durations.

Over the years the Kirigami version got way more advanced then the Plasma version, and having this code duplication didn’t make much more sense, to in Plasma6 whenever referring to a named color or an unit, the Kirigami version should be used, as the Plasma version is going away.

import org.kde.kirigami 2.20 as Kirigami
RowLayout {
    spacing: Kirigami.Units.smallSpacing
    Rectangle {
        color: Kirigami.Theme.backgroundColor
        bordere.color: Kirigami.Theme.textColor
    }
}

How to report Multiscreen bugs

BlaBlaSoftware

As announced previously, Plasma 5.27 will have a significantly reworked multiscreen management, and we want to make sure this will be the best LTS Plasma release we had so far.

Of course, this doesn’t mean it will be perfect from day one, and your feedback is really important, as we want to fix any potential issue as fast as they get noticed.

As you know, for our issue tracking we use Bugzilla at this address. We have different products and components that are involved in the multiscreen management.

First, under New bug, chose the “plasma” category. Then there are 4 possible combinations of products and components, depending on the symptoms:

Possible problemProductComponent
  • The output of the command kscreen-doctor -o looks wrong, such as:
  • The listed “priority” is not the one you set in systemsettings
  • Geometries look wrong
kscreencommon
  • Desktops or panels are on the wrong screen
  • There are black screens but is possible to move the cursor inside them
plasmashellMulti Screen Support
  • Ordinary application windows appear on the wrong screen or get moved in unexpected screens when screens are connected/disconnected
  • Some screens are black and is not possible to move the mouse inside those, but they look enabled in the systemsettings displays module or in the output of the command kscreen-doctor -o
kwinmulti-screen
  • The systemsettings displays module shows settings that don’t match reality
  • The systemsettings displays module shows settings that don’t match the output of the command kscreen-doctor -o
systemsettingskcm_kscreen

In order to have a good complete information on the affected system, its configuration, and the configuration of our multiscreen management, if you can, the following information would be needed:

  • Whether the problem happens in a Wayland or X11 session (or both)
  • A good description of the scenario: how many screens, whether is a laptop or desktop, when the problem happens (startup, connecting/disconnectiong, going out of sleep and things like that)
  • The output the terminal command: kscreen-doctor -o
  • The output of the terminal command: kscreen-console
  • The main plasma configuration file: ~/.config/plasma-org.kde.plasma.desktop-appletsrc

Those items of information already help a lot figuring out what problem is and where it resides.

Afterwards we still may ask for more informations, like an archive of the main screen config files that are the directory content of ~/.local/share/kscreen/ but normally, we wouldn’t need that.

One more word on kscreen-doctor and kscreen-console

Those 2 commands are very useful to understand what Plasma and the rest of the system thinks about every screen that’s connected and how they intend to treat them.

kscreen-doctor

Here is a typical output of the command kscreen-doctor - o:

Output: 1 eDP-1 enabled connected priority 2 Panel Modes: 0:1200x1920@60! 1:1024x768@60 Geometry: 1920,0 960x600 Scale: 2 Rotation: 8 Overscan: 0 Vrr: incapable RgbRange: Automatic
Output: 2 DP-3 enabled connected priority 3 DisplayPort Modes: 0:1024x768@60! 1:800x600@60 2:800x600@56 3:848x480@60 4:640x480@60 5:1024x768@60 Geometry: 1920,600 1024x768 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic
Output: 3 DP-4 enabled connected priority 1 DisplayPort Modes: 0:1920x1080@60*! 1:1920x1080@60 2:1920x1080@60 3:1680x1050@60 4:1600x900@60 5:1280x1024@75 6:1280x1024@60 7:1440x900@60 8:1280x800@60 9:1152x864@75 10:1280x720@60 11:1280x720@60 12:1280x720@60 13:1024x768@75 14:1024x768@70 15:1024x768@60 16:832x624@75 17:800x600@75 18:800x600@72 19:800x600@60 20:800x600@56 21:720x480@60 22:720x480@60 23:720x480@60 24:720x480@60 25:640x480@75 26:640x480@73 27:640x480@67 28:640x480@60 29:640x480@60 30:720x400@70 31:1280x1024@60 32:1024x768@60 33:1280x800@60 34:1920x1080@60 35:1600x900@60 36:1368x768@60 37:1280x720@60 Geometry: 0,0 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic

Here we can see we have 3 outputs, one internal and two via DisplayPort, DP-4 is the primary (priority 1) followed by eDP-1 (internal) and DP-3 (those correcpond to the new reordering UI in the systemsettings screen module).

Important data points, also the screen geometries (in italic in the snippet) which tell their relative positions.

kscreen-console

This gives a bit more verbose information, here is a sample (copied here the data of a single screen, as the output is very long):

Id: 3
Name: "DP-4"
Type: "DisplayPort"
Connected: true
Enabled: true
Priority: 1
Rotation: KScreen::Output::None
Pos: QPoint(0,0)
MMSize: QSize(520, 290)
FollowPreferredMode: false
Size: QSize(1920, 1080)
Scale: 1
Clones: None
Mode: "0"
Preferred Mode: "0"
Preferred modes: ("0")
Modes:
"0" "1920x1080@60" QSize(1920, 1080) 60
"1" "1920x1080@60" QSize(1920, 1080) 60
"10" "1280x720@60" QSize(1280, 720) 60
"11" "1280x720@60" QSize(1280, 720) 60
"12" "1280x720@60" QSize(1280, 720) 59.94
"13" "1024x768@75" QSize(1024, 768) 75.029
"14" "1024x768@70" QSize(1024, 768) 70.069
"15" "1024x768@60" QSize(1024, 768) 60.004
"16" "832x624@75" QSize(832, 624) 74.551
"17" "800x600@75" QSize(800, 600) 75
"18" "800x600@72" QSize(800, 600) 72.188
"19" "800x600@60" QSize(800, 600) 60.317
"2" "1920x1080@60" QSize(1920, 1080) 59.94
"20" "800x600@56" QSize(800, 600) 56.25
"21" "720x480@60" QSize(720, 480) 60
"22" "720x480@60" QSize(720, 480) 60
"23" "720x480@60" QSize(720, 480) 59.94
"24" "720x480@60" QSize(720, 480) 59.94
"25" "640x480@75" QSize(640, 480) 75
"26" "640x480@73" QSize(640, 480) 72.809
"27" "640x480@67" QSize(640, 480) 66.667
"28" "640x480@60" QSize(640, 480) 60
"29" "640x480@60" QSize(640, 480) 59.94
"3" "1680x1050@60" QSize(1680, 1050) 59.883
"30" "720x400@70" QSize(720, 400) 70.082
"31" "1280x1024@60" QSize(1280, 1024) 59.895
"32" "1024x768@60" QSize(1024, 768) 59.92
"33" "1280x800@60" QSize(1280, 800) 59.81
"34" "1920x1080@60" QSize(1920, 1080) 59.963
"35" "1600x900@60" QSize(1600, 900) 59.946
"36" "1368x768@60" QSize(1368, 768) 59.882
"37" "1280x720@60" QSize(1280, 720) 59.855
"4" "1600x900@60" QSize(1600, 900) 60
"5" "1280x1024@75" QSize(1280, 1024) 75.025
"6" "1280x1024@60" QSize(1280, 1024) 60.02
"7" "1440x900@60" QSize(1440, 900) 59.901
"8" "1280x800@60" QSize(1280, 800) 59.91
"9" "1152x864@75" QSize(1152, 864) 75
EDID Info:
Device ID: "xrandr-Samsung Electric Company-S24B300-H4MD302024"
Name: "S24B300"
Vendor: "Samsung Electric Company"
Serial: "H4MD302024"
EISA ID: ""
Hash: "eca6ca3c32c11a47a837d696a970b9d5"
Width: 52
Height: 29
Gamma: 2.2
Red: QQuaternion(scalar:1, vector:(0.640625, 0.335938, 0))
Green: QQuaternion(scalar:1, vector:(0.31543, 0.628906, 0))
Blue: QQuaternion(scalar:1, vector:(0.15918, 0.0585938, 0))
White: QQuaternion(scalar:1, vector:(0.3125, 0.329102, 0))

Important also the section EDID Info, to see if the screen has a good and unique EDID, as invalid Edids, especially in combination with DisplayPort is a known source or problems.

Multi Screen

BlaBlaSoftware

Ah, working with more than one screen, nice and convenient, but always has been the scourge of usability, due to broken hardware and software, on every platform you can imagine. And yes, on Plasma we are notorious to have several problems with regard to multi screens, which spurred many bug reports.

TL;DR

For Plasma 5.27 we did a big refactor on how the screens are managed (and how they are mapped to desktops and panels) which hopefully should solve many of those issues, creating a much more predictable experience, both for “fixed” multi screen setups (like a setup at your desk) and “on the go” (like attaching a projector at a conference).

  • No more default empty desktops after connecting a screen that you already connected in the past
  • No more desktops, wallpapers, widgets and panels lost after restart
  • No more different sets of desktops between X11 and Wayland
  • Better experience when using USB-C based docks

UI wise on the Systemsettings module nothing will change in the most common case, when you have one or two screens, where you will be presented with the usual “primary” checkbox.

When you have 3 or more screens, instead of s simple “Primary” checkbox, you will be presented with a dialog where you can rearrange the screens in a logical order, so that you can say: “This is my screen number one, this is my screen number two etc.”

Reordering screen priorities

This will map exactly to what “screen number one, two etc” are for the Plasma shell, so that whatever desktops, wallpapers, widgets and panels are on the “screen number one” will always be on the “screen number one”, never disappearing again, same for each screen, giving a completely predictable, and stable multiscreen setup.

For 5.27 I worked mostly on the Plasmashell part, but many thanks and shouts to Ivan for his work on KScreen and to Xaver for his work on the KWin and Wayland protocol parts.

Long story: the moving parts

I would like to do a semi-technical but still quite high level description on how our multiscreen infrastructure works, and what did we change.

When you have multiple monitors connected, assuming the kernel and drivers will do the right thing (which… doesn’t always happen), either X11 or Wayland (so in our case the KWin Wayland compositor) will see the screens and have info about them we can enumerate and manage.

KScreen

In Plasma we have a daemon/library to manage the screens, called KScreen. It will save a configuration for each combination of screens it encountered. each screen is identified uniquely by its EDID, and when this fails for the above reasons, the connector name the screen is connected to (under X or libdrm they will have names like HDMI-A-1, DP-2, eDp1 and so forth). connector names are also not optimal, but is the best that can be done in case of a bad monitor (For 5.27 Xaver fixed a quite big issue on this fallback path which likely caused several of the reported bugs).

The user then can chose with the Systemsetting module how the screens are arranged, their resolutions, which is the primary and what not. When a screen is connected or disconnected, KScreen will search for an existing configuration for this set of screens and restore that one.

Plasma

The Plasma shell also has to be aware of multiple screens arrangement, because you want the desktops with their wallpapers, widgets and icons to be on the screen you expect it to, as well all the panels to be always on the “proper” screen you expect it to. And that’s where we had a lot of problems in the past, and various approaches have been attempted.

Current

Currently, up to 5.26 Plasma relied on two concepts for working out which screen a desktop and panel should be. Combining a single primary monitor and using screen connectors names for disambiguate second and third screens. In theory

There are a couple of things that can go wrong with this: between X11 and Wayland, connector names tend to be different (for instance HDMI-1 vs HDMI-A-1 on my system).

Another problem is related to the the USB-C based docks that have video outputs (such as the Steamdeck one, but is common to any other model and brand). They dynamically create and delete the outputs and connectors when they are plugged and unplugged, but the connector name is not stable between different plugs/unplugs: sometimes after re-plugging the old names are not recycled, but increased (so for instance if those were DP-2 and DP-3, they may become all the sudden DP-4 and DP-5). Since we used to store those names, we have a problem: each time a new connector name is encountered is treated as a completely new thing, giving its new empty default desktop and no panels, causing many wtf moments.

Plasma Containments (technical name of the desktops and panels) always had a screen property associated to them which is just an integer: 0 for the primary screen and then 1,2,etc for the others.

5.27

The new approach builds on a single design, extending the primary monitor concept to multiple monitors, which cleans up the codepaths even for the two monitor case.

So we now dropped this association map between screen number integers and connector names, and we go with this ordered list all the way down, so now Plasma, KWin and KScreen agree exactly who “Screen 1” is.

We have a new Wayland protocol for screen ordering (as well an X11 counterpart) for KScreen and KWin to agree to which one is the real logical ordering of the screens, so Plasmashell will now follow this without attempting to identify monitors by itself, removing a very big failure point.

As said, When your system has only 2 screens, in the Systemsettings module you’ll see exactly the UI it had: just a checkbox to select which one is the “Primary”, so no surprises here. When you have 3 screens or more then you are presented with a dialog where you can visually reorder the screens, to decide which is the first, which is the second etc.

In this way, you’ll always be sure that whichever screen was set as “first” will have your “main” set of panels and desktop widgets, that you will never lose, also whichever you set as “second” will always have the desktop and panels you set it and never change and so on.

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: 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.

KF6 Sprint in Berlin

BlaBlaSoftware

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

GraphicsSoftware

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

GraphicsSoftware

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.

desk

The other component is a tiny little application shipped in the “Plasma Sdk” package that’s called lookandfeelexplorer.
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

BlaBlaSoftware

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