Welcome to another edition of “This month in KDE Linux” — KDE’s in-progress operating system.

This month was pretty smooth; we had no build delivery drama, and all OS images we shipped were of satisfactory quality. The project is maturing, and we’re 78% of the way towards completing the beta milestone.

QA & testing

Bhushan Shah and Thomas Duckworth continued working on the project to build a robust and modern automatic QA system. It’s really really close to being integrated at this point, and will act as a full-stack integration test for all of KDE Plasma in addition to a test system for KDE Linux specifically.

More user-friendly installation

Hadi Chokr did the huge amount of work necessary to transform KDE Linux’s .raw image file into a hybrid image that’s also a valid .iso file! This allows KDE Linux to be installed more easily using VM software that often expects to be given an .iso file.

Remember that you’ll still need to turn on UEFI mode, as KDE Linux still intentionally doesn’t support the legacy BIOS system!

Better audio CD ripping

Harald Sitter, Jan Rathmann, and I completed a small project to get KDE’s Audex app up on Flathub as a replacement for the audiocd-kio software we had previously been pre-installing on the image.

The problem with audiocd-kio is that it included two System Settings pages of questionable utility that offered a fairly old-fashioned UX. Now we don’t include those things, and instead we document how to download Audex and use it to rip CDs. And this way, you get automatic metadata lookup, too!

Easier log collection

Felix Araújo built a tool to ease the collection of logs called collect-logs. It also does some data sanitization. This will be very useful for bug reporting purposes!

Rudimentary “Developer Mode”

I created a very simple system to show and hide developer tools, and they’re hidden by default until you run toggle-developer-mode, which is documented here.

This reduces clutter in the launcher widgets of users who aren’t software developers. In the future we’ll add more to this script, and we might consider moving more tools off the base image and into Flatpak apps or even downloadable meta-packages, thereby coming full circle by re-inventing packaging. Go figure.

Documentation

I wrote documentation for how to configure input methods for Chinese, Japanese, Korean, and Vietnamese text input, in consultation with several speakers of these languages.

And in the near future, we plan to pre-install some of these tools to make things easier for the world’s 1.7 billion people who use one of them to communicate on their digital devices.

Grab bag

Thomas Duckworth made Plasma Browser Integration continue to be enabled by default with the latest version of Firefox.

I fixed ydotool, which I had previously broken by trying to force to run as a systemd service. Turns out it can’t do that. So now it’s at least disabled by default.

Yago Raña Gayoso enabled shell completions for kde-builder.

Aleix Pol Gonzalez removed a few pre-installed GTK libraries that it turns out weren’t used for anything.

Vishal Rao prevented the live session from writing to the system’s real-time clock, which could be a nuisance for people who don’t end up installing the OS and go back to their already-installed OS.

Clément Villemur made the Calamares installer not bug you to connect to the internet, because it doesn’t actually need internet access.

And that wraps up June! There are a lot of projects in flight right now, from finishing up the new QA system, to building moving the base OS with BuildStream, to hardening the kernel, to improving each image’s changelogs.

So there’s still lots to do! If you’re a fan of the project, please help out; there are many ways:

• 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.

Rust has achieved something extraordinary: it genuinely excites people to write software. But when it comes to building a real user interface, the ecosystem is still finding its footing. There are numerous options to pick your Rust UI framework from, including those gaining traction, like Iced and egui. Most of the available UI frameworks, however, are still establishing themselves in production environments and fall short in feature-richness. Qt Bridges, a bridging technology in public beta for Rust, brings something different to the table: over three decades of real-world use, commercial support, and a framework that already runs in automotive dashboards, medical devices, and industrial systems worldwide. Qt Bridge for Rust makes that maturity available to Rust developers, providing access to a UI framework that lets you keep your Rust codebase while using Qt Quick’s feature-rich UI libraries and APIs, hardware acceleration, and genuine cross-platform support.

Qt Bridges is a project we have been developing since 2025 to bring Qt’s UI framework capabilities to other programming languages, without going through the full set of bindings. The focus is on the interaction with backend data objects, seamlessly integrated as QML components in a Qt Quick interface.

A while ago, Steam OS 3.8 was released. Among its many improvements, it includes a particularly important one for the Desktop Mode: it finally uses a Wayland session by default.

There are many reasons why this is important for both us and our users. It is more stable, more feature-rich, and does a better job showcasing what Plasma can do.

For now, though, I just want to highlight one neat little feature that is especially handy on a touchscreen device like the Steam Deck: touchscreen gestures.

Out of the box, a three-finger vertical swipe enters Overview mode, showing thumbnails of all open windows. This provides a much more touch-friendly way to multitask, and you can also close a window with a downward swipe gesture. Of course this is a feature available on any device with a touchscreen.

For a while now, my colleagues and I over in Techpaladin Software have been working on software support for the Steam Machine, so it’s so awesome to see the product released!

Like everyone else, I was surprised by the pricing… until I went out and looked at what other hardware costs these days. It seems like in the past 6 months, everything with RAM got 50-100% more expensive. It’s kinda nuts. In light of, shall we say, industry trends (ahem), the price seems reasonable to me.

…especially if you see it less as a single-purpose gaming console and more as a desktop computer that offers a 10-foot UI living room gaming experience. Its horsepower is competitive for the price, and it offers the flexibility of a well-integrated desktop PC user experience. But don’t take it from me; ask Linus Sebastian, who’s rapidly becoming one of the biggest KDE boosters on YouTube:

Some choice quotes from the video:

And from the moment I fired it up and said “goodbye Steam Big Picture Mode”, and started using it as a desktop, I went… “This is what I’ve been waiting for the whole time.”

– Linus Sebastian

Plasma’s great.

– Linus Sebastian

“Plasma on retail hardware” has been my long-term goal for KDE since I first got involved a decade ago. This product is another example that not only can it work, but it can be as good or better than competing offerings.

So congratulations to everyone in KDE and outside of it who helped make this a reality! I’m unbelievably happy at how well KDE software is working for this use case these days, and I see even greater things in the future.

When working on a software library which is targeting 3rd-party consumers, it is rather of self-interest to make the library uncomplicated to use. Unless perhaps there is opportunity seen in having to help out in the process

And to know if it is uncomplicated to use, best before learning otherwise the hard way, one has to take the position of the consumers. Even better if this can be automated, after all that is why people developed machines, like computers, to pass on the dull part.

Many things of a library can be tested during the build, based on the sources and build artifacts. Like functionality of methods, proper export/visibility of their public entry points or the code any special pre-processor macros are resolved to. Here CMake’s VERIFY_INTERFACE_HEADER_SETS also offers a solution to verify that headers can be included on their own, though being bound to the build interface of the library.

Now, the consumer will only see the installed files, and there are for one things that can go wrong when installing even already tested files, as are there files which only work in the installation location or might work differently there, so can be only properly tested there.

Public Header Fails

When about to use a feature of a library, one would see to apply the documented needed include statement. E.g. when writing code dealing with the class KContacts::Picture of the KDE Frameworks module KContacts, the docs hint to use the following include to have any needed declarations available:

#include <KContacts/Picture>

So what could go wrong with such header file (e.g. Picture in the example above):

• the header file is not installed
• the header file is not placed in the relative location as by the documented include statement and the official include search directories
• the header file includes another header from the same library that is not installed (e.g. for test utils)
• the header file includes another header from the same library which is placed in a relative location not resolvable by the official include search directories
• the header file includes another header from a private dependency, so not resolvable by the inherited official include search directories
• the header file uses language features unconditionally of a standard not enforced in the public build flags
• the header file relies on macro definitions not provided correctly, either missing or with wrong value
• the header file is not self-contained with the variants of the headers part of the installation (violating C++ Core Guidelines, SF.11: Header files should be self-contained)
• (… possibly more, please mention in comments)

All these can be mainly checked by simply creating a C++ source file which only includes the very header file, by the documented include statement, and testing for its successful compilation/code parsing, applying the official include search directories and build flags (and the inherited ones of public dependencies).

CMake Config Fails

When about to use a library at all, one would see to use the meta data blobs which also integrate with one’s (meta) build system. E.g. in case of using CMake and as in the example above KF module KContacts, one would for setting up building against the library do as documented, relying on the CMake config files provided:

find_package(KF6 REQUIRED COMPONENTS Contacts)
target_link_libraries(MySoftwareProject PRIVATE KF6::Contacts)

So what could go wrong with those CMake config files:

• the CMake config files are not installed
• the CMake config files are not installed by the correct name and in the correct location
• the library target is not provided by the CMake config files at all
• the library target is not provided by the documented name and the optional namespace
• the library target does not have the correct include search directories set
• the library target does not have the correct build flags set
• the library target misses some documented properties
• the library target misses a dependency in the public link interface, to inherit as needed include search directories and build flags
• the library target has an item in the public link interface not checked for by the CMake config files
• other documented utility targets or variables are not defined or have wrong values
• (… possibly more, please mention in comments)

Most of these issues can be simply checked by creating a CMake project which searches for the library and links some dummy software to it, and testing for its successful configuration and build.

Other Fails

There are further library-related artifacts which should see checks after installation.

Any resources used from a library which are installed as separate files, like translation catalogs, images, sounds, or domain-specific data, could again be missed to be installed, installed by a wrong name or into the wrong location, or otherwise be badly processed before or during the installation process. Those are not specific to libraries though, thus not looked at more here.

Other artifacts are some which themselves are to be built against the library, such as project templates (like the KAppTemplate ones, e.g. for plugins) or examples for using the library. Those are not critical to the direct usage of a library though, thus also not looked at more here.

Continuous Integration As Limited Safe Guard

Software libraries are usually not developed in a void, but based on needs by other software. Changes in the public interface are made together with the respective changes in at least one consumer. So many issues would be detected in the process.

Then the library and many of its consumers, not just the ones a changes was made for, might be part of the same CI setup, where all these consumers would see at least some regular rebuild against the latest version of a library and thus would catch further regressions before the next release of the library.

But not all API of a library might be used by those known consumers, instead only by 3rd-party without any integration into the library development. And some issues of API while used can be shadowed by the usage pattern. So for a more complete check some generic own solution is needed.

Some Automation: ECMInstalledLibraryCheck

Combining the simple check ideas for headers and CMake config files above, some addition to KDE’s Extra CMake Modules is proposed in this merge request: ECMInstalledLibraryCheck. That module provides a macro to add checks for the installed library artifacts, from consumer POV. Currently it covers the public headers (includability) & CMake config files (proper data delivery needed for compiling). It adds one global target all_installed_library_check, to run the checks for all libraries, and a target per library, <library_target>_installed_library_check. Those targets would be used after installation only, obviously.

For the example used above, KF’s KContacts library, the check would be deployed like this:

# use the module from ECM
include(ECMInstalledLibraryCheck)
# for the library target KF6Contacts set up the check
ecm_add_installed_library_check(KF6Contacts
    PACKAGE_NAME "KF6Contacts"
    PACKAGE_VERSION ${KCONTACTS_VERSION}
    PACKAGE_TARGET_NAMESPACE "KF6::"
)
# register the official include statements for the check
ecm_installed_library_check_include_strings(KF6Contacts
    HEADERS ${KContacts_CamelCase_HEADERS}
    PREFIX KContacts
)

Given the library target KF6Contacts thus this adds the target named KF6Contacts_installed_library_check. This target generates and builds a separate CMake-based project for a dummy library linking against the installed library, whose sources are one source file per passed include string, with a single code line #include <include_string>. The check is considered passed if the builds completes without an error.

Additionally the checks can be extended to also cover CMake variables or preprocessor defines, by functions like ecm_installed_library_check_cmake_variable(), ecm_installed_library_check_compile_definition() and ecm_installed_library_check_preprocessor_macro(). The last also has some convenience variant ecm_installed_library_check_version_preprocessor_macros(), in our example deployed like this:

# check all includes also have the usual version macros defined afterwards, only report errors
ecm_installed_library_check_version_preprocessor_macros(KF6Contacts
    PREFIX KCONTACTS
    VERSION ${KCONTACTS_VERSION}
    SILENT
)

The current state of the prototype has already found a number of existing issues in a number of libraries, which so far had not yet been uncovered by consumers’ usage pattern, and first fixes have been rolled out to prevent consumers hitting them in the future.

It also has exposed a principal issues with projects like some KF modules that provide multiple libraries, yet only a single CMake config file for their module. Such file would need to ensure the combined dependencies of all libraries, which then adds unneeded burden to consumers of just one library. Currently the dependency checks in KF CMake config files are rather pragmatically added, when existing consumers stumble over something missing.

Hurdles To Adopting The Check Automation

Checks can only return value for the cost of integrating them if they are also routinely applied and their results considered. Worse, if not used they run chance of bit-rot and actually clutter a project.

Typically a library has a suite of auto-tests, covering all the features. While developers are encouraged to use them on their local system during development, they are at least used on the central CI system, against as many platforms and configurations as possible.

A first challenge with merging post-installation checks to the other checks and tests is that auto-tests are usually designed or at least prepared to be run pre-installation. KDE has had some “Running apps uninstalled” initiative, which resulted at least for auto-tests of KDE Frameworks to be also run on CI before installation. CMake only has the concept of one suite of tests, without an idea of pre-installation and post-installation test times. So one would have e.g. to create some custom system on top, e.g. by using CMake/CTest test labels. And for CI do extra work to run and process the two sets of tests separately.

Another challenge is that like all tests the ECMInstalledLibraryCheck checks come at a cost. While their creation is quickly done (generating a buildsystem file), the execution is taking some time. Because it mainly consists of a full compilation per each tested include statement, which despite just being a simple include line still results in lot of processing due to all the implicit overhead, even more when transitively including many template-ridden headers. And being a new system with some people the cost will scale the normal “don’t need this, never done that, no changes wanted” reaction.

Collaboration Wanted

The author is currently done when it comes to own immediate desires for the features of ECMInstalledLibraryCheck and uses it in personal projects as is. It has been though developed in the (KDE) public with the intent to share it, to have it be useful to others like KDE projects and gain from common usage and feedback.

Not being a CI system person, the author now is mainly looking for someone who can work on integrating the execution of ECMInstalledLibraryCheck checks with KDE CI (or also their own projects’ CI). The idea would be that the check of the installed library artifacts is as useful as any unit test, to catch issues with new code and regressions immediately, so should be run along the normal unit tests, just in its own post-installation stage. This stage could also later see the addition of post-install checks for templates and examples as well as other things which are found useful to test post-install. Ideally the check result would be integrated into the test result display, but for a start just successfully completing the build target should be already useful as indication. Possibly projects would opt in to the test using some configuration flag, or in case of KF could default to it. Perhaps CI integration will also require certain things from the macros, so ideally the CI deployment can be sorted out before ECMInstalledLibraryCheck gets merged and released. So if you find this kind of check useful and are experienced with (KDE) CI setup, please get in contact.

Then post-installation check of library artifacts might have further constraints or desires with some. Would people need doing parallel test of the installed library with different configurations or usage flags? Would people like to use this in cross-compilation (so far no generated code is executed, so in theory should be usable) and does that need further support? Are there other aspects of the installed artifacts you would like to see covered? Please give the current state of the check module a try for your own library projects and get in contact.

Try ECMInstalledLibraryCheck: Does Your Library Pass?

The file ECMInstalledLibraryCheck.cmake should only depend on CMake, so can be just copied into your own project:

• download the raw file from https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/work/kossebau/ECMInstalledLibraryCheck/modules/ECMInstalledLibraryCheck.cmake
• create subdir cmake/ecmcopy in your project, place ECMInstalledLibraryCheck.cmake inside
• make subdir known to CMake: list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/ecmcopy)
• include module: include(ECMInstalledLibraryCheck)
• setup check for your library targets, see docs at begin of module file how to do that
• run the installation target, then the target all_installed_library_check
• see how per library a project “InstalledLibraryCheck” is generated and build, the build log serves as success report
• if the check build fails, try to fix it, install (easy to forget ) and run the check target again
• if curious, peek into the build directory and look at the generated file ${library_target}_ECMInstalledLibraryCheck/CMakeLists.txt, it holds the complete check and can be also played directly with
  

The author has done this with many projects already, in KDE for all of KF modules as well as some graphics, games, multimedia, utility and education software libraries.

Now go and check your own library, and report back how useful ECMInstalledLibraryCheck is for you, what issues it discovered and what your further needs are here

Overview

I’m working on Marknote to introduce a block-editor inspired by popular note taking apps such as Notion. A block editor is a modern text editor that allows you to insert elements such as paragraphs, lists, tables, code, block quotes, etc. into separate blocks. Each block can be reordered, edited, and deleted. Such editors also give you the ability to insert elements by pressing “/” followed by the name of the element. This block based design of these editors make them very fun and intuitive to use.

A problem that most of these editors have in common is incomplete markdown support. They do not support the full commonmark spec. This means many things like nested blockquotes are not possible to use. Other problems include privacy concerns due to their closed sourced nature. They also are mostly web-based applications so they’re slow. This is where Marknote comes in. Marknote already is a popular note taking app by KDE. By introducing a robust block editor, users will be able to have a similar experience in an app that integrates beautifully with the KDE ecosystem, is offline, and most importantly respects privacy.

Current Status

GSoC’s coding period began on 25th May 2026. Unfortunately, my university exams began at the same time and ended on 11th June 2026. So I was not available for the first few weeks. I was still able to implement a big portion of the project.

Integrating md4qt

I spent the first few days making md4qt a dependency of Marknote. It involved adding it into CI images, creating a KDE Craft blueprint, updating the flatpak config as well, and finally making sure it builds correctly using CMake.

Building Markdown Model

After md4qt was finally usable in Marknote, I started working on developing the AsyncDocBuilder. This class allows Marknote to read a markdown file asynchronously (without blocking the UI), and emit a signal with an Abstract Syntax Tree (AST) which represents the parsed markdown document.

After that, I had to implement a tree model that represents the AST. The tree model inherits from QAbstractItemModel. It uses a wrapper class called the TreeItem that wraps around the AST. This represents a simple tree data structure where each node can have more than 1 children nodes. I was able to implement a working model succesfully, although it required a lot of brainstorming.

Getting Data to QML

The tree model represented elements in the parsed markdown document. Each element may have different properties. For example, headings have a level, lists have a listType, etc. Since this model will be used in QML, the data must be accessible in QML. For that, I wrote multiple helper functions that would extract data from each node and insert them into a QVariantMap. This map would be accessible from the blockData role of the tree model, allowing me to easily access properties about these nodes in QML.

Implementing Delegates

Now that the model is ready to use, we need QML delegates that will actually be rendered on screen. The biggest challenge here is that this model represents a tree. This means some elements can be present inside other elements. The standard built-in TreeView would not work here. The reason is that, instead of truly nesting QML elements, it uses indents to show a tree like structure. This is fine for things like file trees, but not for a block editor. In a markdown compliant block editor, the QML elements must truly be nested. To tackle this problem, I had to brainstorm for a week. I tried multiple techniques. One was using a Repeater where the Delegates call themselves, recursively. While this worked, it wasn’t compatible with the tree model that we have created. After a bunch of research, I found out about DelegateModel. It acts as a filter for models in QML. So I could just define a root index for the current view without modifying the actual model. So recursion was finally compatible with the existing tree model.

This step is still under progress. You can see in the attached video that basic markdown elements can be rendered. These are not editable yet, but markdown parsing and rendering works flawlessly.

Conclusion

Working on the block editor this month has been very exciting and challenging. There were some totally new problems that I had to solve that I didn’t foresee submitting my proposal. As always, this blog post does not involve the use of AI. All words are my own so it may contain grammatical errors :P

Ocean Icons in Penpot

I began the process of moving icons from Figma to Penpot. The icons are locate in the Icons page inside Penpot. This page contains some placeholder icon components created by our contributors. This was done so that we could use generic icons for UI as we complete more parts of Ocean design.

Including new icons from Figma into Penpot is not easy. There are a couple of drawbacks we see. Penpot does not have the same shape control that Figma does. Because of that, Penpot does not recognize shapes like circles, squares, lines, etc. Another issue is the importing erases the naming schemes that the icons have. This is a known bug at Penpot and they are working to resolve it.

Penpot also seems to do something pretty interesting on import. It creates a folder where the graphics are contained, it adds an invisible background image, and in some cases, a bitmap in the same structure. I believe these are just import issues that Penpot resolves in different ways. I hope their parsing on import gets better overtime.

However, with the new rendering engine in Penpot, the icon collection, though slow at times, is able to keep up with the rendering and I am able to load up thousands of svg icons in Penpot. Under the previous set up, this would not be possible without crashing.

Because of these two drawbacks, I had to flatten all the images before exporting. Otherwise, Penpot could run into rendering issues as svg code from Figma has its own quirks. Still, with these compromises, I was still able to copy all the monochrome icons built for Ocean into Penpot. Now, I have to take the time to rename all the icons to their proper names. There are also some icons that don’t render properly, or at all. For those icons, I will have to take them case by case and fix them.

After renaming all these icons and getting them to their proper organization, I will create components from them that can be used in UI throughout the file.

Ocean + Union June Meeting

Earlier this month, we also connected with the Union team to discuss the implementation support of reference tokens and semantic tokens from Penpot into Plasma. We also discussed the creation of Ocean assets.

Providing support in Plasma for Ocean design tokens is no small feat. It requires careful preparation. This is one of those elements that Ocean Design provides. The goal here is that Plasma and applications are able to support the tokens/variables provided by the Ocean design system.

In a distant future, our goal would be to give the Ocean system to anyone willing to create their own version. They would export their tokens and Plasma would support them without the need for additional code. This achieves a couple of great things, one is that designers work in an environment that is ready for editing with all the graphical sources needed, no need for coding skills. On the other hand, this should push interested users into designing and testing their designs first, without the need to push code first, which requires the mobilization of our teams to review, adapt and provide feedback. It’s a “cheaper” effort to work with graphics first and see how they would look after export.

There are more benefits to this approach, but these are two that I always go back to.

From this meeting, our determination is that I should provide a series of spec files containing all the technical details from the foundational components in Penpot. These components are the smallest bit of interaction in graphical systems. Buttons, shadows, typography, etc. These are akin to the bricks on a wall.

With this idea in mind, I was able to create and provide the specs to the Union team.

New Components in Penpot

Continuing with the process of creating sample components in Penpot, we now feature:

• Application Navigation: This page contains sidebars for desktop and mobile.
• Section Footers: This page contains footers used in application footers or even websites, for desktop and mobile sizes.
• Inline CTAs (Calls to action): These CTAs help users make quick decisions on a piece of information without the need for taking over the screen using Modals, for example.
• Section Headers (Received an expansion): Section headers used to be just one version of the component. This was expanded to add more versions.

Please note that these components are "not" Plasma components and is not indicative of Plasma's future state. These are here for inspiration for the future, and for users looking to test their design edits and results. Eventually, these could serve as starting points for layout design, component creation, etc.

In addition to these component samples, I am now working on building a calendar view component. I am taking inspiration from Merkuro Calendar and also including some ideas from Ocean. The idea is that a calendar view could be available for others to use and test designs against. More to come on this.

Fixes in Ocean Design System

• Fixed layout and design for dropdown items. They were previously just text in a layout. They are supposed to behave differently inside dropdown menus. They need to have inner margins and separation from other items in a list. The shortcut component also received updates and looks more legit than before. This should make it easier to use dropdown components in Penpot.
• Created a dot component that is used in Calendars to show activity or reminders inside monthly views.
• Inputs components received updates so they behave better when manipulating sizing. There were some issues with containers and components inside containers so I tried fixing those. There is an existing Penpot bug that when components are updated at the source, the component copies tend to go back to use fixed sizing instead of dynamic sizing. This makes me cycle through fixing not just sources but copies of the components. It seems the issue is in nested components where the parent takes over some of the sizing properties. Penpot is working on this.
• Created the checkmark inside a circle component. This component is meant to be used when running through selections that need to indicate success in their interaction. For example, completing a survey, or a multi-step installation procedure. A checkbox is not appropriate there but a circle with a checkmark inside. So now that’s available. It’s not using a monochrome Ocean icon checkmark yet, but that can be changed in the future.
• Avatars are now using an image with color all inside. Previously I had an avatar image that was white and it made it difficult to see the white border around the avatar image.

Next in Component Design

• Calendar view
• Slideout menus
• Progress steps

Thanks

• Thanks to Beryesa for creating the Penpot Design Notes page. This is super helpful when users need to understand what they are looking at and how it is used in the system.
• Thanks to iclone for his work on commenting around UX issues in the VDG channel.
• Thanks to the Union team for all their support for Ocean.
• Thanks to Lorenz for helping me troubleshoot some crashes in Penpot.

Penpot Issues and Features

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

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:

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.

MR !887 merged

The Curves widget MR got merged to master this week and will ship in the Kdenlive 26.08 release. Final change before merge was replacing blockSignals(true/false) pairs on the point spinboxes with QSignalBlocker objects, which auto-unblock when they go out of scope cleaner and safer than manual pairs.

Gradient widget skeleton

Started work on the Gradient widget, targeting the gradientmap MLT filter. The filter already supports up to 32 color stops via stop.N parameters (e.g. stop.1="#ff000000 0.0"), but Kdenlive's existing XML only exposed 2 stops with the wrong parameter type.

Built a new GradientEditWidget in src/assets/view/widgets/ with:

• Draggable color stop handles on a live QLinearGradient preview bar
• Left-click on empty area adds a stop with an interpolated color
• Right-click on a handle removes it (minimum 2 stops enforced, max 32)
• Serializes to/from the MLT stop.N format via a new ParamType::GradientEditor wired through AssetParameterModel
• Project save/reload round-trips correctly

Added gradienteditwidgettest.cpp with 8 assertions covering serialization round-trips, add/remove stops, min/max enforcement, and position snapping. All passing.

What's next

Julius Künzel suggested the widget be designed for potential upstreaming to KDE Frameworks, and pointed to Qt-Color-Widgets as a reference; it has a GradientEditor class with a polished UX. Investigating whether to wrap that instead of maintaining a custom implementation. Will update once there's more clarity on the direction.

Both the Gradient widget MR and the Qt-Color-Widgets investigation are in progress; more next week.