After the criticism in the last post about the limitations of KUserFeedback (KUF) for doing data-driven UX work — let’s get more detailed and constructive:

What insights do we as KDE UX people need to do even better than we are currently doing?

Let us start with what we already get from KUF. We get usage data, like how many people are using Wayland vs. X11. But we only get usage data according to our telemetry policy. So we do not get any deeper insight into how users configure their sessions when using Wayland compared to X11. But this is the kind of information we would need to do proper data-driven UX. What settings are users changing? How many users have icons on their desktop, and which ones? Are people manually mounting network drives? Which System Tray icons are interacted with the most? And so on.

But while this information is already impossible to gather with our current approach, we’re only scratching the surface. We need even deeper UX insights, like understanding where people click. And where they click next (in terms of Markov chains). That way we can understand if people are using Plasma the way we intended when we designed it. Or, how long does it take them to get from point A to point B? Are they taking detours because we’ve laid out paths that users don’t understand in the way we intended?

None of these questions can be answered with our current approach to telemetry.

The basic problem is that we currently send all the raw data to the KDE servers to get the answers we need. And the data we need to collect in order to get the above described desired user insights could of course be used to “identify a specific user” – which is not allowed by our telemetry policy for good reason.

And yet we need even more data. We want to target all users, or only users who exhibit certain behaviors. We want them to fill out questionnaires to better understand why they behave the way they do, to understand their goals and intentions. This would be extremely helpful in understanding bug reports. Or to support our design discussions with relevant data from real users.

All of this can only be achieved with a fundamental change in the way we do telemetry.

Existing alternatives, such as the opt-out Endless OS metrics system, also do not allow enough user insights and share the problem that the data leaves the property of the data owners, the users. That is why we have been working on the privact ecosystem, which allows all the insights described above, while fully preserving users’ privacy. And because of that, we can not only ask for more intimate data, but we can also make participation opt-out and so get data from substantially more people. And why is that? Because with the privact ecosystem, there is no technical possibility that any individual’s personal data can ever be shared remotely. Never. But it would finally enable good user-data-driven UX work. For the sake of KDE and our users.

Please also join the discussion about this issue on invent.kde.org.

Heyho together!

I am from now on writing my posts on GitHub pages. Apart from it being useful to keep my posts versioned using git, I had some issues with my previous blog. The idea was to simply use write.as and publish a post from time to time. This worked well except for more than a month ago me wanting to do a post about my KRunner plugins. It naturally contained a lot of links and thus the publishing was prevented and even the account blocked due to apparent spam. There was no response via mail for over a month.

So here we are not on another blog where I hopefully write more often and also be able to spent more time on KDE!

In the usual frantic activity in the tech sphere I say the innovation we see is limited, while we see an enormous growth of the monopolies in form of vertical silos. Apple’s eco system is closed, and the same applies to for instance Meta’s.

As a result, innovations on the market level remain limited. For instance, the Internet and the Web have innovated and advanced sub optimally the recent years. It is primarily used as infrastructure for these corporations. This needs to change.

Or take that e-books — books and reading, the very foundation of our civilisation — are locked by proprietary DRMs. Perhaps open DRM via blockchain combined with suitable governance is the way to go. This needs to be looked at further.

One effect of the lack of the development and advancement of open technologies is that the common denominator remains low. Innovation stays within the vertical silos, consumers become dependent on them, and the market remains stagnated.

It is my advice to those who want to see real innovation that isn’t locked to companies, involve themselves in the development of open specifications and technologies.

Dear digiKam fans and users,

After five months of active maintenance and many weeks triaging bugs, the digiKam team is proud to present version 8.5.0 of its open source digital photo manager.

Generalities

More than 160 bugs have been fixed and we spent a lot of time contacting users to validate changes in pre-release versions to confirm fixes before deploying the program to production.

Application internationalization has also been updated. digiKam and Showfoto are released with 61 different languages for the graphical interface. Go to the Settings/Configure Languages dialog and change the localization as you want. digiKam needs to be restarted to apply the changes. If you want to contribute to the internationalization of digiKam, please contact the translator teams, following the translation how-to. The statistics about translation states are available here.

KDE Gear is our release service for many apps such as mail and calendaring supremo Kontact, geographers dream Marble, social media influencing Kdenlive and dozens of others. KDE needs you to test that your favourite feature has been added and your worst bug has been squished.

You can do this with KDE neon Testing edition, built from the Git branches which get used to make releases from. You can download the ISO and try it on spare hardware or on a virtual machine to test them out.

But maybe you don’t want the faff of installing a distro. Containers give an easier way to test thanks to Distrobox.

Install Distrobox on your normal computer. Make sure Docker or podman are working.

Download the container with

distrobox create -i invent-registry.kde.org/neon/docker-images/plasma:testing-all

Then start it with
distrobox enter all-testing
And voila it will mount the necessary bits to get Wayland connections working and keep your home directory available and you can run say

kontact

and test the beta for the mail app.

Earlier this year I had the pleasure of visiting the KDE Akademy 2024 in Würzburg. It had been a few years since my last visit to Akademy and it was great to see old friends and meet new ones. Besides socializing, my main task was to talk to as many KDE people as possible about the privact project and its integration into KDE. Knowing the KDE community, not surprisingly this resulted in lots of interesting discussions.

Most importantly, I gave a talk about the current state of privact’s integration with KUserFeedback. If you missed it, here is the recording:

As a follow-up, we had 2 BoFs on Monday to discuss the next steps. Felix was kind enough to join me to provide more technical developer insights than I can give.

As a first teaser for you: In the short term, the privact approach will allow KDE to do proper user research, thereby enabling us to do data-driven UX without compromising user privacy. In the longer term, privact aims to restore digital privacy for everyone, even outside of KDE, even outside of FLOSS. You can learn more in upcoming posts or on the privact homepage.

The individual feedback on the privact approach during Akademy was very good, which is why we now want to start communicating with the larger KDE community. So this post is not only to report about my attendance at Akademy, but also to start blogging again on Planet KDE and to check if the aggregation works.

Hello World Planet KDE!

It was once said over the grapevine that: "Our C++ API documentation has some issues, our QML API documentation has a lot of issues."

And it was true, but that is to change soon! As you might know, there is an ongoing effort to port our documentation from Doxygen to QDoc, and you can help with that.

This is a task that has been adopted by the Streamlined Application Development Experience championed by Nicolas Fella and Nate Graham as part of the KDE Goals initiative.

We would like to invite you to join our porting sprint effort to finish this task. On November 14th at 1PM UTC, we'll be hanging out in the Matrix room working on this. Hope to see you there.

Some prerequisites:

• Ability to use a terminal
• Extra disk space (30GB minimum)
• Some familiarity with APIs

Check out the instructions prepared by Thiago Sueto on how to get started porting a project to QDoc.

Has this ever occurred to you? The most joyful moments of your life got filled with sorrow, a grief of loss…

Let’s talk about the Ubuntu Summit first, my international conference and solo travel outside my country. Probably I am the first from my entire extended family to visit a European country. My parents, well-wishers everyone was so happy. Only person didn’t know much about this, my maternal grandfather, whom I called (yes, “called”, he left us on 27th October 2024) Dada. Let me tell you about the summit first.

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). The kernel passes events to userspace via the evdev system. On the userspace side a Wayland compositor reads those events. Most compositors leverage libinput for this, a library that transforms raw evdev events into something more usable for the compositor while applying some cleaning and configuration. The compositor then delivers events to native Wayland applications using the tablet-v2 protocol. For legacy XWayland applications the compositor uses this protocol to send events to XWayland, which translates them into things X11 apps understand. The compositor can apply useful transformations to the input, like which area of the screen the tablet is mapped to, changing the pressure curve of the pen, or binding buttons to keyboard shortcuts.

The application then processes the events, potentially leveraging a UI toolkit like Qt. Qt creates QTabletEvent object for incoming Wayland events and delivers those to all UI elements. In case no UI element reacts to the event Qt will synthesize a mouse event from the tablet event and deliver that to the UI elements. That way most controls like buttons and menus don’t need special code to handle tablet input. Only when doing very low-level input handling or when needing tablet-specific interactions (like reacting to different pressure values) application developers need to explicitly handle tablet events in their code. Most UI toolkits will work somewhat similar to this. If an application doesn’t react to tablet input at all please file a bug against the application.

Qt Wayland had support for tablet input for a few years now, so what exactly needed fixing? The first thing is cursors. In Wayland the application tells the compositor which cursor to use. This can be done either by specifying a surface (i.e. an image) or a named cursor shape. Guess which one Qt used? That’s right: Neither. It just didn’t specify a cursor at all. The result depends on the compositor: KWin would display a cross-hair cursor as a fallback, which is ~okay, but not the cursor the application developer asked for. On other compositors I’ve tested there will be no cursor visible at all, which isn’t okay at all. For Qt 6.8 I implemented the missing cursor support, so now tablets get the same cursor as mouse input (unless of course the application developer wants a different cursor for tablet input).

Another thing that affected mostly non-Plasma users is client-side decorated windows. On Plasma Qt applications usually use the server-side decoration provided by KWin, but e.g. on GNOME Qt is responsible for drawing and handling window decorations. For this Qt features a plugin system so different decorations with different look-and-feels can be swapped out. Unfortunately those decorations didn’t handle tablet input at all, so it wasn’t possible to move around or close windows using a tablet stylus. I fixed this by pretending the tablet input is mouse input to the decorations, which was a simple yet effective solution for the issue. If there is ever a need for decorations to treat tablet input different to mouse input we can revisit this.

Talking about moving windows, a feature most KDE apps have (even if off-by-default these days) is dragging any empty area to move the window. This wasn’t working when using a stylus. Why? For that we need to look at how this works on a Wayland level. The xdg-shell protocol (the one responsible for most application windows) has a move request that asks the compositor to start a move interaction for the window. As part of the request the application must pass a serial, which is a number that corresponds to the last input event the application has received. To avoid applications suddenly deciding to move in the background compositors usually only allow move requests as a result of direct user input, so this serial must match the last input event. Qt wraps this move request inside the QWindow::startSystemMove function. The problem was that Qt didn’t keep track of the serial it received as part of tablet input, so when starting the move it would pass a wrong serial and the compositor (rightfully) refused the move. A few extra lines later the serial was tracked properly and moving windows with a stylus worked, just in time for Nate to disable the feature by default.

The same problem also affected drag-and-drop. When starting a drag with a stylus Qt now passes the correct serial, making drag-and-drop work (at least on the Qt side, there currently is a bug on the KWin side that prevents this from working).

The last fix for today relates to how applications react to the tablet events. Sometimes applications process clicks differently depending on what keyboard modifiers are pressed. For example pressing Ctrl while clicking on files in Dolphin allows to select multiple files. For this to work Qt conveniently delivers the active modifiers with every input event. Alas for tablet input the modifiers got lost along the way, so it wasn’t possible to select multiple files using a stylus. One small fix later it works as expected.

That’s all the Wayland tablet related fixes for today. If you find more issues in Qt/KDE apps related to tablet input on Wayland please report them on bugs.kde.org and I’ll look into them.

That’s not all there is about Wayland tablet improvements though. Fully in the spirit of the “We care about your input!” Goal there are exiting things happening on the KWin/Plasma side that I’ve been involved in. Stay tuned for more!

In my position of Software Platform Engineer at KDE I work on common building blocks for KDE software, like Qt and KDE Frameworks. This work is possible thanks to your generous donations. Check out our end-of-the-year fundraiser if you’d like to see more work like this.