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.

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.

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.

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.

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

A common papercut in a Wayland session is entries in the task manager showing a generic Wayland icon instead of the proper application icon. Here’s a KWallet window having a generic icon in the task manager (on the right): This is due to the shell not being able to properly map a window to an application. This breaks more things than just icons, but those are often the first thing that is noticed.

Last week I decided to take KDE Itinerary for a test tour. Between the train rides there was also time for some KDE stuff. FOSDEM After writing an exam on Friday afternoon I took a train to Frankfurt. I did so not to enjoy the beautiful scenery of the area around Frankfurt central station at night but to be able to catch an early train towards Bruxelles for my first time at FOSDEM.

Last week I took a train to Berlin for the KDE Frameworks 6 kickoff sprint. A lot has been said about it by my fellow attendees already, so I won’t go into detail much. Work on Qt 6 has begun and with Qt 6 a version 6 of the KDE Frameworks is due. This will gives us the opportunity to clean up and redesign some of our API. Main goal for the sprint was to discuss the major design principles for KF6.

As most of you know KDE Connect has recently been removed from Google Play due to a policy violation with regard to our SMS and telephony features. While the public outcry helped to get it back in with all features remaining this is just yet another example of how new Android policies make it harder for us to maintain the level of quality and features you expect from KDE Connect. Android Oreo forced us to drop support for older Android versions and imposed restrictions on background services which force us to have an annoying persistent notification.