This year, there was another display next hackfest, this time in Nice, France. This was a very productive hackfest, so I'll focus just on my personal highlights here.

KMS backlight property

As mentioned in the blog post about the last hackfest, the current backlight API on Linux is a total mess. To remind you, the kernel exposes backlight devices through sysfs, which has several problems:

• this API doesn't tell you which display the backlight is for. Effectively, only one backlight is supported
• some of the backlight devices don't actually work, it's up to userspace to figure out which one to use
• you need root privileges to change the backlight brightness
• there's no proper minimum. On some displays, backlight level zero turns the backlight off, on others that's the minimum brightness. In some cases, non-zero but very low levels result in wrong colors
• there's no information on how long it takes to apply brightness changes

The new KMS API adds a backlight property to connectors of built-in panels (external monitors may be supported later), so the compositor knows exactly which display it's for, and it can change the backlight without needing more permissions than it already has for driving the display.

We talked about the requirements to merge the API, concluded that it's okay to leave it at one unit-less value for now (it can be trivially extended later), wrote and tested implementations and it's pretty much ready to be merged.

KMS colorops

KMS colorops allow the compositor to offload some color operations to the scanout hardware, which can save a lot of power. We discussed how to best extend it to support YCbCr buffers, which are required for efficient video playback, and tested an implementation of the addition in amdgpu.

The implementation had some bugs with interesting visual results, but we debugged that and could find the source of the problem. The API for this should be merged sooner than later as well.

Scheduling Atomic Commits

As another follow-up to last year's hackfest, we now had an implementation for what we agreed on last year:

• a callback that gives us a timestamp for when the hardware finished programming the last commit
• information on when the deadline is, relative to the start of vblank

We also talked about how all of this should work with ultra high refresh rate monitors, since CPU schedulers are quite bad at timing things precisely. To put things into perspective: KWin currently sets the target commit time to 1ms before vblank, since schedulers sometimes wake up KWin's thread hundreds of microseconds later than planned.

With a 1000Hz display, the compositor would only have 1ms to commit each frame, so that doesn't exactly work out well. Worst case, the compositor may need to immediately commit the next frame once the last one is finished, but in an ideal world, the kernel would 'just' be able to schedule the compositor's threads more accurately.

VRR and QMS

Variable refresh rate has a few annoying problems right now:

• when the refresh rate changes too quickly, many displays change in brightness, which is visible as flickering
• HDMI doesn't require displays to make switching between VRR on and off seamless, so many TVs go blank for a second when doing this
• compositors currently don't have any (good) way to set an exact refresh rate without turning VRR off

All of these issues can be solved by allowing the compositor to set a minimum and maximum refresh rate that the display needs to stay between. We had two proposals for this:

1. allow compositors to set a minimum and maximum refresh duration in nanoseconds
2. allow compositors to set a minimum and maximum refresh rate with a numerator and denominator for both rates

For compositors, the first one is generally simpler, but the second one is needed for HDMI's QMS feature. The "Quick Media Switching" functionality makes TVs switch to exact video refresh rates, which are specified as a numerator and denominator rather than a duration.

We still need more implementations for this to move ahead, but the direction to go in seemed pretty clear.

Color formats and BPC

Currently on Linux, if you want to configure how the image is sent to your display, you're out of luck. Both the bit depth (how many bits per color are used) and the color format (RGB vs. YCbCr, chroma subsampling) can't be configured, the driver chooses both automatically.

The new color format KMS property will solve this problem for the color format side, and we discussed how to do the same for bit depth. We concluded that a "min bpc" to match the already existing "max bpc" would likely be the best way to do this, since compositors can either choose a specific bpc that way, or leave it up to the driver to pick the best possible value.

FreeSync HDR, HDR10+, HDMI SBTM

Anyone that's used HDR for some time knows that displays basically never do it right. Their tonemapping behavior can be unpredictable, and especially TVs often do a lot of "interesting" things in an attempt to improve the image, which can have very bad effects on PCs and video games.

For example, my TV by default makes images brighter than they are. If I use the brightness slider in Plasma, the TV literally compensates the reduced brightness away!

FreeSync HDR is one way to solve this problem: Instead of sending a signal to the screen that's way larger than required (BT.2020 + PQ), just give the display an image in its native colorspace (native primaries + gamma 2.2 with 1.0 being the maximum luminance), and ensure it does the absolute minimum amount of tonemapping possible.

While TVs sadly don't usually support this mode, a lot of higher end gaming monitors do, and as it turns out, supporting it on Linux wasn't actually all that difficult - I already have a kernel patchset to enable the functionality that happened to be mostly there in amdgpu already, and on the compositor side it was entirely trivial. The only part that's still missing is parsing the relevant bits from the monitor's EDID to figure out if it actually supports that mode.

Specifications for the FreeSync information in the EDID are unfortunately not public (yet?), so we'll have to reverse-engineer it. Luckily, some people have already gotten most of the way there, we just need to implement it in libdisplay-info and verify its correctness with a bunch of screens.

HDR10+ and HDMI Source-Based Tone Mapping are other standards intended to solve similar problems, and we'd really like drivers to implement them as well.

Atomic commit feedback

There was some discussion on how compositors can get feedback on why a particular atomic commit failed. There are two big cases where this is important:

• when trying to change the display configuration, especially enabling displays for the first time
• when trying to find the optimal setup for overlay planes¹

Currently, graphics drivers effectively just say "no" when something doesn't work, and both compositors and users are left to try random things until hopefully some configuration is usable.

There's an existing patchset to provide such information, which is very useful for display configuration, but less useful for overlay planes. We talked a bit about how this could possibly be improved, how the API might be extended in the future, and whether or not a userspace library that's more aware of vendor-specific hardware (and driver) limitations might be a better approach for improving overlay plane usage.

linux-dmabuf version 6

This latest version of the linux-dmabuf protocol allows the compositor to advertise that it supports multiple GPUs, and allows applications to set which GPUs they're using. I'll make a separate blog post about this, but the important bit is that it allows for performance improvements in many systems with multiple graphics cards. This is quite the extreme case, but on my setup with an external GPU, using this protocol in Mesa and KWin literally improves performance in Cyberpunk 2077 by 100%!

After some explanation of how it works and minor adjustments to the protocol text, we merged it. There's even a wayland-protocol release for it now!

Non-blocking modeset commits

The KMS API has some annoying quirks, and one of them is how you request an event for images being presented. You can request these page-flip events with a flag on each atomic commit, but if you try to present to multiple CRTCs (usually one per screen) at the same time, you get one event per CRTC.

That part by itself is fine, but what's more problematic is that the kernel has a pretty old workaround for some old and buggy compositor: It doesn't allow you to request page-flip events if any of the CRTCs in an atomic commit are actually turned off.

Because of this, for changing the display configuration, KWin currently uses a blocking commit, which can take up to 90ms in my testing (with a single screen) and blocks KWin's main thread for that time. At the hackfest, Simon put together a kernel patch for allowing compositors to request a page-flip event per CRTC instead of globally, which solves this problem very nicely.

Switching between compositors

When you switch between compositors, currently the compositor you switch to gets all the KMS state from the compositor you switched away from. This can be very convenient for smooth transitions, for example when logging in from the Plasma login manager to the Plasma Wayland session, but it can also go wrong, for example when logging in from the Plasma login manager with HDR enabled into an Xorg session that doesn't understand HDR at all.

This problem has existed since the day KMS was created, and there was never a good solution for it. Some compositors "clean up" after themselves before you switch virtual terminals, but that workaround prevents those smooth transitions and it's not a fully robust way of fixing this.

We looked into finally fixing this properly, and concluded that we want a flag in an atomic commit that makes the kernel reset everything to some sane default state before applying it. This way, we can get more reliable switching between compositors without having to compromise on smooth transitions where possible.

Driver bugs

When doing bug triage for KWin, I usually spend a significant amount of time telling our users that their problems are caused by bugs in graphics drivers and where to report them. So I'm especially happy to hear about important problems being solved:

• the likely by far biggest source of page-flip timeouts on AMD GPUs is finally getting fixed. This was especially bad on AMD laptops, where leaving PSR² enabled could trigger such a freeze multiple times each week
• a Nvidia driver bug causing freezes when using overlay planes is getting fixed
• slow atomic commits on AMD are getting improved. I wrote a KWin autotest that consistently triggers the issue at the hackfest, and Harry made a fix for the most severe cases since then. On my laptop the stutter caused by it isn't usually noticeable, but on dedicated GPUs it was pretty bad

More than just being very annoying, these specific issues are also the blockers for enabling overlay planes by default in KWin on the respective hardware. I have high hopes that we can finally enable overlay planes by default on all hardware this year!

Conclusion

I'm really glad to see so much progress on these topics. My nearly infinite wishlist for driver changes is actually shrinking for once!

Thank you to Collabora for organizing and sponsoring the event, and thanks to all the awesome people for being there and making things happen :)

24 Jun 2026 1:00pm GMT

Qt Bridges aim to bring Qt's UI framework capabilities to commonly used programming languages, like C#, in a way that is familiar to developers using these languages. After the public Beta release, we've continued working on the C# bridge, adding new features and making improvements based on the feedback that we've received. Today we are announcing the release of a new Beta version 0.3.0, including some of these recent additions.

23 Jun 2026 12:16pm GMT

Every C# UI framework comes with a familiar pattern: Windows-first, Linux absent, roadmap uncertain. WPF stalled, MAUI skipped Linux, WinUI 3 stays Windows-native. At the same time, demand for embedded Linux grows and C# teams feel the lack of good UI alternatives for C# on Linux. Qt Bridges, a bridging technology in public beta for C#, provides access to a UI framework that allows preserving your existing C# codebase while utilizing Qt Quick's feature-rich UI libraries and APIs, hardware acceleration, and cross-platform capability.

23 Jun 2026 11:00am GMT

Just something I experience more and more these days.

When it comes to reviewing code, the descriptions, commits and such can be massive blast of information: Full of extraneous details depicting what was changed. The main point is why was something changed. And often in only one huge commit with massive diffs.

I'm sorry but my poor ADHD brain can't take this very well. I don't want to read a novel. Usually blurbs of text are fine: Extraneous detail I can ask about if I need to know.

So this is my plea, from accessibility-ish(?) standpoint, to keep commit messages, merge request descriptions and code comments clear, to the point, need-to-know basis. Do not explain what, but why. Usually the code itself is enough to tell rest of the story. If not, I will ask questions. That's why it's a review.

It's easy to think that having huge description with all and everything is the way to go, but it will just make it slower for people like me to review it. I can barely concentrate already..

Then commits should always be atomic, especially during merge review. Use git amend to make small changes. Before merging, rebase and clean up, or squash. But try your best keep commits atomic: changes that can stand alone.

(Note that this is not aimed at any specific individual, I just finally had brains to write this post since I was reminded of the topic.)

If you use LLM tools, please still write comments, descriptions, commit messages etc. yourself. It helps you to understand whats going on, and it's more accessible for me to review. (Or better yet, try to avoid these tools if you can. I don't think anyone actually needs them. You're good enough without, I promise!)

edit: Seems people are upset about me mentioning accessiblity there. I do not know what is the best way to describe it. But you can just ignore this blog post if it annoys you.

23 Jun 2026 9:12am GMT

Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.7.1.

Plasma 6.7 was released in June 2026 with many feature refinements and new modules to complete the desktop experience.

This release adds a week's worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:

View full changelog

23 Jun 2026 12:00am GMT

By now, many of you have probably seen Linus Tech Tips' "Linux is Easy, right?" video?

The TL;DW version is that yes, things are mostly pretty easy, and the tasks they're having trouble are becoming become less and less common over time… but pain points remain for the "prosumer/technology enthusiast" crowd: folks who are moderately to very technical, but aren't software developers.

KDE comes out pretty well, with one exception: network shares.

Network shares.

Yes, network shares.

Still. In 2026!

What the heck is going on here? How is this not a solved problem? Let's talk about it today.

How it works in KDE's software

When you access a network share from Dolphin's built-in network share browser, it doesn't get mounted as a local path somewhere; Dolphin is connecting to the share using its own communication protocol: smb://, nfs://, or similar.

This is fine for KDE apps; they can use those communication protocols to access files when you double-click them on network shares you've accessed using Dolphin.

Everything works.

When you double-click a file on a network share and it opens in a non-KDE app, at that point something called kio-fuse (that we did a ton of work to build a few years ago) secretly creates a FUSE mount of the share in the background, and passes the app a local path to the file on the secret FUSE mount.

This way, the non-KDE app opens the file from a local path as it expects, and everything still works.

No it doesn't, you liar!

You caught me! Everything works if you open the file from Dolphin… but what if you need to access a file on the share from the "open" dialog in an app, or save a file to the share using the "save" dialog in an app?

Well, then things get more complicated.

If it's a KDE app, the standard KDE open/save dialog knows how to access the network share so you can open or save new files there. If you've created a bookmark for the share in your Places panel (which is our documented recommendation in KDE Linux), it's already right there; simply click on it to connect to the share, and navigate to the desired file or location. Easy peasy, everything works.

Sounds great! So where's the complication? Let's move on.

If it's a non-KDE app that uses the KDE open/save dialog, it's the same deal: access the share from the dialog, everything works. Example apps are VLC and LibreOffice (when run with the Qt backend). Still no complication…

If it's a non-KDE app that uses the portal-based open/save dialog, then everything is lovely here too. The app asks the XDG Desktop Portal for an open/save dialog; the portal offers up the KDE dialog; everything works. In this respect, Flatpak has been encouraging adoption of the portal-based open/save dialogs, which produces a really nice experience: KDE users get a KDE open/save dialog in almost every Flatpak app - something we've all wanted for years!

But now we come to the problem:

If it's a non-KDE app that uses its own non-KDE open/save dialog… then everything becomes terrible. Its dialog will not see any bookmarks you've added to the KDE dialog, and will expect you to have the share mounted locally somewhere. Even if kio-fuse created a mount, the non-KDE dialog doesn't show it nicely in its sidebar! You have to know the secret location of the mount (/run/user/1000/kio-fuse-[something]) and use the dialog to navigate there manually.

If these apps are packaged traditionally, that's bad enough. If they're Flatpaks, it's worse: they have to be packaged with a hole in the security sandbox that allows them to access the kio-fuse mount, or else you can't access it even if you know it exists and navigate there manually. Most do this for the location where GNOME's own system mounts shares… but not for the location where kio-fuse mounts them - nor the location of any shares you've manually mounted, for that matter.

In addition, the GTK open/save dialog's built-in network browsing feature is broken unless the app's Flatpak packaging pokes another sandbox hole for network access - many don't! And custom dialogs may not even have this feature at all.

What a mess. Unfortunately, as of June 2026 (if you're reading this later, please verify), apps in this unfortunate situation include some important ones like Blender, GIMP, LibreOffice (from Flathub or with the GTK backend), OnlyOffice, Inkscape, Audacity, DaVinci Resolve, and Gedit.

So, that's bad.

If it's a command-line tool or daemon, then everything is terrible in the same way. All previous use cases involved GUI tools accessing or mounting the network share; until and unless that happens, there's nothing for CLI tools to see. It's as if the share doesn't exist. Something would need to mount the share at login. That something usually ends up being driven by changes to /etc/fstab that a random internet tutorial walked you through.

Why not just mount stuff the old-fashioned way using /etc/fstab?

Well, there are a few problems with this - the first one being that /etc/fstab is root-owned, so using it to mount a network share requires administrator privileges. That's not gonna fly on multi-user or administrated systems.

You could work around this by using a GUI tool that can modify that file using Polkit, and then ship a Polkit rule to auto-allow this app's requests to modify the file - even for non-admin users.

If it's a password-protected share, you'll also have to store the credentials in plaintext somewhere; there's no provision for storing them in an encrypted password storage system.

This makes a mockery of security, but even if that's acceptable, it turns out there isn't just one way to mount a network share using /etc/fstab, but rather about twelve thousand ways. Every online tutorial gives you a slightly different set of steps, and if you don't do it just right, you'll end up with a mount that isn't writable, or delays the boot process if it's not accessible at that time, or causes apps to hang and freeze if it becomes inaccessible later, or other non-obvious problems that can be really "fun" to troubleshoot.

It's not impossible to do this properly, but you have to know what you're doing. So you really want this file to only be touched by a person or organization that qualifies, and to not make changes to it that you don't fully understand.

How can we fix this?

All is not lost. Happily, KDE just received an investment of over €1.2 million from the Sovereign Tech Fund, and it includes funding for improvements to KDE's network share handling!

Time for full disclosure: KDE e.V. is contracting with my company Techpaladin Software to run this part of the project. Network shares represent a significant paper cut, and I'm really excited to be a part of the process to finally get this topic sorted.

I'm not micromanaging the project; frankly, I don't have the time, even if I wanted to! So my involvement so far has mostly been to put smart people in charge, gather them together into a (virtual) room where they can be productive, and make sure they're adequately funded! Which is what I've done, and and I have every confidence in the team.

Here are some of the ideas under discussion:

1. Have Dolphin and open/save dialogs automatically create temporary bookmarks for recently-accessed network shares, maybe in the "Recent" section.
   This would eliminate the step of manually bookmarking transiently-accessed shares.
2. Have Dolphin and the open/save dialogs create a FUSE mount for each share they access immediately after accessing it, rather than the first time a file from the share is accessed in a non-KDE app.
   This would solve the problem for CLI tools - provided the share is manually accessed at least once beforehand.
3. Either expose the FUSE-mounted share at a location on the system that lets the legacy GTK open/save dialog see it by default, or submit patches to GTK to let the GTK open/save dialog to see kio-fuse-created network share mounts at their current location.
   This would extend that fix to non-Flatpak apps using the legacy GTK dialog.
4. If the user manually bookmarks a network share, have kio-fuse automatically create a mount for it on login, similar to "mapping a drive letter" on Windows.
   This would remove the caveat "…provided the share is manually accessed at least once beforehand."
5. Submit patches for apps on Flathub that still use this legacy dialog that let them see the location where kio-fuse mounts network shares.
   This would extend the above fixes to these apps' Flathub packages.
6. Submit patches to port remaining apps to use the portal-based open/save dialog.
   This would reduce the number of GUI apps that need the above fixes in the first place.
7. Standardize the location and mount arguments for these FUSE mounts so you never end up with GNOME and KDE apps FUSE-mounting the same share to different locations. That's just ridiculous!
   I'm not sure how politically possible this is, but it would be nice to reduce duplication.
8. Look into using systemd mount units as the underlying implementation if systemd is available, and use the current kio-fuse implementation as a fallback only on systems without systemd.
   This would let us use an already standardized system and the more performant kernel drivers for remote filesystems. And it might be more feasible than #7.

Lots of ideas. Preliminary work has already started, and I expect it to be an ongoing area of focus in the coming months.

So hopefully soon this topic will finally be in the rear-view mirror. I think it's clear that KDE is not yet 100% there on network shares, and we can do better. And we will!

22 Jun 2026 3:44pm GMT

Hey wassup guys! Welcome to yet another blog made by me!

I've been busy for a while due to exam stress and my passport situation.
But I am glad to share that I finally got the passport yesterday! This brings me one step closer to making it to Akademy 2026 in Graz, Austria.

Now I just need to get my flight and hotel bookings done, get some required documents signed from my university, get a VISA or a forex card and then finally apply for the Austrian Schengen VISA.

Anyways, this blog is supposed to be about sharing learnings / progress made in week 2 and 3 of my GSoC journey so let's go!

If I recall correctly, I did the following in the past 2 weeks:

Work on some CI issues in the android image and the windows MinGW image.

• I had to build harfbuzz from scratch for the android image because it simply didn't have it by default.
• For the windows image, I actually found a bug in harfbuzz which made the windows build fail. I filed an issue and they fixed it very quickly by using AI https://github.com/harfbuzz/harfbuzz/issues/6026. I don't really like it myself that harfbuzz is heavily using AI in its development but I think I can't really do much about it. Perhaps this is a topic worth covering in another blog?

Destroying resources after we have no use for them.

• I was leaking some memory by using harfbuzz to generate subset fonts but was never really calling the destroy functions required to free that memory.

Fix a dangling pointer bug that caused invalid fonts on subsetting.

• I unknowingly made a serious dangling pointer or use after free bug when I was working on destroying harfbuzz resources after I had used them. The gist here was that I used a class called MemStream but didn't realize that it actually had a read-only view on my subset font data, let's say const char* fontData. I called harfbuzz destroy function after constructing this stream and it freed the fontData and then when the time came for writing to the file, the fontData pointer inside the stream was dangling and corrupted data got written.

Making font subsetting an optional feature

• I reported the harfbuzz issue and the patch MR got merged so does that mean the windows CI would also get fixed immediately? Not quite, the harfbuzz people would first need to release a release and then it needs to be updated in the package repository to finally get the patch working. We aren't sure about just how much time this is going to take so I worked on making the font subsetting functionality optional by using CMake options magic.

What I learned

• I am now less likely to make dangling pointer mistakes but it could still happen.
• Quite a lot of CMake and how to do optional features with it.
• Dealing with CI.
• And a couple more things I forgot about but I did actually learn from them.

Conclusion

I think I did like below-okayish amount of work done but I am glad I actually learnt a lot of useful and important things.

I would like to thank my mentor Albert Astals Cid, and the Poppler community for helping me. I would also like to thank KDE board members for approving my reimbursement requests.

And finally, thank you for reading my blog so far :)

Until next time!

22 Jun 2026 2:16pm GMT

The Challenge: CMake and Qt - Powerful Together, Tricky in Practice

The gap between "CMake that compiles" and "CMake that is correct" can be sometimes significant. CMake has been Qt's official build system since Qt 6.0, and the pairing is genuinely capable: a well-configured Qt CMake project supports cross-platform builds, incremental QML compilation, seamless C++/QML integration, and deployment-ready install targets. But getting there requires mastering a build API that has evolved rapidly across Qt 6 minor releases - and that evolution is precisely where things can become challenging for Large Language Models, especially older or smaller models.

22 Jun 2026 11:41am GMT

Qt Creator 20 has become an Agent Client Protocol (ACP) Client extension. The protocol is supported by many AI providers and handles the details of the communication between the AI coding agent and the IDE.

22 Jun 2026 11:10am GMT

So, last road map discussion it was decided I would start working on HDR. This is partially because I have the hardware for it, as well as Krita now supporting the wayland color management protocol, so my hardware is actually being used appropriately.

Furthermore, before I worked on text my specialization within Krita is its color management code, so I feel a little like a fish in water right now.

HDR tends to mean three separate things:

There's the hardware side, where a screen can show such bright colors that it needs to be interacted with in a special way to make good use of those colors. This particular manner also informs how we store HDR values inside file formats.

There's the scene referred workflow, where we assume there's a scene white, usually the brightness of a diffuse white, like paper, and highlights are above that are the high dynamic range.

Finally, there's the tone mapped result of a scene referred image. That means that we take the scene referred image, and scale everything so that the result fits into a regular SDR range. This is typically the version that people learn of first when they scroll photography websites.

For Krita's purpose, we're largely interested in the first two. The hardware and file format side in particular needs a lot of work to get all the metadata right. For the scene referred section, the filters need adaptation. But the last entry is necessary to create a nice result image for social media, so I'll cover that in the future too.

For now, I focused on getting some UI fixes in.

Canvas Decorations

So, the first thing that needed tackling was the user interface. In particular, when using previous versions of Krita, the canvas decorations were blown out.

Basically, this happened because we draw our decorations onto the OpenGL canvas with a QPainter. Because QPainter nor QColor has any concept of what space it is drawing in, it doesn't know to convert from sRGB to the rec2100pq format we're using for the HDR canvas. We also have the issue that sometimes, colors aren't in sRGB, but rather should represent a color from the image. Previously, we could assume that if the display was wide gamut, we didn't need to adapt the decorations, or treat them differently from image colors, so we just treated them as the same thing, and drew the colors straight onto the display color space.

Now, the only place that knows how to handle image colors properly, applying all the OCIO config, etc, as well as having information to convert sRGB to the canvas space is the display color converter inside the canvas. This one has an extra simplified interface, called the color display renderer. Most of the work to fix this was to add functions to this renderer interface to convert colors (and images) and finally funnel the renderer through all canvas decorations. This was about 130 changes in the end.

Most of them were just plain conversions from sRGB to canvas space, but the color picker had to use the actual image color, as did the preview for the transform tool. Nor everything had to be converted on the fly. In some cases, like the vector tools, we have a set of colors we reuse, so those were added to the display renderer to be converted as a single struct of colors. Then, there's the on canvas toolbars, like for the selection tools. These just use QPalette colors, which was solved in a similar manner, with the display renderer keeping a version of the current palette, but converted to the canvas space. At some point, we might need to do the same with KColorScheme, except that this class doesn't have a way to change colors inside of it. Not sure what the best solution here is, as Krita needs to control the conversion function (in case of wide-gamut, etc).

Then, there were the reference images. Reference images are drawn on the side of the canvas in Krita. While fixing them was easy enough, I went a little further: Enabling HDR and wide gamut on the reference images. This was a little bit ambitious, as it required converting between QColorSpace and our similar class, KoColorProfile (a KoColorSpace, if you're curious, is a KoColorProfile and a bit depth, as KoColorSpace has a whole bunch of per-model+bit-depth functions to wrangle pixels).

This conversion isn't too hard, because QColorSpace can read and return iccprofiles, and KoColorProfile can do the same. However, for rec2100pq in particular, we will want to return a profile of our own. Same with sRGB. So what happens before we try to load the icc profile is that we test the transfer and the like, and funnel the values into our profile searching system. This system was created to handle ITU CICP values (basically a standardized set of enums for transfers and colorants), and was already extended with the known quantities outside of that (Adobe RGB, ProPhoto), so it can handle all the predefined transfers and colorants QColorSpace supports and find the relevant profile before trying to create it.

Now, when we load a reference image, and the image is RGB, Krita will convert it to a QImage, but set the colorspace to use that RGB space. The exception is when the image is floating point, in which case it'll be converted to rec2100pq, because our reference images are eventually stored as PNG, and PNG cannot handle floating point. Then, when we start drawing the reference images, we first ensure the QImage QPaintDevice has its QColorSpace set to use the canvas colorspace. When drawing, we test the color space of the device, and the colorspace of the reference image, and then do the conversion to the canvas space before drawing.

And it works. I'm pretty pleased with this, because we have a bunch of other places we still draw with QPainter that might be useful to color manage, with the most notable one being the vector shapes. I hope we'll be able to tackle that in the near future.

Improving the color management page

This was basically setting a little widget to show the color space data we get from wayland. Wayland sends us two types of information: The preferred color space, and the mastering display data. The former is the space wayland suggests that we send data in for the least amount of color conversions. The second is a little bit more weird. The mastering display color volume in HDR terms is a bit of metadata to indicate the gamut of the display that the image was finalized on. The idea being that this info can help guide the gamut mapping process by indicating in what range the important contrasts are.

In practice, what wayland is sending here is the color volume of the display the current window is on. I think this is so that we can send that data right back when we're sending HDR data for the image that is being authored on that display.

So, I made the XY CIE Tongue widget display these spaces with a toggle to switch between the preferred and current display gamut, and an auto update when the preferences switches screens. It might seem small, but one of the reasons I ported the CIE tongue widget over from Digikam all those years ago is because I do feel it is much more friendly to be able to see the actual gamut instead of having to interpret magic numbers and names.

Making the Histogram handle floating point

Our histogram docker was limited to [0 1], which isn't very useful when working in linear floating point, so I wanted to fix that. So, a histogram in Krita is made by taking a vector of integers, initializing that with 256 values, and then going over each color and incrementing the value that is associated with the value of the pixel. You then do this per-component, to get a view of where the pixel values are per-channel.

What needed to be added here was that we now first test all the pixels for the maximum possible component value. Then, afterwards we divide the range of 0 to maximum by 256, and use that to sort the pixel values into. This means that as the image gets a bigger range, the precision of the histogram decreases, but as far as I know its output should still be statistically relevant.

Of course, in really wide range images, the range becomes a little meaningless. Therefore, it was decided to add a toggle to switch into logarithmic mode as well. For this, to keep the precision sensible, it needs to sample a separate logarithmic vector during pixel sampling. This has the added benefit that switching between linear and logarithmic is instantaneous.

Then I spend some time tweaking the graph and adding numbers at the bottom.

One thing I'm a little worried about though: The log grid is using log10. But with HDR there's a concept of stops, which is log2. And I'm wondering if I should switch the logarithmic mode to log2 instead of log10, but at the same time, I've never seen log2 graph paper.

Vector Cursors

This has nothing to do with HDR, but I also converted all the cursors to SVG. This was something I did when there was a lull in the text work last year, because my screen is also a high dpi screen, and the cursors in X11 were tiny. So, I spend some time redrawing all the cursors, and then load them with QIcon(file.svg).toPixmap(width, height) to get a display scaled pixmap to use with QCursor. Of course, this then got delayed because there were issues with hot-spot offset and Android, and then I had to return to the text work. I managed to get back to this recently and finalize it.

I'm kinda happy, because between the vector cursors, the color managed canvas decorations and the fact canvas decorations get scaled (something I did… two, three years ago), everything we can draw on the canvas now looks good on modern displays.

Next up is going to be digging into the weeds of HDR metadata.

22 Jun 2026 6:00am GMT

We've also created a new USB-card, with the newest stable version of Krita for all OSes. Includes Comics with Krita, Muses, Secrets of Krita and Animate with Krita tutorial packs. It's a 32 GB USB card with USB A and USB C connectors and the latest Kiki splash by Tyson Tan! If you just want the empty card because Kiki is cute, you can get that for a reduced price!

The usb-card is available in two versions: empty, for €19,95 and (manually) updated to the latest version of Krita for €34,95.

22 Jun 2026 12:00am GMT

This week, the import/export feature for KeepSecret was completed and merged in !33.

The implementation went through several changes before reaching its final form. My initial approach was to use a KWalletManager-compatible XML format so that data could be exchanged directly between the two applications. To match KWalletManager's structure exactly, I referenced kwalleteditor.cpp from the KWalletManager repository and implemented support for elements.

The final format now preserves all item information:

-Secrets are stored as Base64-encoded data and decoded directly from the raw byte array, avoiding UTF-8 conversions that could corrupt binary or non-UTF-8 secrets. -The contentType field is preserved, matching the Secret Service specification's combination of raw secret bytes and content type metadata. -Every attribute key and value is exported exactly as stored, without assuming any particular schema. -Exported files use a dedicated .keepsecret extension instead of a generic XML extension.

My first version queried libsecret directly during export. While functional, this wasn't consistent with how CollectionModel already manages data. Based on feedback, the final version loads secrets and attributes into the in-memory item list (m_items) when a wallet is opened secrets and attributes into the in-memory item list (m_items) when a wallet is opened, and the export process simply reads from that existing data. This keeps the implementation cleaner and aligned with the rest of the model.

There was also a small but important UI change. Initially, the Import and Export actions were placed in the application's global drawer. During review, Marco Martin noted that these operations belong to a specific wallet rather than the application as a whole. Following that feedback, the actions were moved to the wallet page itself and integrated into the ActionCollection system, alongside actions such as Lock and Delete Wallet. As a bonus, they automatically gain keyboard shortcut support through the existing shortcut infrastructure.

The next step is a follow-up merge request that adds support for importing the legacy KWalletManager XML format. This will make migration from KWallet to KeepSecret much smoother for existing users. The merge request!34 is open and under review.

21 Jun 2026 5:12pm GMT

It's been quite a while since I last wrote an entry in this blog. It's also been some time in which my invent gitlab graph has been feeling a bit emptier and I've also been more absent from the KDE work and community in general.

Several causes have been lining up to cause this lack of time and energy (or, in modern terms, bandwidth) I've had lately to dedicate to this amazing community and projects. But one could also summarize this to a lack of motivation.

In order to improve the situation, I've had to resort to a last desperate meassure: LEARNING VI!.

I know most people reading this might want to discourage me from such a painful path, more even at my 40+ age. But I've found myself again piked by the spark of curiosity, and wanting to learn and try new thigs. Even writing this paragraphs feel a bit easier as I'm punching characters in INSERT MODE.

Of course, I've not jumped into a vim/neovim terminal editor, but the very same Kate editor I'm used and love to work with. Just activated the integrated VI-mode and started getting comfortable with it.

On this process I've also discoverd several small issues that were not fully working, not implemented, or differ from the regular VIM experience. And as a KDE developer/enthusiast what's more enticing than pull up my sleeves and try to fix those. As we usually advice newcomers: better stratch one's own itch.

And what's best, I'm enjoying the experience of simultaneously learning some new VI magic, seeing how it is implemented in Kate, and using it to potentially fix bugs or implement new functionallity. I'm aware that the VI-mode is not supposed to be a full replacement or mimick of the traditional terminal VIM experience, and it shouldn't be. But I think there is still enough room for improvement within that limit.

For now, my first junior jobs on the matter have been implementing counted undos/redos (ex. 3u to undo the last 3 actions), and save some space in the always crowded status bar. Also trying to fix how 3rd-level symbols on my keyboard (those accessed with AltGr) are processed on Windows.

But since I've discovered VI registers, I'm having the most fun fixing some usecases, adding new tests and implementing some of the missing ones. And I have also some new exciting (but more involved) ideas in mind.

Still not sure if many users and members of the community will benefit from these. Are you a happy VIM (or VI adjacent) user? Did you know Kate had this mode completely integrated with its UI at a keystroke's distance? (try Ctrl-Alt-V)? Moreover, since the VI-mode code is implemented in the KTextEditor framework, any application that uses it, such as KWrite or KDevelop (or even your own app) can use this mode too!

This is fun!

21 Jun 2026 4:31pm GMT

Hello everyone, i am uploading this blog nearly after a month. I got the wifi security QML working and one of my MR got merged in production. Here is my detailed work done during that phase

• Refactored the Security 8021x. I have detailed explanation in my MR description. MR - https://invent.kde.org/plasma/plasma-nm/-/merge_requests/566

• Similarly, I refactored the cpp code for the wifisecurity part (WPA2, WPA3 Personal networks), MR - https://invent.kde.org/plasma/plasma-nm/-/merge_requests/582

• New QML designs and QML classes (which are still in review) for Wifi Security Tab and its combo box. MR - https://invent.kde.org/plasma/plasma-nm/-/merge_requests/583

• I have refactored almost 50% of the main KCM editor (the left side pane is completed) MR - https://invent.kde.org/plasma/plasma-nm/-/merge_requests/584

What's Next?

I'm currently working on the remaining Network Connection tabs, such as General, Status, and others. There's still a lot of work ahead, but the progress so far has been encouraging.

I'll continue sharing updates as development progresses.

20 Jun 2026 4:32pm GMT

This is a weekly update from my Google Summer of Code 2026 project with KDE, improving effect widgets in Kdenlive, a free and open source video editor.

This week JB reviewed the per-channel tabs work on MR !887 and asked for four usability improvements. All four are now in the MR.

Per-channel curve colors

With four tabs (All/R/G/B) it wasn't obvious at a glance which channel you were editing. JB suggested passing a color through the XML:

<parameter type="av_curve" name="av.g" default="" color="#44CC44">
 <name>G</name>
</parameter>

The color attribute is now read in AssetParameterModel and passed down to KisCurveWidget, which uses it to draw that channel's curve line instead of the default neutral color. All/R/G/B use #CCCCCC/#FF4444/#44CC44/#4488FF.

Reset button for the active channel

A small button next to the point spinboxes resets only the currently active tab's curve back to identity, going through KisCurveWidget::reset(); the same model update path as a normal edit, so it persists correctly on save.

Input/Output value display

JB asked for the selected point's X/Y to be shown numerically, like GIMP's curve editor, for finer adjustments and reproducibility. The underlying DragValue spinboxes for this already existed in the curve widget's .ui file but had never actually rendered, for either frei0r.curves or avfilter.curves; a layout ordering bug going back years. Rather than untangle that legacy code, I added two new QDoubleSpinBox widgets directly, wired to the existing currentPoint signal that fires on point selection/drag.

Ghost overlay of edited channels

JB also suggested copying GIMP's behavior of showing all non-null curves at once, so you can see how channels relate while editing one. When a channel's curve is active for editing, the other channels are now drawn faintly, in their own colors, if they've been edited away from identity. The active channel stays fully opaque on top.

All four changes are in MR !887. 48 unit test assertions pass; also fixed a test-environment issue where avcurvetest wasn't loading the Kdenlive XML effect definitions, which had been masking proper av_curve parameter typing.

JB's m_widgets null-placeholder feedback from last week is still unresolved, waiting on his direction before touching it.

20 Jun 2026 9:57am GMT

A new Craft cache has been published about a week ago. The update has already been rolled out to KDE's CD and Windows CI with the update to Qt 6.11 beeing the most important change.

Changes (highlights)

General

We added updated our base image to build the Linux cache from AlmaLinux 8.10 to AlmaLinux 9.8. This implies a newer minimum required GLIBC.

We did inital work on MSVC 2026 support, but given that it is not supported by Qt 6.11, we did not complete it yet.

Blueprints

• OpenSSL 3.6.2
• Qt 6.11.1
• New Qt modules QtGraphs and QtQuick3D
• FFmpeg 8.1.1
• FFmpeg is build with libass and x264 on MSVC now
• tiff 4.7.1
• libffi 3.5.2

About KDE Craft

KDE Craft is an open source meta-build system and package manager. It manages dependencies and builds libraries and applications from source on Windows, macOS, Linux, FreeBSD and Android.

Learn more on https://community.kde.org/Craft or join the Matrix room #kde-craft:kde.org

20 Jun 2026 9:00am GMT