As you probably have seen from other people’s blog posts there was the 2023 Plasma Sprint last week. It was generously hosted by TUXEDO Computers in their offices in Augsburg, Germany. Many thanks to TUXEDO for that!

Other people have already well summarized what happend there, so let’s have a look at what I have been doing:

Together with Kai Uwe, Volker, and Ismael I looked at notifications. This includes internal simplifications in KNotifications, API design questions, a proposed V2 for the notification portal API, and a new UI for per-event configuration in the notification settings module.

A month has passed since my last monthly post about my work as KDE Software Platform Engineer. What have I been up to since then?

As usual not everything I did ended up as committed code. A lot of my work is reviewing other people’s code, discussing ideas, and generally being useful to the community.

One area I’ve been focussing on is our infrastructure for global shortcuts. These are currently handled by the KGlobalAccel framework. This frameworks contains the runtime component that manages global shortcuts as well as an application-facing library to interact with the runtime. The runtime and interface library being in the same project has caused us some issues in the past. To address these the runtime part is now split out into a separate project and part of the Plasma group. You can read up more details on this here. This change also allowed for some further changes that made launching applications from global shortcuts both simpler code-wise and more robust. I have also worked on another set of changes that will address some of the pain points that are currently present in our global shortcuts system. While doing that I also addressed some issues I found in the underlying KDE Frameworks libraries.

It’s been a month since my first post about my work as KDE Software Platform Engineer, so let’s have a look at what I have been doing since then.

The scope of what falls under “Software Platform” work is arguably quite wide. I like to describe it as “Taking care of everything needed so that people can build and enjoy awesome software”. Of course that often means hacking on source code, but that is by no means the only thing I do. A significant part of what I do is talking to other people, discussing ideas, reviewing code, making architecture decisions, documenting things, triaging bugreports, and just generally being useful to others. A lot of this work is strategic in nature and the benefits will only show in the long term, but some short-term improvements happend this month also.

As you probably have heard by now the lastest development versions of Plasma and KDE Frameworks require Qt6. This transition has been in the works for a few years by now, but it was only somewhat recently that we took the plunge and started relying on Qt6 exclusively for Plasma. Plasma 5.27 is the last Plasma 5 release and continues in bugfix-only mode.

For people who want to hack on Plasma features this raises the obvious question: How do I build Plasma 6 to hack on it?

There has been some recent discussions about how KDE applications (or Qt apps in general) should look and feel like outside of the Plasma desktop, particularly in a GNOME environment.

During this discussion I noticed two major disconnects between the involved parties. One of them is technical in nature, where (understandably) not everyone involved has deep knowledge about how Qt and KDE apps work. The other one is cultural in nature, where there’s opposing views about who gets to decide how an application should look and feel like on a given platform.

Precisely one month ago I joined KDE e.V., the non-profit organization behind KDE, as Software Platform Engineer. This is part of three positions in KDE’s “Make a living” initiative.

The exact scope of this position is a bit vague. I like to describe it as “Taking care of everything needed so that people can build and enjoy awesome software”. A large part of that is taking care of foundational libraries such as Qt and KDE Frameworks, but it can be really anything that helps people do awesome things. This is pretty much what I’ve been doing as a volunteer for the last couple of years anyway.

As you may know KDE consists of many different subprojects, where some projects depend on other projects. Most KDE projects depend on some KDE Frameworks, but other dependencies are also possible, e.g. plasma-desktop depends on plasma-workspace. To be able to automate building projects (for the CI system or tools like kdesrc-build) you need a machine-readable source of dependency information.

For a long time this information has been available in a set of files in repo-metadata. To declare for example plasma-desktop’s dependency on plasma-workspace one would write the line

Last weekend, on May 21st, some people (including me) met in Berlin for what I believe is the first in-person KDE sprint since you-know-what happened (there was LAS, but that’s not technically a KDE sprint). We met in KDAB’s office, which was incidentally also the location of the last in-person sprint before unamed things happened.

Photo by Joseph P. De Veaugh-Geiss.

During the sprint we set up a measurement lab for the KDE Eco initiative. Our goal is to make it as easy as possible for application developers to measure the energy consumption of their applications. To do this a stable and reliable measurement system that is available over a long timespan is needed. KDAB kindly offered to host such a system in their office.

In my last post I talked about why knowing the desktop file for a window is important for the task manager. I promised to talk about some cool stuff we did there in Plasma 5.24, so here we are.

While hacking on the task manager code I noticed that we show a “Open new instance” action in the context menu of every task manager entry, even for those where it doesn’t make sense. A lot of apps are inherently single-window or single-instace, i.e. launching the app a second time will not open a second window but rather focus the existing one. Also, not all windows actually belong to a user-facing or user-launchable application. For example the network integration might ask you for the WiFi password, but you can’t open a new window for that from the task manager. Another kind of app where this actions doesn’t make sense is helper applications like the wizard for connecting to a new bluetooth device.

In my last post I talked about what application developers can do to fix their applications not showing up correctly in Plasma’s task manager. I motivated this by the fact that we need this on Wayland to display the app’s icon. However icons are not the only reason why correctly mapping windows to desktop files is important. It brings substantial benefits even on X11:

• Application titles: In addition to showing the window title Plasma’s task manager also shows the application name (the Name key in the desktop file). If the desktop file can’t be determined it falls back to the executable name, which isn’t particularly nice.
• Jumplist actions: Desktop files allow apps to specify additional application actions. For example Firefox allows you to open a new window or a new private browsing window by right-clicking on the entry in the task manager.
• Media player controls: Plasma’s task manager allows to control application’s media playback. You can e.g. pause a music player by right-clicking on its task manager entry. For this to work the window has to be matched to the MPRIS player instance, which happens based on the desktop file name.
• Recent files: Plasma’s task manager shows you recently used files for an application in the context menu for an application and allows to open that file in the app. This also relies on the desktop file mapping.

Now that we established why it is important to map a window to a desktop file, how is it done?