Happy holidays to all in the KDE universe who celebrate them! As 2025 draws to a close, I thought it would be a good time to take stock.

“This Week in Plasma” began 8 years ago as a development report for KDE’s Usability & Productivity goal, which had just been democratically selected by the community in the very first round of the new KDE Goals process.

Back then it wasn’t called “This Week in Plasma” (or “TWiP” for short), but eventually it would gain and change names, and move off my personal blog and onto KDE’s infrastructure.

During these past 8 years, I’ve done my best to keep the wider KDE community informed about what’s going on almost every week! And I’m constantly amazed and humbled by the positive feedback it’s generated.

The march of time and accumulation of responsibilities

My own role in KDE has changed substantially during these 8 years. I started out in 2017 as a volunteer and fell in love with KDE, squeezing my KDE time into a long daily train commute to and from work. And by 2019 I had a full-time job at Blue Systems, doing what I loved. In 2022 I was elected to the KDE e.V. board of directors, until October of this year. Each of these transitions heralded the accumulation of more responsibilities beyond TWiP.

And at the beginning of this year, everything changed again when I became the co-owner and CEO of Techpaladin Software, the successor of Blue Systems’ consultancy business, and an employer of over a dozen rockstar KDE developers.

This has been the largest career shift in my life, and caused my time to become more limited than ever before. It’s possible some readers may have noticed the quality of TWiP content slipping over the past year; it’s not a coincidence, and I apologize for not being able to do a better job.

I need help

I truly want to keep publishing this blog, but there comes a point where I have to face facts: my time and energy budgets are not as unlimited as I wish they were. In addition, my children are getting older; they’re 9 and 13, and they need their dad to do more than just work and work and work and work and work some more.

So it’s time to begin the painful but necessary process of ensuring that those budgets remain big enough to cover my work and family responsibilities.

In 2026, I’m actively looking for a person or team interested in taking over TWiP. Until then, I plan to reduce the frequency of posts, based on how busy my schedule is. Expect one every two weeks, or even every three or four weeks.

How You Can Help

If anyone reading would like to see TWiP remain a weekly fixture as much as I do, the best way to make it happen is to get involved and help out with it! I would be thrilled to hand off TWiP to the next generation.

Nothing about TWiP is particularly difficult, but it does take time. Time to notice or seek out relevant changes, time to collect them in a big list, time to sort them for relevance to the readership, time to write a little blurb for each of them, time to take screenshots showcasing the changes, and time to edit and polish the post.

I’m happy to teach, coach, or mentor anyone who wants to get involved. So if you’ve been wondering how you can get involved in something that matters without technical skills beyond basic markdown and git, this is a perfect way to do it. And if you are technical, I’m sure there are low-hanging-fruit opportunities for automation that I never pursued (I did try AI a few times, but the results were always horrible).

You can reach out to me about it at nate@kde.org, or the relevant Matrix room, or any other relevant means of getting in touch that you might already know about. Please do!

And finally

I’d like to take the opportunity to thank the readers and community members. This blog post series is something I never really expected to become popular, and it was my pleasure to publish it (almost) every week!

Today Plasma and KDE in general are strong and prosperous, with growing bases of users, hardware partners, distros pre-installing our software, and small-donor financing. In some ways KDE is outgrowing TWiP; it’s no longer really necessary to provide weekly evidence that we’re still keeping the lights on. The evidence is all around us!

But it’s still a nice thing to have, I think. I personally would feel sad if I had to abandon TWiP without anyone to hand it off to. So if you’re interested in getting involved, please reach out!

If helping to take over TWiP isn’t your cup of tea, consider donating to KDE’s 2025 end-of-year fundraiser. It’s already demolished past records by raising over €325,000, but every little bit helps! This level of funding can support significant projects and keep KDE independent for years to come. And that’s what we all want.

So here’s to a great 2025 for KDE, and may 2026 be even better!

At the TUG2025 conference, I presented a talk about the development of a new colour font, which does automatic syntax highlighting for TeX documents/snippets. The idea was floated by CVR, and was inspired by a prior-art of HTML/CSS syntax highlighting font by Heikki Lotvonen.

Syntax highlighting is achieved by specialized grammar files or packages on desktop applications, code editors, the Web, and typesetting systems like TeX. Some of these tools are heavy (e.g. prism.js or pygmentize package). A light-weight alternative would be a font that uses recent OpenType technologies to do syntax highlighting of code snippets. I developed such a font, for highlighting TeX code snippets.

There are some novelties in the developed font:

1. It supports both COLRv0 and COLRv1 colour format specifications (separate fonts, but generated from the same source).
2. Supports plain TeX, LaTeX2 and LaTeX3 macro names.
3. A novel set of OpenType shaping rules for TeX syntax colouring.

The base font used is M+ Code Latin by Coji Morishita. The details of the development, use cases, and limitations can be found in the 46:2 issue of the TUGboat journal publication. The binary font and sources are available at RIT fonts repository.

Happy holidays everyone. Consider this as your holiday card from me. I will be taking short break from KDE stuff for now, though I will be around.

(I tagged KDE so that readers of planet have to see these, mwahaha.)

And happy new year 2026, let's hope it gets better from here.

Lately, this question came up a few times on different channels and I felt to provide some background why things are the way they are.

The question arose most likely, because the latest KMyMoney development snapshot downloaded had a problem and users using that snapshots wanted to return to an earlier version which did not have this problem. At that point they just found out, that those older versions are not available anymore. Therefore, this post will provide some information how the KMyMoney project handles development and which services create binary versions and why older ones disappear.

For that purpose, I created the diagram shown below. It shows the participants in the game enclosed in the areas identified by dashed lines. Those are:

• KMyMoney developers provide the source code that makes up the application
• KDE project and their sys-admins running the CI/CD infrastructure which is used by the KMyMoney team to verify that the software compiles and builds in various environments (Linux, FreeBSD, Windows) and provides executable test versions (snapshots).
• The distribution maintainers who use released source code versions, add distribution specific changes and provide the installable package in the format for the distribution in question (e.g. RPM, DEB, AUR, TGZ, …).

The diagram also shows the means that the various players interact with, namely the GIT repository and the released source tar-balls. And last but not least, it marks the different steps in the processes of snapshots and releases (red circle with white number) which are explained below.

Step 1 is where a source code change happens. This may be a new feature or a bug fix. The developer commits this change to the GIT repository either into a specific branch (e.g. stable or master). I leave out feature branches which also exist but don’t play a role here. Once step 1 is finished, automatically

Step 2 kicks in and the KDE CI/CD system starts a pipeline to build the software and run the automated tests in various environments. In case any of those builds or tests fails, the committing developer gets a notification via e-mail and has the chance to fix the problem by adding another commit in step 1 and thus restarting the process. If all builds and tests finish successfully, the last part of step 2 creates installable versions for different environments as snapshot version and continues with step3.

Step 3.stores the last successful build for download by developers, testers and interested users. Per KDE project policy only the last successful build is kept, which answers the title’s question. Those snapshot versions will show a version x.y.z followed by an 8 digit hash in the Help/About KMyMoney dialog. This 8 digit hash identifies the commit (step 1) that this version is based on. Example: 5.2.1-05390aa93

Steps 1 through 3 can happen multiple times a day.

Step 4 happens, when the KMyMoney developers (or better release manager) create a release. A release does not only contain the source code in a compressed container format and an electronic signature as outlined above, but is also accompanied by the releases notes, change log and the public announcement on blogs, mailing lists, forums, etc. So a bit of work is involved. Step 4 also includes the change of the version number of KMyMoney (which is another step 1 commit) and creating a tag in the GIT repository on the commit that is used to create the tarball. Binaries created based on those tarballs therefore do not show a commit hash in the Help/About KMyMoney dialog.

Step 5 is performed by the release manager with the help of KDE sysadmin. KDE sysadmins take the files and add them to the KDE content delivery network which comprises of mirrors around the world.

Step 6 happens, when distribution maintainers take those source code files and compile and build them into installable packages for their distributions.

Steps 4 through 6 usually happen at a low frequency.

I hope that this explains how the project works and why things are the way they are.

Not shown in the above diagram is the work performed by one developer. He maintains a specific build for MS-Windows versions based on MinGW. Using cross-compiled versions allow to create KMyMoney for Windows including support for AqBanking (online banking features) which is not possible using the MSVC compiler suite. Since he basically uses the above mentioned steps 4, 5 and 6, the resulting binaries unfortunately do not contain the 8 digit hash in the Help/About KMyMoney dialog.

Last weekend I attended the annual(ish) KDE Personal Information Management (PIM) sprint in Paris, to discuss and work on KDE’s infrastructure and applications for dealing with email, calendars and address books. And since this involved travelling, there was some Itinerary field testing as well of course.

PIM Sprint

The PIM sprint was hosted by enioka Haute Couture this time, in their offices in the middle of Paris, which happens to be located in a very appropriately named street for this.

With nine people attending (even if Kévin could only make it remotely in the end) it was actually a new record since moving that event to France many years ago. Even better, for about half of the attendees it was their first PIM sprint ever.

Topics

The following is by no means complete, see also the other reports on Planet KDE such as the one from Albert, as well as the notes on the sprint wiki page.

KMime framework

My focus was mainly on finally pushing the move of KMime to KDE Frameworks over the finishing line. While most review comments collected during Akademy have meanwhile been addressed, the request to make ownership transfers more explicit in the API is still requiring work. Not so much in KMime itself, but it’s exposing sloppy ownership semantics in consumer code such the message composing code in messagelib. Attempting to untangling that has at least already lead to multiple memory leaks being found and fixed.

Message-IDs

We also reviewed the code to generate Message-ID headers in KMime, triggered by a recent forum thread. Message ids have to be globally unique, but the underlying specification and implementation predate UUIDs being widely available (yes, email is that old). Therefore this used to be a combination of a time-based random string and the host name of the sending machine.

That works but is not up to today’s privacy standards anymore. Instead, the de-facto standard nowadays is to combine a UUID-based identifier with the domain of the sender address. The latter is just necessary to comply with the format and doesn’t contribute to the uniqueness. KMail will now do the same.

While that is a minor detail, it’s somewhat symptomatic for working on email-related code, trying to understand decisions made in specifications and code from last century and assessing the implications of changing any of that.

And more

Other topics discussed included:

• Retirement of the Kolab resource. That has been on the agenda since years, and a proposal exists since a while. That hasn’t been implemented yet in the hope for a better solution which never materialized. Meanwhile a library this depends on is no longer buildable on current systems, so the Kolab resource has been silently disappearing from some distributions already, which is far worse than even the most low-effort orderly retirement.
• Flatpak packaging for the Akonadi stack, and the challenges for host integration that come with it. As sharing that between two Flatpak applications and/or to/from the host isn’t really viable, the best we can do is probably a dedicated D-Bus interface for a separate platform calendar backend plugin in KCalendarCore, and use that for host integration like in the Plasma clock.
• Improvements to address auto-completion in KMail, in particular better defaults for filtering “no-reply” addresses.

We also spend some time debugging some weird synchronization issues that David R eventually tracked down to a very recent one-line change. This originally had been mis-attributed to the Sqlite backend for Akonadi while exploring whether that should become the default (with support for the other databases being dropped in the long run), but fortunately turned out to be entirely unrelated to that.

Travel

Travel ended up a bit adventurous and thus provided plenty of opportunity for observing Itinerary and Transitous under unusual circumstances.

• We need a more powerful alternative journey search that doesn’t use the next change as a starting point, but every upcoming stop of the train you are currently on. MOTIS used to have this built-in as so-called on-trip queries, but it would also be possible to emulate this client-side. This helps with situations where the best alternative isn’t just to take the next train after a missed connection, but to continue on the train you are on longer to connect onwards at a later stop.
• We should apply a lower-bound sanity check to realtime data in Transitous. In cases of more complex reroutings and detours Deutsche Bahn’s own projection can contain times which go beyond what’s technically, legally or physically possible.
• Also, crowd-sourced vehicle positions are equally valuable for operators where we usually have realtime data, to further support such sanity checks. Deutsche Bahn’s onboard GPS is actually precise enough (outside of tunnels) to determine the exact track (and thus the speed rating) on OpenRailwayMap.
• Border points reported as dummy intermediate stops without a time or location still slip through on some backends and mess up our progress display in Itinerary.
• Parsing of international DB seat (re)bookings got fixed.

Another interesting observation from a routing perspective were passages in Paris (e.g. Passage Jouffroy or Passage des Panoramas) which in OSM terms are essentially footways with opening hours or conditional access. That is, those work as regular pedestrian ways during the day and are closed at night. OSM can model this for roads and routers can usually deal with that for vehicles, but I haven’t seen this used yet for walking.

You can help!

Getting everyone together for a few days is extremely valuable and productive, and your donations to KDE .e.V. help to make that possible!

Welcome to a new issue of This Week in Plasma!

This week many KDE contributors wound down their activities in preparation for some well-deserved rest. But that didn’t stop the merging of some impactful work anyway!

This will be 2025’s last This Week in Plasma post; I too will take a break next week. Happy holidays for those who celebrate, and I’ll see you all in 2026!

Notable New Features

Plasma 6.6.0

Implemented support for automatic brightness adjustment on devices with ambient light sensors! (Xaver Hugl, KDE bug #502122)

Notable UI Improvements

Plasma 6.5.5

Improved KRunner’s search matching algorithms to prioritize partial matches at the beginning of apps’ names, descriptions, and keywords. This should fix issues like searching for “ala” and getting “KAlarm” as the top match instead of “Alacritty”. (Harald Sitter, KDE bug #512400 and KDE bug #512399)

Plasma 6.6.0

Added a workaround for Windows games with HDR support to make sure their colors still look good when run in WINE or Proton. (Xaver Hugl, KDE bug #509114)

Spectacle’s notifications about screenshots now include an “Open Containing Folder” button, and persist in the history if you don’t manually close them. This should make it harder to miss where your screenshots got saved to. (Noah Davis, Spectacle MR #499)

Fixed an issue in Spectacle that made the bottom toolbar in Rectangular Region mode get cut off when the selected region is close to the bottom of a screen with certain screen setups. (Mario Roß, Spectacle MR # 498)

System Settings’ Wi-Fi & Networking page now shows information about the connected Wi-Fi networks, just like the System Tray popup does. (Alexander Wilms, KDE bug #471071)

Discover now shows available updates within the app in a fancier-looking way. (Taras Oleksyn, KDE bug #509926)

Notable Bug Fixes

Plasma 6.5.5

Disabling visual customization of Plasma via the Kiosk system now hides relevant buttons on System Settings’ Quick Settings page. (Nicolas Fella, KDE bug #511381)

6.6.0

Made opacity window rules work for picture-in-picture windows. (Vlad Zahorodnii, KDE bug #513374)

Frameworks 6.22

Fixed a large number of clipboard-related issues on Wayland. (David Edmundson and David Redondo, kguiaddons MR #191)

The next release of WallpaperEngineKDE

Fixed one of the most common crashes in Plasma, caused by using the 3rd-party WallpaperEngineKDE wallpaper plugin. (catsout, wallpaper-scene-renderer Issue #13)

Other bug information of note:

• 5 very high priority Plasma bugs (same as last week). Current list of bugs
• 59 15-minute Plasma bugs (up from 55 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.5.5

Fixed an issue that prevented KWin from using direct scanout when the Battle.net launcher is open. (Xaver Hugl, KDE bug #513203)

Plasma 6.6.0

Reduced frame drop on monitors with extremely high refresh rates. (Xaver Hugl, KDE bug #513296)

Implemented the ability for portal-based applications to actively inhibit logout, for example because they have unsaved documents open. (David Edmundson, xdg-desktop-portal-kde MR #391)

How You Can Help

Donate to KDE’s 2025 fundraiser! It really makes a big difference. In total, KDE has raised over €300,000 during this fundraiser! The average donation is about €25. KDE truly is funded by you!

This money will help keep KDE strong and independent for years to come, and I’m just in awe of the generosity of the KDE community and userbase. Thank you all for helping KDE to grow and prosper!

If money is tight, you can help KDE by directly getting involved. Donating time is actually more impactful than donating money. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

The Kdenlive team is happy to announce the release of version 25.12.0, just in time for the holiday season. For this release, we concentrated on improving the user experience. Many of these changes were discussed during our very productive Berlin sprint last September, where the team met for three days of brainstorming.

Interface and Usability

Docking System

We introduced a new, more flexible docking system, allowing you to group the widgets you want together or easily show/hide them on demand. Each layout is now saved in its own file, opening the possibility for sharing. It is also now saved inside the project file, so when reopening a project the layout used when saving it is loaded and you are immediately ready to continue where you left off editing! The downside is that existing layouts are not compatible, so that you will need to recreate your custom layouts.

Welcome Screen

We introduced a Welcome Screen to improve the experience for new users, and add some handy shortcuts for everyone. With your feedback this will evolve in the future.

Along with the Welcome Screen, we introduced a vertical layout and optional safe areas to improve editing of 9:16 videos.

Menu Restructuring

Part of a long running discussion in the team, the menus were re-organized to make them more intuitive. Our long-time users may be confused initially (hopefully not for long, though), but we tried to follow some of the conventions in the professional editing world. For example, we regrouped all file related actions like Render and the Project Settings in the File menu. There might be a few adjustments in the upcoming releases, but the most important changes are in.

Thanks to users and translators feedback, we were able to fix several parts of the user interface that were not picked up properly for translation, making Kdenlive easier to use in your native language.

Monitor

We revamped the monitor view of audio, with a minimap on top allowing to intuitively zoom parts of the audio. (audio monitor)

Markers

For consistency and to avoid confusion, we renamed timeline guides to markers, since the term guide was used interchangeably and therefore confusing, and they were in fact markers for a sequence clip. Markers can now have a duration that is shown in the timeline, and can be dragged in the timeline from the Markers list.

Other Highlights

Major Bug Fixes

• We fixed more than 15 crash reports
• Windows: Fix render failure when user name contains special characters
• Fix project corruption when copy-pasting a sequence or project file between projects

Packaging

• We fixed the VAAPI support in AppImage, allowing for faster decoding and render time
• Several updates made it into our binaries, like Qt 6.10.1 and FFmpeg 8.0

Last Minute Fixes

Several fixes that will be in the next release have already been included in the 25.12.0 binaries available on kdenlive.org. If you installed Kdenlive from your Linux distro, you will get those fixes with version 25.12.1 (release scheduled for January 2026).

Give back to Kdenlive

Releases are possible thanks to donations by the community. Donate now!

Need help ?

As usual, you will find very useful tips in our documentation website. You can also get help and exchange your ideas in our Kdenlive users Matrix chat room.

Get involved

Kdenlive relies on its community, your help is always welcome. You can contribute by :

• Helping to identify and triage bugs
• Contribute to translating Kdenlive in your language
• Promote Kdenlive in your local community

For the full changelog continue reading on kdenlive.org.

This is a effectively a guest blogpost where I, as usual, take the credit for the work someone else has done.

Last year ago set out making a home automation <--> Desktop Linux bridge over the Christmas holidays.

The idea is that if you're using home automation your PC that you're in front of has a lot of important information that can be used for adjusting automations; are you in a call, are your headphones on, and so on. I made a small daemon, named Kiot (derived from "KDE Internet of Things") that exposes this information about your PC to Home Automation software, like Home Assistant.

It worked well enough for all my use-cases, so after a bit of initial buzz and a few drive-by fixes it fell to the wayside whilst I worked on other things.

In the last month it got a new contributor, Odd Østlie (TheOddPirate) who has been like a rocket ship of new features; and a bit of a community with another member being active in testing and feedback.

We now track and expose:

• bluetooth

• audio devices, volume control and selection

• battery states for laptops and wireless peripherals

• gamepad detection

• active window information

• media player/mpris connection

With more integrations in pull requests.
There's also the start of a configuration UI, so there's no messing about with configuration files.

I'll do another post once we've made a 0.1 and a flatpak, but if you're interested in KDE + home automation, go check out his work at https://github.com/davidedmundson/kiot .

Last weekend I attended this year's edition of the KDE PIM Sprint which, this time, took place in Paris.

I arrived in Paris around 1 p.m. and first walked from Gare du Nord to the Île de la Cité to have a look at the reconstructed roof of Notre Dame. Then I checked in at my hotel and after a brief rest I went to the sprint venue, the office of enioka. There I was greeted by one of our hosts for the weekend and by a few KDE PIMsters who had already taken over the meeting room.

After firing up my computer, KMail complained that it couldn't access one of my IMAP accounts. The error said "authentication failed" and a second error message claimed that access to KWallet (which stores the passwords of the IMAP accounts) was denied. Using the website of the mail provider I verified that my credentials still work. Adding the IMAP account a second time didn't help. Still the same errors. And a look at KWallet also didn't give me a clue why it should deny access to the password of one of my IMAP accounts when two other IMAP accounts worked. Since access to this IMAP account wasn't that important during the KDE PIM sprint I decided not to waste more time on this problem. This proved to be a good decision because once I was back at home the account magically worked again. I blame weird security measures by the email provider.

In the meantime more people had arrived and we went for dinner. Afterward we went back to the venue and, now that most people were there, we went over the list of topics from last year's KDE PIM Sprint. Some progress has been made since the last sprint but many topics didn't see much work done. Any and all help is welcome!

Originally I planned to look into a bug that's been haunting me for some time: KMail shows seemingly random counts of unread messages in the folder list that have little to do with the actual number of unread messages in those folders. Because I'm using the latest stable versions of almost all KDE software (as provided by openSUSE Tumbleweed) I started to build the release/25.12 branch of KMail and its 30+ KDE PIM dependencies. This took the rest of Friday evening and part of Saturday morning. Shortly before midnight we called it a day.

On Saturday morning, after a joint breakfast in the office, we discussed a few more topics from our agenda. After that I decided to scratch my original plan and, instead, to help with making the KMime library fit for becoming a KDE Framework. I created a few MRs to replace the usage of bool parameters in the API with enums. Then I looked into adapting the users of KMime to the new API. Unfortunately, this proved more painful than expected because KDE PIM does not only depend on the master branch of everything else in KDE PIM (which I was very well aware of) but a lot of the KDE PIM projects also depend on the master branch of the ktextaddons library which is a kind of intermediate library between KDE Frameworks and KDE PIM with its own release schedule. For many of the KDE PIM projects I could simply lower the required version of ktextaddons to the latest stable release (as shipped by Tumbleweed), but for pimcommon this hack didn't work anymore because it used a new header from ktextaddons master. By then it was already Sunday afternoon and anyway time for me to pack my stuff.

On my way to Gare du Nord I passed by Sacré Cœur on Montmartre where to my surprise a choir of Santa Clauses and Santa Claudettes was performing French Christmas songs.

In conclusion, I got more useful work done during this sprint than during some other sprints, although the dependency requirements of KDE PIM annoy me a lot. I've been involved in KDE PIM for 25 years now although, admittedly, I rarely contribute to it in my spare time since I started to code for a living. To a large part the reason for this is that it would cost way too much of my spare time to build all of KDE PIM all of the time.

Thanks to enioka for hosting us and to Kevin for organizing the sprint. And many thanks to those of you donating to KDE which makes these sprints possible.