A few weeks ago Qt 6.8 was released, delivering many fixes and improvements for our software. Some of them were contributed by yours truly, and in this post I want to highlight some of them. They relate to graphics tablet/stylus input on Wayland. Before we go into the fixes let’s have a quick overview of the flow of tablet input events on Wayland: The genesis of input events is in the kernel driver for the particular tablet, which talks to the hardware (via USB, bluetooth etc).

This year’s Akademy was a special one for me in many ways. First of all, instead of me travelling to Akademy it took place in my hometown of Würzburg, Germany. While I did have a hand in organizing it, most of the credit for it goes to Tobias and David. I had a lot of fun introducing people to my area and the concept of drinking wine on a bridge.

In a previous post I talked about using the QML Language Server for KDE development. Since writing that post a few things happened, so it’s time for an update. I mentioned that when using Kate qmlls should work out of the box when opening a QML file. That’s mostly true, there is one problem though. Depending on your distribution the binary for qmlls has a different name. Sometimes it’s qmlls, sometimes qmlls6 or qmlls-qt6.

Last week, like many other people, I was in Berlin for the Mega^WGoals sprint. Natually the three goals (Sustainability, Accessibility, and Automatability; the three abilities) attracted a diverse crowd of people that brought also other topics, so it turned into a proper megasprint. Being interested in all three goals made it a bit callenging to follow all relevant discussions unfortunately, but on the flip side it never got boring. Most of my goal-related work was towards the automation goal.

For a while Qt has been offering qmlls, a Language Server Protocol implementation for QML. This allows popular text editors like Kate (and some lesser known ones like Visual Studio Code) to work with QML code without having to write dedicated support for it. Naturally many people are eager to use it to hack on KDE code. When trying to do that you probably have encountered some frustration with things not working as expected.

KNotifications is KDE’s framework for creating popup notifications. It supports Linux, Windows, macOS, and Android, making it, to my knowledge, the most complete cross-platform library for this available in C++. This makes it natually interesting to use for non-KDE Qt application developers. However there is one aspect that makes it less attractive for third-party developers: It’s number of dependencies. As of KNotifications 5.110 it depends on the following other KDE Frameworks:

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.

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.

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?