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 :)
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 …
KDE Ni! OS
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).
System 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.
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.
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.
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)
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: 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
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.
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?
Konqi Christmas post card (CC-BY-SA-4-0 Timothée Giet)
When I suspend my laptop, any video or music stops playing
I can use three fingers on my touch pad to switch virtual desktops
I get a notification when my wireless mouse is about to run out of juice
I can middle-click a window on the task bar to close it
I can have a sticky note in my panel for use as a scratchpad
I can middle-click the notification icon to engage “do not disturb” mode
There’s a handy little color picker widget for my panel
I can throw my cursor into the corner of the screen to peek at my desktop
I can keep any window always on top when I need to
I can create a QR code of anything I copy to my clipboard
When I take a screenshot, I can then just drag it to where I need it
I can change the screen brightness by mouse wheeling the brightness icon
I can drag a window to the top of the screen to maximize it
I can send a window to different virtual desktops by using a global shortcut
There’s a little live volume meter in each slider in the volume popup
I can bring up a little magnifier window around my mouse cursor
I can draw red lines on the screen using a desktop effect
I can use the back/forward mouse buttons on the task bar to change music tracks
When I wiggle the mouse, the cursor gets bigger and bigger, and there’s no limit!
Night light comforts my eyes in the evening hours
KRunner finds browser tabs in the mess of hundreds of tabs I have
I can raise the speaker volume above 100% when needed
I can wheel a window’s title bar to change its opacity to quickly compare stuff
I can use window rules to force apps to open exactly how I want
I can add custom global shortcuts for almost anything
System Monitor displays a tonne of info, including from my solar installation
I can speed up playback of pretty much any video from Plasma’s Media Controller
I can use Meta left click to move and Meta right click to resize a window anytime
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 principlefreebsd-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 upgradeFetch all the things.
freebsd-update -r 15.0-RELEASE installInstall the new stuff.
rebootSmooth 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_ureLoad the kernel driver for the USB-ethernet port.
/rescue/dhclient ue0DHCP 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/mountTo check what the name is of the ZFS mounted on /
/rescue/zfs set readonly=off zroot/ROOT/defaultMake 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.txzFetch the installation tarball.
cd /
/rescue/tar xzf /tmp/base.txz lib/libsys.so.7Extract the missing library.
freebsd-update installThis 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 pkgReinstall with a known-good tool.
pkg updateFetch all the things.
pkg upgradeInstall 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).
After months of being completely consumed by my bachelor thesis and then giving myself some much needed rest, I finally have the time and headspace to sit down and write this post. And honestly, I have been waiting to write about this because Akademy 2025 was special.
This was my first in person Akademy after three years of attending remotely. Every year I would watch talks through a screen, imagining the energy in the room and the hallway conversations I was missing. This time, since my thesis brought me to Europe to work at CERN, I finally had the chance to join everyone in Berlin. KDE made it possible for me to attend in person, and I was also scheduled to give a talk on my Google Summer of Code project, KEcolab, which I currently maintain. So you can imagine how excited I was for this entire week. People say Akademy feels more like a KDE festival than a conference, and I was about to find out why.
I packed my bags in Switzerland and left for Berlin.
Arrival and Welcome Dinner
I reached Berlin on the fifth and went straight to the welcome dinner near Tiergarten. The restaurant had a relaxed vibe, and within minutes I was meeting people I had only ever known through Matrix usernames. Suddenly the names on my screen had real voices and real faces. We talked about everything from new KDE developments and the Banana release to personal side projects and long contribution journeys.
I finally met the KDE Eco team and the people working on the Endof10 campaign which is going amazingly well. We chatted over drinks, laughed a lot, and I might have invited half the table to visit CERN if they ever pass through Switzerland. Dinner was great. I had a pasta salad whose German name I still cannot pronounce, along with some very nice KDE drinks.
I returned late at night and realised that my slides were still not ready. My talk was scheduled for early morning on day one, so I stayed up finishing everything and managed only a few hours of sleep before the big day.
Day One
Day one opened with a keynote by Alexander Rosenthal on Open by Design. It set a very thoughtful tone for the conference. Right after that, I gave my talk titled KEcoLab: KDE’s Automation Tool for Energy Consumption Measurements. You can watch it here: https://youtu.be/ybduSygg2Ns?si=tZlXN7XuGcfyux-Q
The audience asked some great questions about expanding energy measurements to more applications and tools and how the process of measurement works behind the scenes.
Presenting KEcoLab at Akademy 2025
My talk overlapped with the Plasma talk, so I unfortunately could not attend that one. I spent the rest of the day listening to some very inspiring sessions. The KDE annual recap was a highlight, showing how far we have come as a community. It covered improvements across many applications, developments in Kirigami and updates to the new language bindings for Rust and Python. There was also a small peek into what is coming next such as improvements to drawing tablet support and the Plasma keyboard.
If you are interested in contributing to KDE, trust me when I say there are endless ways to do so even if you are not a technical person. You can explore opportunities here: https://community.kde.org/Get_Involved
Day Two
Day Two was packed with talks that focused on being thoughtful developers and maintainers. The keynote by Paloma Oliveira, titled The Politics of the Pull Request, stood out to me. It explored open source from angles we often overlook and gave me a lot to think about.
Paloma Oliveira’s keynote on “The Politics of the Pull Request” - exploring the social and political dimensions of open source collaboration
I also enjoyed talks related to Wayland and Plasma Mobile, and in between sessions I helped volunteer at the welcome desk. At the end of the day, we all gathered at C Base for the social event. Great pizza, great people, great atmosphere.
Day Three
Day Three was dedicated to BoFs. I attended the KDE Goals BoF and then started preparing for the KEcolab BoF because we had to quickly fix a few last minute issues in the lab setup.
Our session was right after the Okular BoF, which turned out to be perfect timing. The Okular team gave us really helpful input since KEcolab and Okular are working on an ongoing integration. We talked about the possibility of running individual energy tests on different components and many other ideas. You can follow the issues we discussed here: https://invent.kde.org/sdk/kecolab/-/issues
Day Four
Day Four had more BoFs. I am sad I missed the You Can Dance BoF because it sounded like everyone had a lot of fun. I joined the KDE Out of Experience BoF and the KDE Flatpak BoF instead, both of which were genuinely interesting.
Day Five
Akademy day trip. This was incredibly fun. We were split into groups and had to complete different tasks around Berlin. We even had a bear themed challenge which led to some hilarious photos. We placed KDE stickers on poles, shared selfies and enjoyed the entire city.
Exploring Berlin with the KDE community - sticker missions, bear challenges, and unforgettable moments
Later we visited the Computer Museum which was heaven for anyone who loves old hardware. They had everything from retro consoles to the legendary 3dfx Voodoo chips. I spent way too long inside the museum and ended up missing the group that went to the dinner spot afterward.
Classic Macs - The originals that started it all
Day Six
The last official day included the Linux InstallFest. A few new contributors came in to install Fedora KDE on their laptops and it was a relaxing final day. People were packing, saying their goodbyes and heading home. I stayed for the after drinks event and spent the evening talking to more people before ending the day with bittersweet farewells.
But Akademy was not over for me yet.
Day Seven
I stayed an extra day to work on the KEcoLab lab with Joseph and Volker in KDAB, Berlin. Huge thanks to both of them. We switched the lab from KDE Neon to Fedora and set up Wayland. We are now testing ydotool so KEcoLab will run smoothly on Wayland as well. We did ran into few issues with the VNC but it was still productive, fun and a perfect ending to the week.
After lunch I said my final goodbye to Berlin and headed to the airport.
Final Thoughts
Akademy was one of the best conference experiences I have ever had. It was a week full of meeting incredible people, listening to inspiring talks, sharing ideas, social beers and feeling truly part of KDE.
KDE is one of the most welcoming open source communities and I am grateful to every single person who made my time there so special.
Thank you to KDE eV for sponsoring my attendance. Thank you to everyone I met for the warm conversations and kindness. I will not list names because I would definitely miss someone but you all made this Akademy unforgettable.
A special thanks to my KEcoLab team (Joseph, Volker, Kieryn (for the constant help throughout the event, Aakarsh and all past contributors). Also a big thank you to the KDE Eco Team, the EndOf10 team, KDE Promo and the entire KDE family. And of course thanks to the volunteers and organizers who made Akademy perfect from start to finish.
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.
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.
cullmann
@christoph-cullmann:matrix.org
Paloma Oliveira’s keynote on “The Politics of the Pull Request” - exploring the social and political dimensions of open source collaboration
