Greetings!

As we're nearing the end of SoK 2026, I am writing to share my experience and progress since my previous blog.

The second half of my SoK project has been a real learning experience for me, about how contributions to KDE and open-source communities in general work. I also learnt the importance of thorough testing, bug fixing, and polishing that is required before shipping any software.

Technical update and challenges faced

Till the halfway mark, I was able to complete a rough working version of the source mode editor. But after feedback from my mentor, I realized that a lot of work was still left to be done.

Firstly, there were a lot of repeated lines of code in my solution, as I had essentially split the existing editor into two - the rich editor and the raw editor. This meant that a lot of the functionality was common between the two editors, and I had re-used existing code for that. This was true for both the QML pages and the C++ document handlers. As I now realize, that would have been a nightmare for maintainability, as any single fix or change would have to be made in two places.

The fix for the C++ part seemed to be obvious: to use inheritance. So I decided to make the RichDocumentHandler and RawDocumentHandler inherit from a common parent, the DocumentHandler. DocumentHandler now contained all the common methods, significantly reducing repeated lines of code.

Similarly on the QML side, I made a parent component, EditPage, and made the Rich and Raw edit pages inherit from it. This caused some issues (mostly related to property sharing between components) that were eventually fixed.

A major issue I faced was caused by the fact that my MR essentially removed the existing EditPage.qml and documenthandler.cpp (although files with the same name are still present, they serve different purposes). Their contents were divided into two files - the rich and raw versions respectively. But while I was working on my feature, other contributors were still modifying the old files. Git can't handle this automatically, because the old file is in a way completely changed. This meant that I had to manually go through each commit to the old files, and move the changes accordingly to the new files. This proved to be a major headache, and caused me (and even Carl) to spend considerable time manually rebasing. So when finally the feature was merged, it was a sigh of relief, as we wouldn't need to manually maintain it anymore!

Apart from this, I also added a spell-checking capability to the editor, using Sonnet.

Demo

Learning and experience

I was grateful to see my work get published in Marknote 1.5 - and also felt a responsibility at the same time. Source mode is an asset for the app, but at the same time any bugs in my work are also a liability!

I learnt how a professional application is different from a hobby project, and how the quality and rigour of work should reflect that.

It was a really fun experience working with the KDE community and I'd like to thank my mentor Carl Schwan for always being there to help!

SoK has been a great first stepping stone to introduce me to the community, and I'm looking forward to contributing to Marknote and other apps even after the program!

The latest Qt release, Qt 6.11, is just around the corner. This short blog post series presents the new features that QML tooling brings in Qt 6.11. You can find part 1 on new qmlls features here, and part 2 on new qmllint warnings here.

In this blog post, we will start with a short recap on the context property and go through the new context property support in qmllint and QML Language Server.

Global objects are one of the core abstractions in Wayland. They are used to announce supported protocols or announce semi-transient objects, for example available outputs. The compositor can add and remove global objects on the fly. For example, an output global object can be created when a new monitor becomes available, and be removed when the corresponding monitor gets disconnected.

While there are no issues with announcing new global objects, the global removal is a racy process and if things go bad, your application will crash. Application crashes due to output removal were and still are fairly common, unfortunately.

The race

Let’s start from the start. If the compositor detects a new output, it may announce the corresponding wl_output global object. A client interested in outputs will then eventually bind it and receive the information about the output, e.g. the name, geometry, and so on:

Things get interesting when it is time to remove the wl_output global. Ideally, after telling clients that the given global has been removed, nobody should use or bind it. If a client has bound the wl_output global object, it should only perform cleanup.

However, it can happen that a wl_output global is removed shortly after it has been announced. If a client attempts to bind that wl_output at the same time, there is a big problem now. When the bind request finally arrives at the compositor side, the global won’t exist anymore and the only option left will be to post a protocol error and effectively crash the client.

Attempt #1

Unfortunately, there is not a lot that can be done about the in-flight bind requests, they have to be handled. If we could only tell the clients that a given global has been removed but not destroy it yet, that would help with the race, we would still be able to process bind requests. Once the compositor knows that nobody will bind the global anymore, only then it can destroy it for good. This is the idea behind the first attempt to fix the race.

The hardest part is figuring out when a global can be actually destroyed. The best option would be if the clients acknowledged the global removal. After the compositor receives acks from all clients, it can finally destroy the global. But here’s the problem, the wl_registry is frozen, no new requests or events can be added to it. So, as a way around, practically all compositors chose to destroy removed global objects on a timer.

That did help with the race, we saw a reduction in the number of crashes, but they didn’t go away completely… On Linux, the monotonic clock can advance while the computer sleeps. After the computer wakes up from sleep, the global destruction timer will likely time out and the global will be destroyed. This is a huge issue. There can still be clients that saw the global and want to bind it but they were not able to flush their requests on time because the computer went to sleep, etc. So we are kind of back to square one.

Attempt #2

The general idea behind the first attempt was sound, the compositor only needs to know the right time when it is okay to finally destroy the global. It’s absolutely crucial that the Wayland clients can acknowledge the global object removal. But what about the wl_registry interface being frozen? Well, it’s still true, however we’ve got a new way around — the wl_fixes interface. The wl_fixes interface was added to work around the fact that the wl_registry interface is frozen.

With the updated plan, the only slight change in the protocol is that the client needs to send an ack request to the compositor after receiving a wl_registry.global_remove event

After the compositor receives acks from all clients, it can finally safely destroy the global.

Note that according to this, a client must acknowledge all wl_registry.global_remove events even if it didn’t bind the corresponding global objects. Unfortunately, it also means that all clients must be well-behaving so the compositor can clean up the global data without accidentally getting any client disconnected. If a single client doesn’t ack global remove events, the compositor can start accumulating zombie globals.

Client changes

The client side changes should be fairly trivial. The only thing that a client must do is call the wl_fixes.ack_global_remove request when it receives a wl_registry.global_remove event, that’s it.

Here are some patches to add support for wl_fixes.ack_global_remove in various clients and toolkits:

• Qt: https://codereview.qt-project.org/c/qt/qtbase/+/721655
• GTK3: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9649
• GTK4: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9648
• SDL: https://github.com/libsdl-org/SDL/pull/15203
• Xwayland: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2140
• Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40416
• Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/7666143
• Firefox: https://phabricator.services.mozilla.com/D288357
• wayland-rs: https://github.com/Smithay/wayland-rs/pull/887

Compositor changes

libwayland-server gained a few helpers to assist with the removal of global objects. The compositor will need to implement the wl_fixes.ack_global_remove request by calling the wl_fixes_handle_ack_global_remove() function (it is provided by libwayland-server).

In order to remove a global, the compositor will need to set a “withdrawn” callback and then call the wl_global_remove() function. libwayland-server will take care of all other heavy-lifting; it will call the withdrawn callback to notify the compositor when it is safe to call the wl_global_destroy() function.

Conclusion

In hindsight, perhaps available outputs could have been announced differently, not as global objects. That being said, the wl_output did expose some flaws in the core Wayland protocol, which unfortunately, were not trivial and led to various client crashes. With the work described in this post, I hope that the Wayland session will become even more reliable and fewer applications will unexpectedly crash.

Many thanks to Julian Orth and Pekka Paalanen for suggesting ideas and code review!

Today is the simultaneous release of Krita 5.3.0 and Krita 6.0.0!

Depending which version of Qt and KDE Frameworks you build, the same source will result in one of the other. Both versions are almost functionally identical, with 6.0.0 having more Wayland functionality.

But note that since Krita 6 is still considered rather experimental, since it's our first release based on Qt 6, and there were many complicated changes between 5 and 6.

For real work, please use 5.3.0! We expect 6.0 to become the main version of Krita before the end of the year, though.

What's New

Video courtesy of David Revoy.

Krita 5.3/6.0 is the result of many years of work by the Krita developers. Some features have been rewritten from the ground up, others make their first appearance.

Enjoy the completely new text feature: on canvas editing, full opentype support, text flowing into shapes. It is now easier than ever to create vector-based panels for comic pages. Tools got extended: for instance, the fill tool now can close gaps. The liquify mode of the transform tool is much faster. There are new filters: a propagate colors filter and a reset transparent filter. Support for HDR painting has been improved. The recorder docker can now work in real time. There is improved support for file formats, like support for text objects in PSD files. And much, much, much more!

For a complete overview of everything, check out our extensive release notes!

5.3.0 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-x64-5.3.0-setup.exe

• Portable 64 bits Windows: krita-x64-5.3.0.zip

• Debug symbols. (Unpack in the Krita installation folder)

Linux

Note: starting with recent releases, the minimum supported distro versions may change.

[!WARNING] Starting with recent AppImage runtime updates, some AppImageLauncher versions may be incompatible. See AppImage runtime docs for troubleshooting.

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

MacOS

Note: minimum supported MacOS may change between releases.

• MacOS disk image: krita-5.3.0-signed.dmg

Android

Krita on Android is still beta; tablets only.

• 64 bits Intel CPU APK

• 64 bits Arm CPU APK

• 32 bits Arm CPU APK

Source code

For source archives, please download the 6.0.0 archives and build with Qt5.

md5sum

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

Key

The Linux AppImage and is signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

6.0.0 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-x64-6.0.0-setup.exe

• Portable 64 bits Windows: krita-x64-6.0.0.zip

• Debug symbols. (Unpack in the Krita installation folder)

Linux

Note: starting with recent releases, the minimum supported distro versions may change.

[!WARNING] Starting with recent AppImage runtime updates, some AppImageLauncher versions may be incompatible. See AppImage runtime docs for troubleshooting.

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

MacOS

Note: minimum supported MacOS may change between releases.

• MacOS disk image: krita-6.0.0-signed.dmg

Android

Krita 6.0.0 is not yet functional on Android, so we are not making APK's available for sideloading.

Source code

• krita-6.0.0.tar.gz

• krita-6.0.0.tar.xz

md5sum

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

Key

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

Hello again! Welcome to another bugfix release. This update is highly recommended, as it tackles a few critical issues to keep the app running smoothly.

• Resolved a crash that occurred when creating your first notebook.
• Fixed an issue that prevented notebooks from being removed.
• Corrected a glitch allowing notes to be drag-and-dropped through quick sketches.
• Note sorting is functioning as intended now.
• Restored the undo and redo buttons when a single note is open.
• Added the "Clear" button to allow removing content from the quick sketches.
• Added several minor background improvements for better overall stability.

Get Marknote

We encourage everyone to update as soon as possible. You can grab the latest version via Flatpak, or your favorite package manager.

Packager Section

You can find the package on download.kde.org and it has been signed with Carl Schwan's GPG key.

Since my initial post was a bit scatterbrained and ill-explained, I thought before getting into any progress details I’d first re-introduce this project with a proper explainer, cover the work done, answer some technical questions, and touch on where it’s going.

What is Strand

Strand is “Progressive Web Application” (or PWA) runtime. Its primary purpose is to run web-based applications with better system integration than the browser, using only configuration – no programming. I understand my previous post used muddled language, so I’ll be using the “Runtime” term moving forward.

Strand is built using Qt/KDE tech. It uses QtWebEngine for the browser-driven work. It is using plain Qt Widgets for the interface. Initially the plan was one-main-process-per-app, but that’s changing. More on that in a bit.

The first version used AI to develop a proof-of-concept. Initially I thought I’d simply fix-up the AI codebase, but the deeper I dug the more disappointed I was. I still consider it nice-to-have, and I might occasionally pull the odd fragment from it, but the overall structure was, ultimately, unsalvageable.

Work Done & The Work-Week Refactor

Hacking on this in the evenings, I initially began by moving common functions into utility classes, general refactoring, inspecting the code more thoroughly for flaws, establishing tractable logic flows, deduplicating code, I added a couple features, etc.

It isn’t my preferred way to work, and honestly, it felt like some old jobs I used to have where most of my effort was cleaning up other people’s messes. I don’t know too many people who like working that way. Generally the way I *like* to work is by writing the code I want to write with my ideal imaginary classes, then I go and implement those classes. This was the opposite; I was grinding against classes filled with whatever was most convenient for the AI to write, and more than a few times I would find the same functionality written different ways in different places because the AI had no planning foresight.

So instead of fighting the bad code I eventually just opened a fresh project. I copied a few of the cleaned-up files, I pulled in what was working, and now I’m developing more traditionally – only I have some code reference I can pull from. I’m not saying I don’t use AI – it’s still decent at filling out the odd small method or autocompleting lines – but it was worse than anticipated at larger efforts.

How is Memory

In my initial post I mentioned Electron a few times as a heavy maintenance burden, and found a few comments wondering about memory usage. The truth is, while Electron apps are heavy, most of that weight comes simply from running the Chromium engine. My larger concern was mainly the effort involved in maintenance. While the human-written version will be different, I did some memory tests just to see where in the ballpark this might land.

My basic setup was installing a few app wrappers: YouTube Music, Flathub, and Prospect Mail (Outlook). Hilariously, one was a Snap, one was a Flatpak, and one was an AppImage. I installed all apps on Chrome (except Flathub, which has no PWA – it ran as a tab). Finally, a FlatHub profile was added to Strand.

The bullet-point info:

• Running one App: Electron and Strand beat Chrome with near-identical memory usage. Chrome overhead for one app (even if only a single PWA window) can easily add 200MiB of RAM.
• Running Multiple Apps: Chrome pulls ahead the more apps you run because it recycles the engine. The current version of Strand, as well as Electron, duplicate the engine each app. 2 apps in either Strand or Electron use more memory than Chrome. 3+ just increases the lead for Chrome.

In the revised version of Strand I’ll be using Chrome-style profiles instead of one-process-per-app. This *should* put running Strand at less memory than full-fat Chrome while offering the cumulative savings. That running PWAs in a browser you’re already using will always be most memory-efficient.

Why did I make the process structure blunder? Well, I’ll be real, the AI gaslit me. There was a bug in the early code causing profiles to share data, but the AI confidently told me I required –user-data-dir as an environment flag. It didn’t. Despite the grating discovery I’m keeping the process-level separation code. The plan now is to split the process if an app is toggling engine-level features like hardware acceleration. I’ll have a little map of the engine parameters, I’ll turn them into a little “process hash-key”, and it’ll share the engine with matching profiles.

Checking Out Youtube Music Desktop & Where it’s Going

In testing the Electron variants I found “Youtube Music Desktop”, which is probably the nicest Electron wrapper app I’ve seen. It provides a client-side decoration, very nice settings menu, and customization options which a configuration-only system like Strand simply can’t provide.

I thought about it, and questioned if Strand application profiles should include Javascript/CSS integrations as a feature so profiles can have extra enhancements… But I really didn’t like the malicious potential – especially since distribution is still a wild-card. I wondered “Could I trust a banking PWA in this system, with access knowing it’s my bank, without either verification or inspecting someones code?”

There’s also the question, “What happens if an app updates, and the custom code breaks? Will it fail to open? Will it subtly break? How long might a user have to wait before an author hears their app isn’t working?”

Ultimately I decided that I’ll integrate some ideas it offers (E.g. “Launch on Startup” as an option) but keep the overall system configuration-based. If you want to run your bank on the Strand Runtime, or a corporate-approved app, it needs to be secure and functional first. And, well, Strand was always meant to be a middle-ground; if it can’t do everything a bespoke app can do – that’s fine.

Hopefully this re-introduction was a bit clearer, and explained some of the technicalities. I’ll be posting more as the human-led version reaches parity, but this is an evening-and-weekend project so I won’t promise annoying updates until it gets interesting again.

Animations… Everybody loves animations. They make your desktop look more eye candy, and they also help with guiding or drawing the user’s attention towards certain elements on the screen, for example a new window or a popup or a button, etc.

An animation is a just quick series of images to simulate the movement of an object on the screen. For example, consider a basic animation that only lists digits

As you can see, it’s just a sequence of individual digit images that are presented quick enough.

The animation frames have to presented at a steady pace to maintain the smooth feeling. If one or two frames are late, a frame drop can occur, which the user will likely notice. There are various reasons why a frame may not be presented on time. One reason might be that the app has been busy doing something else, for example loading a big file from the disk. However, there can also be reasons that are not exactly under the direct influence of the app, for example the operating system scheduler may prioritize scheduling other tasks or perhaps the memory scheduler has decided that it needs to do some of its things, etc. An animation with a frame drop may look as follows

If a frame cannot be painted on time, we are in a sticky situation no matter how you look at it. The animation won’t look as smooth as it could.

That being said, it is also worth mentioning how some apps (and compositors) drive animations. A lot of them advance animations simply by the amount of time that has passed since the last frame. In pseudo-code, it looks as follows:

const milliseconds target = next_presentation_timestamp();
const milliseconds delta = target - previous_repaint_time;
previous_repaint_time = target;

advance_animations_by(delta); 

The biggest drawback of this approach is that it can introduce discontinuities to the motion of an object. For example

If the app becomes busy for about 48 milliseconds after painting the frame 3, the delta interval will be 48 the next time a frame will be painted, which will effectively advance the animation to frame 7. Technically, this is not the wrong behavior. It does make sense if you look purely at the math. From the human eyes point of view though, the fact that there is a discontinuity in the animation now is far from ideal.

Luckily, there is a simple workaround. If we know the refresh rate of the monitor, we could estimate the maximum allowed delta interval for a single frame (for example, for a 60Hz monitor, it will be 16.6ms) and limit the animation delta time by it. It won’t make animations butter smooth but it will reduce discontinuous jumps in the animation.

In comparison to the aforementioned described method to advance animations, with the proposed method, animations will advance as follows

As you can see, even though there was a frame jitter, the frames 4, 5, and 6 have not been dropped. Obviously, this is not a silver bullet solution. The final motion may still look “wonky” depending on the duration of the frame jitter but even with that being said, the advantages are still worth it. In pseudo-code, it will look as follows

const milliseconds target = next_presentation_timestamp();
const milliseconds max_delta = 1000 / output->refresh_rate;
const milliseconds delta = min(max_delta, target - previous_repaint_time);
previous_repaint_time = target;

advance_animations_by(delta);

Plasma 6.7

The animation delta interval throttling will be implemented in the next release of Plasma. Note that this will only affect compositor-side animations, for example the ones that are played when a window is opened or closed. It will not affect animations that are played inside applications, the compositor has little actual influence on those.

In my testing, both on my desktop and a less powerful laptop, I noticed slight improvements when opening new windows, animations feel a little bit more smoother especially on the laptop. That being said, please don’t take it as me saying that animations will be perfectly smooth. No, if a frame jitter occurs, we’re in a pretty ugly situation and these changes are mostly about hardening kwin so the animations look less choppy.

During FOSDEM this year, I met a group of very cool people that put together events about Open Source Design. They invited me to participate this year.

The topic was similar to my talk during FOSDEM, but with a twist on the soft skills needed to complete the creation of a new design system for Plasma.

The conference is only one day. Something really cool they did was to have something like BoF (Birds of a Feather) sessions during the afternoon slot before my talk. We had the opportunity to discuss important aspects proposed by the attendees around design and making your way into the field.

Since I was representing KDE in this project, I brought my newly-acquired tshirt from FOSDEM!

The experience was great. Everyone was awesome and even met up with new contributors to the VDG. Comments from after my talk were very positive and I look forward to participating in even more events of this nature.

Design System Update

At this time, the design system keeps evolving. I have gone back to rework some application icons. After reviewing the current designs and consulting with team members, the consensus is that they should be simpler, more approachable. I have made some concepts that I will keep exploring going forward.

Additional to that, new tokens have been created. We now have shadow tokens, and I have applied them to all the components that I can think of. They have replaced manually-created shadows from the previous time.

Radius and spacing tokens now need to also make their way into the components. Unfortunately, Penpot is struggling today on creating new tokens. I will wait for an update. However, the work involves going through out component buttons and applying foundational spacing tokens to the sides and inner spaces for the components.

While this might be long, it is easy. The spacing numbers are already in the component. My part is to create all the spacing components, locate the margin or padding number I see today in buttons, find the base component, and apply the spacing tokens.

I am also closely following up on Penpot’s new beta, hopefully coming out soon, with their new rendering engine.

I have also connected the Penpot team with our LAS (Linux App Summit) event and hopefully they can attend.

More to come!

If you’re interested in participating in this effort and have some awesome design and integration skills, join us!

https://matrix.to/#/#visualdesigngroup:kde.org

Welcome to a new issue of This Week in Plasma!

This week several new features landed, in addition to a number of user interface improvements and some nice performance improvements and bug fixes. Check ‘em out:

Notable new features

Plasma 6.7

For each additional time zone you add to the Digital Clock widget, it now also shows how far forward or behind that time zone is compared to yours. (Nate Graham, plasma-workspace MR #6417)

After

Before

If you disable the feature to invoke KRunner by typing on the desktop, instead typing on the desktop invokes “type-ahead”, which allows selecting files by typing the first letter or two of their names. (Guillermo Steren, KDE Bugzilla #427961)

You can now reverse the ordering of items in the System Tray widget. (Nathaniel Krebs, KDE Bugzilla #517016)

Notable UI improvements

Plasma 6.7

Discover now sorts app lists by number of reviews by default, resulting in vastly more relevant results while browsing rather than searching. The old rating-based sorting method is still available, of course. (Nate Graham, discover MR #1274)

After

Before

Discover now filters out non-apps from its home page, preventing death spirals of negativity where people would leave 1-star reviews saying they were broken (not being launchable apps, the “Launch” button wouldn’t work), causing them to move up higher in the list. (Nate Graham, discover MR #1287)

System Settings and KWin now consistently use the word “pointer” to refer to the mouse/touchpad pointer. (Philipp Kiemle, plasma-workspace MR #6425 and kwin MR #8982)

Screen un-dimming is now faster than dimming, since un-dimming would mean you’re ready to use the system again. (Kai Uwe Broulik, kwin MR #8963)

The currently-active task in a grouped task tooltip now has bold text, to help you pick it out. (Christoph Wolk, KDE Bugzilla #516278)

Labels for Bluetooth devices in the System Tray widget have been re-arranged so that you can always see the battery level no matter how long the device name is. (Kai Uwe Broulik, KDE Bugzilla #515090)

The Global Menu widget’s menu highlights are now rounded consistently with the highlights for other menus. (Akseli Lahtinen, libplasma MR #1459)

You can now set a modifier key all on its own to focus a Plasma panel. (Christoph Wolk, plasma-desktop MR #3547)

Plasma’s panel configuration window now only offers opacity settings if the active Plasma style supports it. (Filip Fila, KDE Bugzilla #516042)

Notable bug fixes

Plasma 6.5.6

Fixed a bug that distorted the image on certain vertically-oriented monitors while displaying the Plasma Login Manager. (Anton Gobulev, KDE Bugzilla #517409)

Plasma 6.6.3

Fixed a case where KWin could crash after changing the Zoom effect’s settings in certain specific ways. (Ritchie Frodomar, KDE Bugzilla #517073)

Fixed two cases where KWin could crash when misconfigured or given broken content. (Nicolas Fella, KDE Bugzilla #517137 and KDE Bugzilla #517711)

Fixed a few cases where KDE’s printing management system could crash due to faulty information from printers about their ink levels. (Mike Noe, print-manager MR #311)

The tooltip for the Refresh button in Discover’s Updates section no longer says “F5 (QQuickShortcut(gobbledygook))”, fixing an unexpected side-effect of a recent KDE Frameworks update. (Akseli Lahtinen, KDE Bugzilla #516392)

Plasma 6.6.4

Fixed an issue that made the “bounce keys” accessibility feature break key repeat in the Brave browser. (Ritchie Frodomar, KDE Bugzilla #513268)

In the shortcut conflict dialog opened by System Settings’ Shortcuts page, the “Re-assign” action now works. (Dávid Bácskay-Nagy, KDE Bugzilla #471370)

Made the update count in Discover’s notifications more accurate. (Akseli Lahtinen, discover MR #1284)

Frameworks 6.25

Reverted an innocent-looking change that broke icons for some apps like OBS and Ungoogled Chromium due to an underlying deficiency in the Qt toolkit’s SVG renderer. (Nate Graham, KDE Bugzilla #516007)

Notable in performance & technical

Plasma 6.6.4

Reduced CPU and GPU load for full-screen windows (also known as “direct scan-out”) on screens without the pointer on them. (Xaver Hugl, KDE Bugzilla #516808)

Plasma 6.7

Added support for “3D LUTs” in KWin, which reduces resource usage on GPUs that support color pipelines in hardware. (Xaver Hugl, kwin MR #8475)

The Networks widget now only fetches network speed information while that information is visible. (Ser Freedman, plasma-nm MR #544)

Stopped creating unnecessary OpenGL contexts for apps that don’t use OpenGL, which reduces their memory usage by 10-15 MB or more per app and also speeds up launch times. (Vlad Zahorodnii, plasma-integration MR #209)

Qt 6.10.3

Fixed an issue that broke HDR support while using the Vulkan renderer on certain hardware. (Joshua Goins, Qt patch #711621)

How you can help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!

Beyond that, you can help KDE by directly getting involved in any other projects. 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.

You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.

To get a new Plasma feature or a bug fix mentioned here

Push a commit to the relevant merge request on invent.kde.org.