This week, I completed the port of KeepSecret's actions to the new org.kde.kirigami.actioncollection API from kirigami-app-components, a recently introduced library developed by Marco Martin (notmart).

Before working on this task, actions were defined separately throughout the UI. With ActionCollection, I could define each action once in a central place and then reuse it wherever it was needed. This makes the code easier to maintain and also integrates KeepSecret with KDE's standard shortcut system, allowing users to configure shortcuts through the usual KDE interface.

The main change was creating a dedicated Actions.qml file with AC.ActionCollectionManager as the root element. Inside it, actions are now centrally defined across three collections - one for the wallet list, one for wallet contents, and one for item details. These include actions such as New Wallet, New Entry, Search, Lock, Unlock, Copy Password, Save, Revert, and Delete.

During review, additional actions were added, dependencies were simplified, and Flatpak build issues were addressed. Since kirigami-app-components is still very new, some CI and packaging adjustments were needed before everything built correctly.

The merge request !29 has now been reviewed, approved, and merged into KeepSecret.

Next up is the Import/Export feature - I'll be studying KeepSecret's wallet data structures and designing the file format this week.

04 Jun 2026 7:54pm GMT

Hello Reader!

In case you don't know me (quite likely 😆), I am Ojas Maheshwari (@the_epicman:matrix.org) and I am currently working in the Google Summer of Code program for the KDE community on a project about Font Subsetting in Poppler under my mentor Albert Astals Cid.

Community Bonding

If I am being honest, I had already bonded with the Poppler community before GSoC started 😅

I had a lot of conversations with Albert, Sune, lbaudin and ats, and they already helped me a lot with my technical problems with my contributions prior to GSoC :D

However, I also managed to bond with other fellow GSoC contributors this summer so it's a win in my book :D

Week 1

I learnt a lot about how PDF files work this week.

Technical terms like Indirect Objects, Default Appearance, Appearance Streams which used to sound confusing to me before finally clicked.

I got more comfortable with traversing and using PDF data structures such as Objects, Arrays, Dicts, Streams etc.

The Happy News is that I got the Font Subsetting to work for FreeText Annotations.

I have raised a Draft MR which should be ready-to-review by end of this week and my plan is to get it fully correct and merged first and then move on to doing the same thing for forms.

Code screenshot to make the blog look cooler

How it works

If you are interested to know what my current approach is:

• The whole subsetting runs only when the user saves the document.

• We go over all resources (for now, just FreeText annotations) that were modified, and call a subsetFonts method on them.

• This is a method implemented by every class that needs subsetting, and inside this method we pass the data on what "font" renders what part of the "text" to our FontSubsetter::getSubsetFonts.

std::map<Ref, Ref> FontSubsetter::getSubsetFonts(const std::map<std::shared_ptr<const GfxFont>, std::string> &fontMappings) const

• The function generates the subset font objects and adds them to the PDF and returns mappings of old font refs and newer font refs. The subsetting happens using a library called "Harfbuzz".

• Then the subsetFonts function simply replaces the older refs with the newer ones inside the font subdictionary of the appearance stream of the annotation.

Thanks for reading

Although this blog might look small, it took me more than 1.5 hours to write this because I kept writing and deleting things. I am hoping I get better at writing blogs in the future.

But anyways, thanks for reading!
And have a great day !
Byee 😃!

04 Jun 2026 5:39pm GMT

Luis Cañas Díaz and I shared lessons from our BI journey at the Eclipse Foundation SDV webinar - from open source to automotive. Methodology, real use cases, and hard-won lessons on data, metrics, and insights.

04 Jun 2026 5:15pm GMT

How long does it take for an Item to become visible?

Frames skipped counter in application

#include <QQuickItem>
#include <QQuickWindow>
class TimedItem : public QQuickItem
{
Q_OBJECT
QML_ELEMENT
Q_PROPERTY(qint64 timeToDisplay READ timeToDisplay NOTIFY timeToDisplayChanged FINAL)
public:
TimedItem(QQuickItem* parent = nullptr) : QQuickItem(parent),
  m_elapsedTimer(new QElapsedTimer())
{
setVisible(false);
// When made visible, measure time to display
QObject::connect(this, &QQuickItem::visibleChanged, this, &TimedItem::startMeasuringTimeToDisplay, Qt::DirectConnection);
};
qint64 timeToDisplay() {
return m_timeToDisplay;
};
signals:
void timeToDisplayChanged();
private:
void startMeasuringTimeToDisplay()
{
if (isVisible())
{
// Reset
m_frameReady = false;
// Attempt to take measurement after frame swaps
QObject::connect(window(), &QQuickWindow::afterFrameEnd, this, &TimedItem::measure,
static_cast<Qt::ConnectionType>(Qt::DirectConnection | Qt::UniqueConnection));
// Force polish, ensuring elapsed measurement is taken on the right frame
ensurePolished();
// Take initial measurement
m_elapsedTimer->start();
}
}
void updatePolish()
{
// The frame for this component will be rendered after this
m_frameReady = true;
}
void measure()
{
// This will be called for every frame until the right frame has been rendered
if (m_frameReady)
{
// Measure elapsed time
m_timeToDisplay = m_elapsedTimer->elapsed();
// Prevent measuring further frame
QObject::disconnect(window(), &QQuickWindow::afterFrameEnd, this, &TimedItem::measure);
// Propagate measured time
emit timeToDisplayChanged();
}
}
private:
qint64 m_timeToDisplay = 0;
QElapsedTimer *m_elapsedTimer;
bool m_frameReady = false;
};

The post How long does it take for an Item to become visible? appeared first on KDAB.

04 Jun 2026 2:18pm GMT

We are happy to announce the release of Qt Creator 20 RC!

04 Jun 2026 9:41am GMT

Over 180 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

• akregator: Fix a hang on launch on arm64 (Commit)
• ksanecore: Fix crash on skanlite startup (Commit, fixes bug #517465)
• koko: Fix move to trash action overriding image editor delete actions (Commit, fixes bug #519784)

Distro and app store packagers should update their application packages.

• 26.04 release notes for information on tarballs and known issues.
• Package download wiki page
• 26.04.2 source info page
• 26.04.2 full changelog

04 Jun 2026 12:00am GMT

When we first announced the transition to Plasma Wayland, one of Martin's slides from stated, "It's done when it's done!"

That talk was 15 years ago!

Nothing in software is never truly "done", but as announced previously we are finally at a point where we're ready to retire the X11 and put all our focus on the future.

As of today, the Plasma X11 session you can log into has been officially removed, and we will start a mass cleanup of X11-specific code soon.

When does it take effect?

This change will be included in Plasma 6.8, which will be released in around five months.

What's Changed?

In Plasma 6.8, there will be no X11 session in the login screen. There will only be a Wayland session available to log into.

In 6.8, all X11-specific code paths in Plasma for Plasma Shell, System Settings, and device configuration will be gone.

What's stayed the same?

XWayland support remains present. You can keep using your X11 applications, and our XWayland application support is second-to-none.

If you use KDE applications on another desktop environment, this change will have no effect. KDE applications will continue to work in X11 for the foreseeable future.

Plasma Login Manager will continue to be able to log you into X11 sessions of other desktop environments.

What's Next?

The possibilities this opens up are very exciting. Until now, on the desktop side, we've had to target the lowest common denominator or be stuck trying to maintain two conflicting code paths. It was absolutely the right choice to do a gradual transition and approach things this way, but that approach has its limits.

Moving forward with a single code path going through Wayland is going to allow us to bring new performance improvements, memory optimisations, and brand new exciting features throughout Plasma.

How Ready Are We?

Our internal metrics within KDE show that over 95% of users of Plasma 6.6 are on Wayland, with a gradual increase every release. The metrics also show that basically no one is testing or developing Plasma on X11 anymore. The platform was already, for all intents and purposes, abandoned by KDE contributors.

We have every reason to trust this metric data, as it is exactly in-line with what Sentry (our automatic crash reporting tool) reports for newly-encountered crashes shows.

For transparency, the one caveat in all of the above is that I've deliberately always focused on people using the latest Plasma release. We do still have a sizable chunk of users on X11 still using Plasma 5.27. Including them, the total Wayland adoption rate is about 76%. But back then, Wayland wasn't the default session type, so it's hardly a surprise those users are still on X11. Things have come a massively long way in the three years since Plasma 5.27 was released.

Anyone still using Plasma 5.27 - or any release older than Plasma 6.8 - won't be affected by what we do in Plasma 6.8, and nothing will be applied retroactively.

Still Have Issues with Wayland on 6.7?

Whilst we have had full confidence since Plasma 6.0 that our Wayland session provides the better overall experience, we are aware that things don't behave exactly the same. Not everything works the same especially in specialised areas.

We are not expecting a completely seamless transition for everyone. Custom scripts, tools used and even workflows might have to change. But we are aiming to offer a transition where there is still a way to accomplish all your day-to-day tasks.

Plasma 6.7 is the last release that will include an X11 session, and it's coming out in just a few days. If you still have issues that force you back to X11 we would love to hear from you.

We can't promise to get everything fixed in time for 6.8, but we can promise to listen and be aware. People's remaining pain point are and will be on our radar, so please take this time to communicate them.

02 Jun 2026 12:38pm GMT

Hot on the heels of Krita 5.3.2, we're releasing Krita 5.3.2.1. 5.3.2 had a bug with the layer docker that was very pervasive, and could cause anything from unsynced layers to crashes to groups not behaving as they should. 5.3.2.1 fixes this. Furthermore, we also had some issues where the Windows packages weren't signed. This too should now be fixed.

[!WARNING] We consider Krita 5.3.2.1 suitable for productive work; 6.0.2.1 is, because of the many changes from Qt5 to Qt6 more experimental.

Download 5.3.2.1

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.2.1-setup.exe

• Portable 64 bits Windows: krita-x64-5.3.2.1.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.2.1-x86_64.AppImage

MacOS

Note: minimum supported MacOS may change between releases.

• MacOS disk image: krita-5.3.2.1-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

Sources are the same as 6.0.2.1

md5sum

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

Key

See the 6.0.2.1 key section.

Download 6.0.2.1

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.2.1-setup.exe

• Portable 64 bits Windows: krita-x64-6.0.2.1.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.2.1-x86_64.AppImage

MacOS

Note: minimum supported MacOS may change between releases.

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

Android

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

Source code

• krita-6.0.2.1.tar.gz

• krita-6.0.2.1.tar.xz

md5sum

For all downloads, visit https://download.kde.org/stable/krita/6.0.2.1/ 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).

02 Jun 2026 12:00am GMT

KStars v3.8.3 is released on 2026.06.01 for Windows, Linux, and MacOS.

For Linux users, it's highly recommended to use the official KStars Flatpak hosted at Flathub.

This release brings major improvements to the Mount Modeler with artificial horizon filtering and uniform point distribution, significant connection speed optimizations, better guide streaming integration, and enhanced rotator handling. We've also fixed several scheduler and stability issues reported by the community. Here are the highlights:

Alignment & Mount Modeler

• Christian Kemper added Artificial Horizon filtering to the Mount Modeler wizard, allowing generated alignment points below the active horizon to be automatically filtered out. Candidate coordinate points (both generated AltAz coordinates and snapped catalog objects) are now checked and rejected if they fall into active artificial horizon regions.
• New Uniform Distribution mode generates points spread evenly across the visible sky using a Halton sequence, sampling in AltAz space to guarantee every point is above the configured minimum altitude. Points whose declination exceeds +/-80 degrees after conversion are rejected. The Any Stars, Named Stars, and Any Object modes now adopt this distribution internally and snap each generated position to the nearest qualifying object.
• Auto-sorted wizard output: points added by the wizard are automatically sorted in nearest-neighbour slew order, minimizing total slew distance. Users no longer need to click Sort after running the wizard. Clicking Sort during a run reorders only the remaining unvisited points, leaving completed rows undisturbed.
• The wizard now automatically configures the solver for each alignment point. Blind solves are used by default because no pointing model exists yet at the start of a run, so the mount's reported position may be significantly off. The GOTO mode is forced to Sync so the mount is updated after each successful solve. The original settings are saved and restored when the run finishes, is aborted, or is reset.
• Refactored point generation logic to eliminate duplicated generation and conversion math in the test suite, improving generator efficiency using a stateful sequence
• Toni Schriber fixed activation of the rotator button in the align module
• Fixed effective focal length calculation to use radians in the DSLR branch

Guide

• Thanks to Andreas Ruthner, guide streaming now correctly handles video stream window interaction. The video window no longer pops up when guide streaming starts, displays frames correctly when opened from the Capture module after a guide session, and now renders 16-bit mono stream frames (previously only 8-bit mono and RGB were handled).
• Andreas also fixed frame, binning, gain and exposure sync for streaming mode. When starting guide streaming, the module now applies the same frame settings that captureOneFrame() applies for single-frame captures. Previously, streaming mode skipped this setup entirely, causing stale values from other modules to remain active in the driver.
• Frame ROI and binning now sync on stream start, live gain updates apply immediately when the user changes the spinner during active streaming, and binning/exposure changes automatically stop and restart the stream
• Added 0.001-0.01s exposure values to the guide exposure spinner for fast streaming and daytime testing

Rotator

• Fixed several issues with Reversed rotator state not taken into account in various rotator operations
• Rotation now aborts if the Position Angle error keeps increasing due perhaps to reversed rotator behavior

Ekos Profiles & Connection

• Significantly cut down time to connect to INDI web manager by skipping DNS resolution if we already have an IP address specified for the remote host
• Fixed rare crash due to dangling clientManager pointer with test to verify the fix

Capture & Livestacking

• Use OpenCV debayering by default. Enforce even ROI selection to ensure bayer boundaries are respected.
• Always sync from INDI to overwrite shadow states in the Camera process
• Account for STREAM_FULL_DEPTH when streaming
• John Evans added support for Live Stacker Alt/AZ data via Seestar S30 Pro. It should support other telescopes in Alt/AZ mode.
• John added a gradient removal option to post processing in Live Stacker.

FITS Viewer & File Handling

• Use standard gzip compress instead of Qt own compression algorithm
• Support loading .fits.gz and .xisf.gz in the viewer

Scheduler & Observatory Automation

• Fixed scheduler freezes when loading ESL referencing many ESQ files (patch by Tomas). BUGS:519294
• Autopark should work over multiple nights now
• If observatory is not started, skip shutdown procedure
• Fixed issue where post-shutdown script run in infinite loop
• Fixed scheduler and capture scripts not running inside flatpak

Optical Trains & DBus API

• Added DBus call to set and get Pictures directory
• Fixed warning of missing devices when we already selected alternative devices in the optical train

Build & Infrastructure

• Use KSUtil to consolidate all calls to external executable so they can run correctly within a flatpak as well
• Within flatpak, run the external scripts on the host system since it may require libraries that are only available on the host system
• Christian Kemper fixed macOS iconutil failure by adding 256px and 512px icon sizes rendered from the existing SVG source, which are required by iconutil on macOS 15 (Sequoia)
• Wolfgang Reissenberger updated the Dockerfile to be based on installation scripts for all steps: INDI, StellarSolver, PHD2, GSC, openCV. All scripts are built uniformly such that existing packages or installations are preferred. If the package is missing, first installing the appropriate package is tried. If this fails, the package is built from sources

Stability & Bug Fixes

• Fixed crash reported in crash-reports.kde.org regarding invalid base device or message text. The check for message text now occurs earlier in the process to protect against this crash.
• Milhan Kim fixed test deadlock by replacing QTest::mouseClick with animateClick(), which posts the click through the event loop and prevents tests from hanging indefinitely on QDialog::exec() loops
• Fixed an issue where frequent temperature updates can cause the dark cover check to run indefinitely
• Hy Murveit fixed green lines display issue
• Fixed solution assignment
• Fixed crash and distorted artifacts in video streaming
• Replaced all abs and fabs with std::abs for consistency
• Modernized signals and slots

Many thanks to Christian Kemper, Andreas Ruthner, Toni Schriber, Hy Murveit, John Evans, Milhan Kim, Wolfgang Reissenberger, Tomas, and all others who contributed fixes and improvements to this release! Your work makes KStars better for everyone.

Download KStars v3.8.3 today and enjoy improved mount modeling, faster connections, and more reliable guiding!

01 Jun 2026 10:36am GMT

Throughout this new process at KDE, I believe I have failed to clearly state what Ocean is and what it means for the future for Plasma user interface and experience.

In this post, I will try to shed some light into this and hopefully it's easier for new people interested in this project.

Why the Confusion?

I think a lot of the confusion primarily comes from my part in showing graphics first and interface later.

Graphics tend to attract a lot of attention. So much that it swallows other narratives about what Ocean is. It's natural for our users to want to know more and accept that the graphics are the whole story.

Spoiler… it's not just graphics

How Should We Think of Ocean?

Ocean is many things, let me list them out:

• Ocean Design System
• Ocean Widget Style
• Ocean Font
• Ocean Icons(Icon Pack)
• Ocean Plasma Style
• Ocean Color Scheme
  

I think this is another reason why there is confusion out there. I have given a few talks on this as well, but I also see how it's confusing.

In simple terms, Ocean is a new graphic design platform for the Plasma Desktop.

This new platform aims, first, to organize the way graphic design for Plasma is achieved. As you may know, designers like me, tend to be pretty creative and unbound. We give free range to creativity and we like to break norms.

This is a problem, because if we want to make graphics for a computer system, such as Plasma, we need to organize our creativity in way that developers can understand.

For this reason, in recent years, a modern way to organize creativity for computers was invented by applications like Sketch, Figma, and Adobe XD.

In these applications SVG is the graphic of choice. SVG is a set of coordinates that tell the system how to draw shapes on the screen. It's versatile enough that SVG code can be read and tweaked by designers and developers alike. It can be stretched without losing quality, yadah, yadah, yadah… You know the rest.

This new wave of applications work with SVG as collections or repeatable graphics interconnected with each other. They use systems of "Components" and "Variants". Given that computer UI is generally very repetitive, these components save designers time in building more copies of the same graphic with only slight modifications, let's say for states such as default, hover, selected, etc.

These design systems help bring the world of UI development into the graphic design applications. Many developers are very used to working with graphical components, but only until recently were designers able to work with them in a flexible graphical way.

KDE Plasma has never had a system like this to organize design around the UI. Because of this, designers haven't really made a ton of inroads into the system and this limits users in the way that we can deliver design for them. In essence, we designers, were never organized enough to provide a proper, development-ready, graphic design that could be used for Plasma.

This is where Ocean comes in. We took up the idea of creating a design system for Plasma that accounts for most, if not all, of the necessary graphical building blocks that developers could use, that preserve consistency between graphics and code, and deliver a cohesive experience for users.

By doing this, our hope is that graphic designers that are used to working with design systems can join our team and help us go even further.

On the developer side, a design system is a much more clear way of communicating component organization. Developers can more easily understand how buttons are made, what colors are used, what typography levels are on screen, etc. We do this by creating a series of graphic tokens that describe their use in more detail.

CSS is also involved, even though we may not support it, applications like Figma and Penpot have the ability to represent component code in CSS terms that others can read. In addition to these tokens, we create a series of foundational tokens where we declare our colors, typography, shadow levels and composition, blur levels, etc. Everything that users would need to see on the screen.

Ok, But What About the Graphics You Keep Showing?

During the first part of creating a design system, we noticed something pretty meaningful. Breeze and other previous themes, while they work, they don't have any reflection in a design system. Therefore, designers have a hard time completing the puzzle for a good design system that accounts for Breeze. With any attempt, we would be completing so much of a missing puzzle that we would create something new anyway, just to replicate a style in Penpot, for example.

Because of this, we decided to create a new style called Ocean and any style is composed of many parts, listed above.

Because of this, we created:

• Ocean Icons (In progress)
• Ocean Plasma Style (Complete in Penpot)
• Ocean Font (In progress)
• Ocean Style (Complete in Penpot)
• Ocean Color Scheme (Complete-ish, needs more testing)

And one little important detail, it doesn't matter so much how Ocean style looks. Why?

Because through a design system for graphic designers, we have the ability to distribute our system for free to anyone that wants to use it. Graphic designers can tweak the design tokens that Plasma can understand and by doing that, they can more easily build a Plasma Style on their own in a way that is cohesive, thoughtful, complete. We then give those elements to the developer team that would help us execute the design. Hence why I say that Ocean is a design platform.

Still, we created a new style in graphical form and we are working with the developer team to execute this style, using the design system tokens and components, in the same way that the designer intended.

Our current focus is on icons, particularly application icons. This is just one of the many parts that compose Ocean design. A few months ago we completed a round of design that created monochrome Ocean icons. These icons are functional in nature and much easier to put together. However, we knew that app icons take longer because they are colorful and require lots of time and styling.

Icons

My recent posts showcase the progress on these icons. To be more clear about how we are doing this icon design element, here is a process:

1. Formalize the visual system
   1. Define strict rules for perspective, lighting, shadows, gloss, depth, materials, and color usage so all icons feel like one coherent family.
2. Strengthen semantic readability
   1. Ensure each icon immediately communicates the app's purpose, especially at small sizes. Avoid abstraction that weakens recognition.
3. Improve visual hierarchy
   1. Reduce competing elements and make each icon have one clear focal point with cleaner foreground/background separation.
4. Tighten color discipline
   1. Use fewer competing colors, control saturation more carefully, and keep palettes more consistent across the set.
5. Be more selective with stylistic quirks
   1. Avoid asymmetry, misalignment, or unusual perspectives unless they clearly improve recognition or composition.
6. Standardize depth and rendering behavior
   1. Keep extrusion, internal shadows, dimensionality, and lighting logic consistent across all icons.
7. Shift from per-icon experimentation to system-level art direction
   1. Prioritize cohesion and consistency over making every icon individually novel or visually surprising.

…and we are in step 3 of the process for these icons. We are moving them from rough mockups and sketches into more formalized shapes. At this stage, you should not expect a lot of color or shape cohesion. After this pass comes a time of definition. We restrict our colors even more, simplify shapes for impact, remove or redo icons, etc. It's a major review. We expect to do this along with the community.

We also decided to not create icons for third parties. This makes the amount of app icons to make much smaller. This also makes it easier to think about what our icons should look like going forward.

All in all, Ocean is a platform composed of many parts. Our current design focus is set on completing the icon pack while the rest of the style is preparing for development.

I hope this makes it easier to understand and I am happy to answer any questions.

31 May 2026 9:14pm GMT

Joe Bloggs sat himself in front of his brand new laptop, pressed the On button and waited.

31 May 2026 5:35pm GMT

Welcome to another edition of "This month in KDE Linux" - KDE's in-progress operating system.

Infrastructure

This month we completed a major infrastructure project. Previously, our build process was generating Arch packages for KDE software and having mkosi install them; Hadi Chokr ported this to use KDE's kde-builder tool to compile all KDE software directly. This change brings three benefits:

• Better alignment with how developers compile KDE software themselves.
• Improves distro-agnosticism, so we can more easily get non-KDE software from a different source in the future should the need arise.
• Substantially faster by using a more effective caching system.

QA & testing

Another major focus this month was on improving KDE Linux's automatic QA story. The project already has a basic "does it boot to the desktop?" test for every build, but we can do much better.

To that effect, Bhushan Shah and Thomas Duckworth worked on finishing up the OpenQA-based testing system prototyped by Kangwei Zhu last year. Once fully integrated, this promises to hugely improve our ability to catch bad builds before they're released, and we can update it over time to catch even more failure conditions.

Harald Sitter also added a test using the existing system to make sure we don't ship an image with broken file capabilities. We did ship one bad build that includes a regression here, so this new test ensures that it won't happen again.

Security

After multiple security issues were discovered in the upstream Linux kernel last month, a few of us (Adrian Vovk, Hadi Chokr, and I) did a mini-audit of insecure and unused software included in KDE Linux. This resulted in a variety of positive changes:

• Returning to the vanilla kernel; it turned out the Zen kernel no longer offered very much beyond the config tweaks we had already made anyway.
• Deleting the insecure and unused alf_alg kernel modules.
• Replacing the NTFS and CDemu kernel modules with their userspace FUSE versions.
• Removing the out-of-tree OpenRazer and APFS kernel modules. It was nice to have these pre-installed, but we realized they would eventually cause us to fail secure boot review, and we should instead be working towards upstream solutions. APFS support can work in userspace anyway via its FUSE driver. It looks like it might be abandoned, though. So there may be no good option; we'll see.
• Removing a bunch of unused and unnecessary packages: acpi_call, busybox, cryfs, encfs, hplip, v4l2loopback-utils (yes it is indeed unneeded; you can do everything it does in userspace), and vpl-gpu-rt.
• Removing fuse2 as it's unmaintained and known to be insecure. This will unfortunately have the effect of breaking some old AppImage apps. If you encounter any, please report that as a bug to the app's authors/packagers; multiple other OSs have already removed fuse2, so apps really need to update to fuse3 ASAP.
• Removing fenrir, which it turns out was embarrassingly not used at all for various technical reasons. This allowed us to completely remove our usage of the AUR, which had been a source of infrastructure instability in the past.

Pre-installed apps

I implemented a service to install any new pre-installed Flatpak apps on people's existing systems. It ignores any apps you've previously uninstalled manually.

Speaking of new Flatpak apps, I replaced KWalletManager and its configuration page in System Settings with the new KeepSecret app, packaged using Flatpak.

I also updated Ark's nightly Flatpak packaging to include 7-zip support and generally synchronize it with the Flathub version.

Documentation

I migrated the project's website and documentation to https://linux.kde.org, where everything lives now. I also added a few more pages.

Grab bag

Hadi Chokr set up /opt/local for being a supported location for installing compiled binaries. This is because the usual /usr/local location is read-only on KDE Linux. This is now documented here.

João Pedro Silva Sousa fixed a bug that could make installation fail if there happened to be two KDE Linux live USB disks plugged in at once.

And that wraps up May! There's still lots to do, so if you're a fan of the project, please help out:

• User support: help support people on discuss.kde.org using KDE Linux.
• Issue reporting: install KDE Linux and report issues.
• Documentation: improve docs; submit merge requests here.
• Flatpak: fix packaging or code issues in Flatpak-packaged apps.
• OS development: help build KDE Linux! There's plenty to do.
• Kapsule development: work on our Incus-based Kapsule system, which is integral to the "expansion by experts" story.

31 May 2026 4:16pm GMT

This is my first weekly update as a Google Summer of Code 2026 student working with KDE on Kdenlive.

My project is "Improving Effect Widgets for Kdenlive." The first widget I'm working on is the Curves Widget, specifically adding per-channel tab support to the avfilter.curves effect.

The problem: Kdenlive's current Curves effect uses a dropdown to switch between channels (R, G, B). Switching channels wipes the previous curve there's no memory per channel. So if you tune the red channel and switch to green, your red curve is gone. You'd have to stack multiple instances of the effect to adjust more than one channel.

The fix: replace the dropdown with tabs (All, R, G, B), each storing its own curve independently, all serialized together into avfilter.curves format.

This week I went from zero code to functional tabs in Kdenlive.

What went in:

• Added m_channelData (std::map<CurveModes, QString>) to store per-channel curve state and m_tabBar (QTabBar) to CurveParamWidget
• Implemented slotTabChanged -> saves the current channel's curve before switching, loads the next channel's curve or resets to straight line
• Implemented serializeAllChannels -> builds the full avfilter.curves format from all channel data
• Created avfilter_curves.xml -> new effect definition with per-channel parameter support
• Fixed avfilter.curves being silently excluded from Kdenlive's effects list

R, G, B tabs are working correctly and affecting the video output. The "All" tab (master curve for all channels) is still being worked on.

Week 2 starts tomorrow.

31 May 2026 1:11pm GMT

Back in March at FOSSASIA in Bangkok, I got invited to visit the OpenKylin team in Shanghai. I mentioned it briefly at the end of that report, and here we are - the follow-up post.

31 May 2026 12:00am GMT

I'm Tomaz Canabrava, a developer with over 20 years of experience with compiled and non compiled languages. Having worked for projects in large and small companies, I have a broad understanding of the software development process.

My strong focus is in Rust, a systems programming language that I use to build high performance, reliable software. My previous focus was in C++ with Qt.

You can see the work I do on my GitHub, and at KDE

31 May 2026 12:00am GMT

So... progress continues on Oxygen

Over the last few weeks me and Pravin Kumar have been filling in some of the gaps in the icon set. There are still quite a few missing icons around the place, but slowly Oxygen is becoming a bit more complete again.

Its fun revisiting this old project after all these years. Sometimes I find myself looking at old icons wondering what younger me was thinking. Sometimes the answer is "not much"or, the answer is "way too much"..

Either way, Oxygen continues to grow.

Talking about fun...

I've also been spending some time investigating QML styling and themeing. And in this case not because i have immediate plans do this, but mostly because i am curious about what is possible and where the limitations actually are.

One thing I learned over the years is that there is often a large gap between what a toolkit "officially" allows and what a sufficiently stubborn designer can get away with

Some of the ideas are probably completely unreasonable. Some not so much

Which usually means they are worth exploring.

I've been experimenting with possible directions for O² and thinking about how a future visual language could work. And this that im doing now is more of an exploration on the range rgther than what it actualy look slike

Nothing concrete yet.

Mostly experiments.
Questions.
Terrible ideas.
Possibly a few good ones hidden among them.

If things continue to move forward we (via KDAB) probably make a video showing some of these investigations, experiments and concepts. Sometimes its easier to explain visual ideas by showing them instead of writing walls of text about them.

So stay tuned

And as always... if you are using Oxygen, thank you.

Its nice seeing that this old project still has a few new stories to tell.

30 May 2026 11:27am GMT