This weekend, I attended the KDE PIM 2025 Sprint (AKA meeting) in Paris.

First, what does PIM mean? Personal information management.

Second, what does Personal information management mean? It's the software for managing email, calendar, address book, etc.

Third, this is going to be long, so let me thank https://haute-couture.enioka.com/en/ for hosting us (their office  is in Rue du Mail which seems very fitting for a meeting improving e-mail software) and thanks to KDE e.V. for sponsoring travel and hotel for the meeting. If you can, please donate so that more meetings like this can happen. 

This was my first time attending a PIM sprint even though I have been a KDE developer for a long time and a KMail/KOrganizer user for possibly even longer. 

It is true that these softwares are not in the most polished state, but honestly I would not know how to handle my email without KMail.

Anyhow here's a list of things I did: 

We talked a bit about bugs handling and it turns out not a lot of people are having a look at bugs, so I volunteered to watch the pim-bugs-null@kde.org address in Bugzilla (where most/all related bugs are assigned to) so I can help a bit. Note that I only committed to quickly read over them to try to make sure "really bad things" don't get overlooked. "Normal" bugs will always exist in every software and those will be fixed when they are fixed :)

If you also want to help you can set yourself to watch that pim-bugs-null@kde.org address in https://bugs.kde.org/userprefs.cgi?tab=email. 

On the topic of bugs, I managed to fix "left-click does not work on links with target="_blank" in HTML e-mails" with an impressive 1-liner change. It should be available with KDE Gear 25.12.1.

On Friday night, I experienced "sending emails does not work". After a few hours of debugging and thanks to our sysadmins, we found out it was due to "Your SMTP configuration was wrong". It seems older KMail versions were a bit more gracious when your configuration was wrong, but now it fails (fair enoug, although ideally it could give a better error). Incidentally I was not the only one with this problem since a few hours later we got this bug https://bugs.kde.org/show_bug.cgi?id=513284 that was basically the same. (My watching of pim-bugs-null@kde.org was already fruitful!)

On Saturday morning, I continued scratching my own itch and fixed a rather obscure bug where some context menu actions when right clicking on emails in KMail were not properly updated when expanding/collapsing threads.

KMime is undergoing API modernization and is slated to become a KDE Framework soon (TM). I helped a bit adapting code that uses KMime to the new API. 

On Sunday, I worked a bit on polishing address suggestion blacklisting on KMail (i.e. when I search for Foo, I don't want to get a suggestion to send an email to their old employer's email address). You can do that right now by right clicking on the "To" text field and selecting Completion Configuration and then going to the third tab. But that is a bit cumbersome (to the degree I had no idea that feature existed until the very same day). To make it a bit easier to discover, i have proposed adding a right click menu on the suggestions themselves that let's you blacklist that particular email address.

And now, a short list of things we did: (many more were done and will be explained in detail by other folks)

• Talk about switching the default backend to SQLite instead of mysql MariaDB. In general dropping servers (MariaDB/postgres) support would help making the code more maintainable. There are some people using it without problems, but Nico volunteered to do a test run during the sprint and he ended up with some problems, so there's still some things to debug there.
• Talk about doing a survey/adding more KUserFeedback data. We kind of agreed that first we need to know what question we really want to know the answer to and what would be the consequences of a given answer before spending time in designing a survey. But anyway if you use the KDE PIM software, please enable User Feedback in the settings, we promise we won't spy on you.
• New online accounts system. It should replace the not very useful accounts system that we now have (that also has a quite complicated dependency chain). It showed quite some promise in making things much more user friendly.

All in all it was a very productive meeting and I am happy to have attended.

On a closing note, one day we will have to speak about potentially sponsoring food for sprint attendees. We got travel and hotel sponsored, but I spent around 100 € on breakfast/lunch/dinner for that sprint (not going to any fancy place at all). Yes, I can spare that amount of money, but maybe some others in the community can not, and for sure we want them to also attend. One could even argue that having to spend money on top of spending a weekend and 2 work-holidays for the travel is a bit too much, it won't be me because I ❤️ KDE but someone could argue it 😁

KDE Gear 25.12 got just released.

This includes my fixes (or workarounds) for Konsole & Kate window activation on Wayland.

If you now start Kate or Konsole inside Konsole, the new processes will properly activate their windows to come on top of Konsole.

This works both for just starting new instances and for re-using already running ones.

For more details, see my older post about the implementation.

At the moment that only works for Konsole & Kate.

If that works nicely for our users, perhaps somebody will come up with a more generic way for that or we can move that workaround to some lower level of the stack.

:) For me that is already a nice Christmas present, I disliked that this was broken for years :)

Btw., thanks again for the amazing end of the year fundraiser results! €280k and counting :)

Feedback

You can provide feedback on the matching Reddit post.

At this year’s Akademy (the yearly conference and gathering of KDE), there were several talks about immutable Linux distributions born inside KDE. The first, and more covered in the news was KDE Linux, the distro with an officially sounding name. And the second one was KDE Neon Core, which sounds like a continuation of KDE Neon, but is quite independent of it.

Things shouldn’t come in twos. There needs to be another immutable KDE distro, so I’m announcing the …

Now, this is a bit of a joke.

This is not really going to be a new distribution (for real, not like KDE Neon claimed not to be a distribution back in the day :) ). I don’t have the expertise nor the time to make a distribution from scratch.

But, while listening to the presentations about KDE Linux and KDE Neon Core, I had the idea to see how many of the planned features for those distributions I could implement based on an already existing and quite popular distribution called … if you have a keen eye, you might have guessed based on the image above … NixOS.

Step 1: Immutability

At the crux of it, immutability (along with other related buzzwords) means that you can not have an update break your system. There are no half-updates, no mixing incompatible versions of packages, etc. And if something gets broken with the new version, you can always roll back your system to a previous version.

This comes out of the box with NixOS. It just does it in a different way to other distributions. Its package manager allows installation of as many versions of a single package as needed, and the user or a running application “sees” only the versions they are compatible with.

When you update your system, the old packages are still installed, and you can reboot the computer into the pre-update state (previous versions are called generations).

Booting into an old state doesn’t really do anything special, it just makes you “see” the versions of the packages that were active in that version of your system. You don’t even need to reboot most of the time – if you see that a new version of LibreOffice doesn’t open your file correctly, and you want to try with the previous version, just ask Nix to launch the old version for you. The old version of LibreOffice is still on your system even if you’ve not booted into the system version (generation) it was installed on.

Steps 2..n

My main computer is (and always will be) Debian, but I’ve been using NixOS on my laptop for months now. And it works quite well.

As NixOS can be installed or replicated from a single configuration file, I plan to create a repository that will hold the definition of the system on my laptop (aka, the reference installation of KDE Ni! OS :) ) and to keep it updated while I go through each of the steps of simulating other distributions’ features.

This way, anyone who wants to have KDE Ni! OS on their computer will be able to install it by installing NixOS and using this file for system definition.

The next step will mainly be for developers – it will be about replacing a system package with a version you (or somebody else) developed. For example, if you want the Plasma Vault to behave a bit differently, or to test a fix for a bug you found, any sane distribution should allow you to do that easily, and without endangering the system integrity (no sudo make install). So, KDE Ni! OS will have to be able to do it as well.

I hate waiting for compilations. For day-to-day it may only be a minute or two, but once you start doing another task, the context switching distracts from what you were doing before and breaks everything up. Life is too short to be waiting for computers.

Obviously the first answer is to have a faster machine, but having a super fast laptop and a super fast PC all the time contributes to e-waste which I also hate. Some of my test devices for touch and tablet work are 5 year old Intel atom devices that I still sometimes need to compile on to fix things.

The solution is distributed compiling, using multiple computers to share the work.

Icecream or distcc used to be the tools back in the day, but they're both quite dated and have other issues.

There's a relatively new kid on the block, sccache. sccache primarily serves as a way of keeping your cached compiled assets around (think ccache), but also sharing them across users. Sharing cached assets requires exactly matching paths and dependencies and compilers so it's not that great for my needs; but it seems it would be perfect for flatpak and immutable cases.

But sccache also has another trick up it's sleeve; distributed compilation.

The documentation for sccache is a bit overwhelming packed with enterprise level features https://github.com/mozilla/sccache/blob/main/docs/Distributed.md.
It wasn't that clear how to do something simple, so I thought it might be useful to share how I got things working nicely for me.

Installation

Sccache is probably available in your distribution, note that not all distros include the shared compiler part.

If not you can download a version from https://github.com/mozilla/sccache/releases/download

The nice part is it's statically linked with no external dependencies so you can throw it on anything, even if it's immutable like KDE Linux or even a Steamdeck or two.

The parts

Scheduler

The scheduler is the key part of the operation; the client sends requests to the scheduler which in return replies with a list of schedulers that can recieve payloads distributing them accordingly.

Simple

Create a file as follows:

scheduler.conf

public_addr = "0.0.0.0:10600"
client_auth = { type = "token", token = "dave_is_great" }
server_auth = { type = "token", token = "dave_is_great" }

sccache-dist scheduler --config scheduler.conf

Docker

As I want the scheduler always on, I run it on a small home-server, where I prefer to docker-ise everything.

docker-compose:

version: '3.8'

services:
  sccache-scheduler:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        VERSION: "v0.10.0"
        SHASUM: bbf2e67d5e030967f31283236ea57f68892f0c7b56681ae7bfe80cd7f47e1acc
    image: sccache:latest
    container_name: sccache-scheduler
    ports:
      - "10600:10600"
    volumes:
      - ./scheduler.conf:/scheduler.conf:ro
    entrypoint: ["/usr/local/bin/sccache-dist", "scheduler", "--config", "/scheduler.conf"]
    restart: unless-stopped
    environment:
      - SCCACHE_NO_DAEMON=1

Dockerfile

FROM alpine:3.9.2

ARG VERSION
ARG SHASUM

RUN apk add clang
RUN apk add curl
RUN apk add --no-cache bubblewrap

RUN curl -L https://github.com/mozilla/sccache/releases/download/$VERSION/sccache-dist-$VERSION-x86_64-unknown-linux-musl.tar.gz > sccache-dist.tar.gz \
    && tar xf sccache-dist.tar.gz \
    && mv sccache-dist-$VERSION-x86_64-unknown-linux-musl/sccache-dist /usr/local/bin/sccache-dist \
    && rm -r sccache-dist.tar.gz sccache-dist-$VERSION-x86_64-unknown-linux-musl

RUN apk del curl

ENTRYPOINT ["/usr/local/bin/sccache"]

and the scheduler.conf as above.

Servers (build machines)

This is the part that does the building.
The config takes the address of the scheduler, but also the server's own IP address as a sort of "callback" address.

It needs to run as root in order to have capabilities to set up sandboxing and restrict it back down to something lower than where we started. The sitaution is a bit silly, but it is what it is.

server.conf

public_addr = "192.168.1.YOURIPADDRESS:10501"
scheduler_url = "http://192.168.1.SCHEDULERIPADDRESS:10600"
cache_dir = "/tmp/toolchains"
scheduler_auth = { type = "DANGEROUSLY_INSECURE" }

[builder]
type = "overlay"
# The directory under which a sandboxed filesystem will be created for builds.
build_dir = "/tmp/build"
# The path to the bubblewrap version 0.3.0+ `bwrap` binary.
bwrap_path = "/usr/bin/bwrap"

Then you can run sudo sccache-dist server --config server.conf

Systemd

As I want this running constantly on my desktop and laptop I use a systemd service.

/etc/systemd/system/sccache.service
[Unit]
Description=sccache scheduler
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/sccache-dist server --config /etc/sccache/server.conf
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Clients

The final part is relatively simple, making local builds use the other build servers.

First we need to set up a config as follows:

.config/sccache/config

[dist]
scheduler_url = "http://192.168.1.SCHEDULERIPADDRESS:10600"
toolchains = []
toolchain_cache_size = 5368709120
auth = { type = "token", token = "dave_is_great" }

Cmake

Enabling requires just telling cmake to use the relevant wrapper with -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache

kde-builder

And/or it to your kde-builder as follows:

.config/kde-builder.yaml

global:
  cmake-options: -GNinja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON  -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache 

and reconfigure the project(s)

Quirks and workarounds

The most annoying quirk is servers need a consistent IP address within your network. Servers register to the scheduler with a fixed IP address. When clients queue jobs they are given the IP addresses back from the scheduler and are expected to then talk to the build server(s) directly. Using hostnames doesn't work.

Note also if you change your local .config/sccache you may need to run sccache --stop-server on the client to relaunch. Confusingly in this case 'server' refers to a process on the client that compile jobs are thrown at.

Debugging

sccache --dist-status will show the connected schedulers and how many total active jobs

Managing job count

By default ninja schedules the same number of jobs as you have local cores for. It's unaware of the many other cores you have.
I have this in my zshrc to set the number of jobs to the total number on the scheduler at that time.

function getSccacheCPUs() {
        sccache --dist-status  | jq '."SchedulerStatus"[1].num_cpus'
}
alias ks='MAKEFLAGS=-j${getSccacheCPUs} kde-builder'

Comparison to icecream

Cons:

• The setup process is a lot more laborious than icecream's magic turn-up-and-compile structure
• No cool UI to see how many tasks are being compiled.

Pros:

• It's very robust to network issues. If the scheduler is down or no servers are available things build locally extremely transparently
• It also has it's own equivalent of a local 'ccache' which means you don't need to worry about daisy-chaing compilers wrappers to still have cached output.
• It's actively maintained, the last meaningful commit in icecream is years ago

Today we're releasing Krita 5.2.14. This is going to be the last bug fix release for 5.2. This release in particular contains many bug and usability fixes for Android.

Touch-and-Hold Color Picker

The color picker has been improved to make it look, feel and function better. The most important change is for touchscreens: you can now press the screen with one finger and hold it in the same spot to bring up the color picker. This is enabled by default in all input profiles. If it doesn't happen for you, either reset your canvas input settings to the defaults or manually assign the One Finger Hold gesture like this:

New Color Picker Preview

Aside from that, the preview has also been changed from the rectangles side by side to a circle around the cursor. This gives better visibility to the colors you are picking and also means that your right hand won't obscure the preview if you're drawing on a screen tablet. If you don't like the way this looks, you can change the appearance of the circle in the settings or go back to a two-rectangles style preview instead. Except now you can choose whether you want them on the right like before, on the left or on top of the cursor. Additionally, the long-standing issue of the preview getting rotated and mirrored along with the canvas has been fixed. It will now show up in the same spot no matter how you spin it.

Changelog:

Beyond that, we have a ton of smaller usability fixes for touch, a new icon on MacOS and much more.

Special thanks to Freya Lupen, Stuffins, Joshua Goins in addition to the sponsored developers.

• Fix brush preview outlines being aligned based on incorrect bounding box. (Bug 477164)
• Don't require restart for touch painting change and Automatically detect touch painting
• [android] Fix main window not showing document (Bug 488606)
• Fix off-by-1 in BrushHud Deform Modes combobox (Bug 509741)
• Double-click slider spin boxes to edit
• [android] Disable long-press right-click emulation
• Allow long-pressing to open context menus
• Various error handling fixes on android so it tries to recover instead of asserting.
• [android] Make IAP and supporter badge work again
• Make curve autosmooth work with touch drawing (Bug 510363)
• Make multi-clicking work with touch painting
• Disable left-click kinetic scrolling on timeline (CCBug 474975)
• Enable double and triple click with stylus when using vector tools.
• Check whether the splash is valid (Bug 491279)
• [android] Make main window fullscreen by default
• [android] Don't exit fullscreen when pressing back
• [android] Remove fullscreen toggle in status bar
• Fix hidden brush editor titlebar (Windows + Android) (Bug 452804)
• Add toggle eraser preset touch canvas input
• Make sliders not show selection handles on Android
• Properly calculate long-press slop distance
• Make long-press context menus behave more cleanly
• Make kinetic scrolling not delay long presses
• Disable long-press on widgets they interfere with
• Make popup menus appear at touch position
• Make edit shapes tool work with touch drawing (Bug 511594)
• [android] Enter fullscreen early to avoid flicker
• fix Node::setChildNodes
• fix histograms when adding a new filter layer
• Fix various touch shortcuts with wrong actions (Bug 485161)
• Make sampler preview not rotate/mirror with canvas (Bug 347799)
• Implement one-finger touch and hold gesture
• PythonPluginManager: Fix crash on Python 3.14
• macos: update krita app icon to display in respect to system appearance
• macos : make thumbnails of kra, krz and ora (Bug 493474)
• Don't allow dragging layers onto their own canvas (Bug 512771)
• Allow holding Ctrl to override drag on canvas
• [android] Write to temporary file when saving (Bug 498257)
• [android] Make shortcut input work properly
• Fix crash when using a smudge brush (Bug 512243)

Download

Windows

If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

[!NOTE] We are no longer making 32-bit Windows builds.

• 64 bits Windows Installer: krita-5.2.14-setup.exe
• Portable 64 bits Windows: krita-5.2.14.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

Note: starting with 5.2.11, the minimum supported version of Ubuntu is 22.04.

[!WARNING] Starting with 5.2.11 has updated the AppImage runtime, which is known to be incompatible with the old versions of AppImageLauncher. Developers of the AppImage runtime suggest to remove or update AppImageLauncher. See this report: Issue 121 More AppImage troubleshooting info is available here: FUSE

• 64 bits Linux: krita-5.2.14-x86_64.AppImage

MacOS

Note: We're not supporting MacOS 10.13 anymore, 10.14 is the minimum supported version.

• MacOS disk image: krita-5.2.14.dmg

Android

We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.

• 64 bits Intel CPU APK
• 64 bits Arm CPU APK
• 32 bits Arm CPU APK

Source code

• krita-5.2.14.tar.gz
• krita-5.2.14.tar.xz

md5sum

For all downloads, visit https://download.kde.org/stable/krita/5.2.14/ and click on "Details" to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

KDE’s 30th birthday is coming up next year. For this year’s holiday season I therefore decided to compile a list of 30 reasons why I love KDE Plasma. It makes me so much more productive and work a lot more fun. While some of the items listed below aren’t unique to Plasma, it’s the combination of all of those things that truly makes it the best desktop environment out there. Tell me, what are your top reasons?

1. When I suspend my laptop, any video or music stops playing
2. I can use three fingers on my touch pad to switch virtual desktops
3. I get a notification when my wireless mouse is about to run out of juice
4. I can middle-click a window on the task bar to close it
5. I can have a sticky note in my panel for use as a scratchpad
6. I can middle-click the notification icon to engage “do not disturb” mode
7. There’s a handy little color picker widget for my panel
8. I can throw my cursor into the corner of the screen to peek at my desktop
9. I can keep any window always on top when I need to
10. I can create a QR code of anything I copy to my clipboard
11. When I take a screenshot, I can then just drag it to where I need it
12. I can change the screen brightness by mouse wheeling the brightness icon
13. I can drag a window to the top of the screen to maximize it
14. I can send a window to different virtual desktops by using a global shortcut
15. There’s a little live volume meter in each slider in the volume popup
16. I can bring up a little magnifier window around my mouse cursor
17. I can draw red lines on the screen using a desktop effect
18. I can use the back/forward mouse buttons on the task bar to change music tracks
19. When I wiggle the mouse, the cursor gets bigger and bigger, and there’s no limit!
20. Night light comforts my eyes in the evening hours
21. KRunner finds browser tabs in the mess of hundreds of tabs I have
22. I can raise the speaker volume above 100% when needed
23. I can wheel a window’s title bar to change its opacity to quickly compare stuff
24. I can make the Copilot key on my keyboard actually do something useful
25. I can use window rules to force apps to open exactly how I want
26. I can add custom global shortcuts for almost anything
27. System Monitor displays a tonne of info, including from my solar installation
28. I can speed up playback of pretty much any video from Plasma’s Media Controller
29. I can use Meta left click to move and Meta right click to resize a window anytime
30. I can quickly access recent files opened in an app by right clicking its task bar entry

… and that is just Plasma, not even mentioning fantastic apps like the Dolphin file manager, Konsole, Kate editor, and of course KDE Connect. Another way to show your love for KDE is by donating to our Year End Fundraiser and maybe even adopt an app!

Akademy is a special event for most of KDE people, it is opportunity for KDE developers, designers, users etc to meet and greet each other face-to-face. I have been attending most Akademies since year 2014. So of-course this year also I attended Akademy 2025 in Berlin. Last time I was in Berlin was right before pandemic happened, attending KDE Plasma Mobile Sprint in KDAB offices. It’s always lovely to visit this beautiful city!

Naïvely, I ran freebsd-update -r 15.0-STABLE install in my regular FreeBSD desktop. That was a mistake.

In principle freebsd-update is the way to update the installed system. In principle it works really smoothly, from binary release to binary release: it has a good manpage which tells you you can go from release to release. My FreeBSD laptop (which also runs Fedora 42 as more of a daily-driver OS) was running 14.3, so:

• freebsd-update -r 15.0-RELEASE upgrade Fetch all the things.
• freebsd-update -r 15.0-RELEASE install Install the new stuff.
• reboot Smooth sailing.

That is the naive and optimistic thing to do.

If you spotted “make sure you read the announcement and release notes” in the manpage, good for you.

After the reboot, I was dropped into a shell where nearly every command I typed in resulted in

ld-elf.so.1: Shared object "libsys.so.7" not found, required by "libc.so.7"

Good Bug Reports Help

Fortunately, Graham Perrin had already reported this with basically-the-same steps to get into trouble.

And based on that Matthew and Colin made a fix so that other people could first update their packages (e.g. pkg update on the system before using freebsd-update) to get the fixes in to the package-manager.

Good Workarounds, Also

In the same PR (Problem Report), Craig describes a workaround which almost worked for me. Because it’s a laptop, I needed a few extra steps. As an aside, /rescue is a directory where statically-linked rescue binaries live, which don’t suffer from shared-library misery.

• /rescue/kldload if_ure Load the kernel driver for the USB-ethernet port.
• /rescue/dhclient ue0 DHCP to get some network.

I have root-on-ZFS, and in single-user mode this comes up read-only, so switch read-only off. This is different from other (e.g. UFS, ext4) filesystems where mount -o rw,remount would be the thing to do:

• /rescue/mount To check what the name is of the ZFS mounted on /
• /rescue/zfs set readonly=off zroot/ROOT/default Make it read-write.

Edit 2025-12-17: Fixed typo’s in the path of the commands

After that, basically Craig’s steps:

• cd /tmp
• /rescue/fetch https://download.freebsd.org/releases/amd64/15.0-BETA2/base.txz Fetch the installation tarball.
• cd /
• /rescue/tar xzf /tmp/base.txz lib/libsys.so.7 Extract the missing library.
• freebsd-update install This one is the “normal” dynamically-linked one, which works now the missing library is there.

Post-Upgrade Mucking About

Since there wasn’t anything especially configured or complicated on this machine, I reinstalled the package-manager with a hammer and then upgraded all the packages:

• pkg-static install pkg Reinstall with a known-good tool.
• pkg update Fetch all the things.
• pkg upgrade Install all the things.

Somehow I’ve also gotten myself stuck in a “graphics driver causes kernel panic”, state. Which kind of limits the graphics side of things this week. Amusingly AMD GPU stability is listed as a release feature, but #391 and #393 issues tell a slightly different story. I’m glad of bz@’s proposed fix, although I’ll need to rebuild the kernel to try it (which literally means make buildkernel installkernel on FreeBSD, it’s that simple).

The attentive reader will note that yes, Akademy happened in September already. Not the most prolific blogger. Not the most prolific contributor either. But I had already drafted much of this post two months ago, so let's get it out the door. I'll cut all the paragraphs about fun social outings and focus on recapping stuff related to our Input Goal.

A special thank-you to Farid, of Kdenlive and KDE Goals coordination fame, who convinced me to take the trek when I thought perhaps I shouldn't cross the Atlantic twice in a year. I'm glad I went, tons of great sessions and conversations. Powered by your donations, KDE e.V. supported my travel costs and made it possible for me to coordinate with many KDE people in person. Thank you. Yes, you! Anyway.

Talking input

I met my fellow Input Goal co-initiator Gernot (Duha on Matrix) in person for the first time. Together, and alongside reports on the other KDE goals, we delivered our presentation summarizing one year of input improvements. The KDE community made some excellent progress since the goal was chosen, thanks to everyone who contributed towards it! At the same time, there is more work to do and we'd love to see further contributions. Watch the talk for more details.

Our third Input Goal champion, Joshua Goins, had so much to report on improvements for drawing tablet users that he held an entire presentation on that particular topic.

One particular highlight for me was running into Dorota. She has been pushing for improvements to Wayland's input method protocols and had joined our input handling community on Matrix over the past year. Listening to Dorota's cross-desktop experience and plans was super interesting, and I was happy to see her coordinate with KWin maintainers over the course of Akademy. In the time since, some of Dorota's work was included in the latest upstream release of Wayland Protocols as experimental addition. Hopefully this will be further refined and standardized over time.

Andy Betts sat down with me to discuss the UI designs for touchpad gesture customization, following earlier back-and-forth with Natalie and Nate over the summer. Xaver Hugl provided some great feedback at Akademy about my ongoing patch series to implement stroke gesture support in KWin. He also proposed a change that will help with integrating config file support for gesture customization into KWin. This is all still in the works - full disclosure, I've been having somewhat of a hard time recently for unrelated reasons. It now has path simplification (for performance reasons) plus a nice stroke drawing visualization, but still lacking tests and such. Christmas time seems as good a time as any to pick up some slack and push this forward.

In more exciting news, KDE's new on-screen keyboard has seen a significant amount of work in the last few months. Aleix Pol's initial prototype for Plasma Keyboard was supercharged by Devin Lin, who also made it to Akademy but had to take off early. We decided to release Plasma Keyboard independently first, then integrating it into regular Plasma releases in 2026. This 0.1 preview release is now available, you can check if your distribution already ships it, or you can grab the nightly Plasma Keyboard Flatpak to test its latest state. Yes, even input methods will run just fine as Flatpaks.

Meanwhile, somewhere far away across the ocean, a remote partipant was going full steam ahead on another important piece in the input handling puzzle.

GSoC project: Game controller support in KWin

For this year's Google Summer of Code, Yelsin Sepulveda was accepted to improve game controller support in KWin with mentorship by Xaver Hugl and myself. After a strong start, Yelsin was forced to delay the second part of his project due to personal circumstance and Google did not agree to a deadline extension. However! With an excellent work ethic, Yelsin still continued to work on the project and brought it to completion regardless of Google's official approval. The result is an opt-in KWin plugin that's close to getting merged, and will:

• Make KWin aware of game controllers in the first place,
• Prevent system sleep on controller activity,
• Emulate mouse and keyboard input when no other game (or app) uses the controller,
• Deal with the Steam Controller's idiosyncratic "Lizard Mode".
• Provide the foundation for future game controller customization in Plasma.

From the KDE side, we consider this GSoC project a resounding success. If you missed Yelsin's own posts on Planet KDE, his blog posts from mid September and early October cover a lot more detail.

Other exciting developments

Some presentations and conversations that I found particularly compelling, not focused on input.

Thanks to Bhushan Shah, Plasma now knows what made your system wake up from system sleep. Building on this, power management primarily for Plasma Mobile but also Plasma Desktop can improve even further, including the potential for scheduled background tasks and going right back to sleep.

Linux distros have been kind to KDE this year. Neal Gompa presented the Fedora KDE SIG's long-term efforts to ship a premium Plasma experience. Terrific work from these folks, this is now my current favorite distro suggestion for friends & family. Furthermore, Harald Sitter presented the Alpha release of KDE Linux, now happily chugging along on its way to becoming a Beta. This is what I hope to install on my parents' laptops one day. I took a banana from Harald in return for promising that I'll test it out myself. Didn't say when; nonetheless, the promise stands.

I was not expecting to find myself talking to GNOME contributors at Akademy, but Lorenz Wildberg from the GNOME Foundation's Board of Directors was a super interesting conversation partner. Long story short, both GNOME and KDE know about their respective shortcomings and are trying to learn from each other's experiences. Sometimes by adopting things that work, sometimes by taking a different route, sometimes just by focusing on our existing strengths and building on those. Either way, listening and reflecting will beat low-effort snark anytime. SDK evolution, contributor onboarding, governance, fun times.

Looking back and ahead

Yes, I lost a few weeks from getting a back injury soon after Akademy. The good news is that it's pretty much all healed at this point. But my contribution habits have remained out of whack since. I'm hoping to get this back on track asap, because I also really want to help KDE to reach the inflection point. Gamers, governments and many more people have something to gain if the Linux desktop breaks out of its niche into the mainstream. The tech industry has been disappointing to me on so many fronts. This here, though, is something I'm excited to see happening.

Like in the years before, KDE does an end of the year fundraiser campaign.

Beside that Plasma will show some small popup to ask if you want to sponsor us with a donation.

It looks like this year that is already going well, below the state as of today, 7th December 2025.

I want to say to all that already donated: Thanks a lot!

I will not personally get any money from that, but I will benefit largely from the stuff KDE e.V. funds with it, like the infrastructure, some people working on our stuff and the very important sprints and conferences!

Keep the money flowing, money is not everything, but if you can not contribute in another way and you have some spare money, please consider a donation.

I wish you all a good end of the year :)

Discussion

Feel free to join the discussion at the Linux reddit.