Planet KDE | English

This Week in Plasma: Better Animations

Nate Graham — Sat, 04 Jul 2026 00:00:01 +0000

Welcome to a new issue of This Week in Plasma!

This week Plasma 6.7 received a few more stabilization bug-fixes while attention turned towards the upcoming 6.8 release. Some exciting changes are in progress, and a few have already merged, including highly visible improvements to some common animations.

Check it out!

Notable new features

Plasma 6.8

Updated the Emoji Selector app to version 17 of the Unicode emoji standard, giving you access to derpy new emojis like “🫪️”. (Jens Jerosch, plasma-desktop MR #3849)

Notable UI improvements

Plasma 6.7.2

Moved the global “Move Mouse to Focus” and “Move Mouse to Center” actions out of the Zoom effect, so they still work even if you’ve globally disabled the Zoom effect. (Vlad Zahorodnii, KDE Bugzilla #522070)

Plasma 6.7.3

Made KRunner’s Bookmarks search provider return results for 2-character queries (so it will match “Qt”, for example), and use fewer system resources. (Kai Uwe Broulik, plasma-workspace MR #6764)

The Clipboard widget’s Actions Configuration page now uses better internal margins for the content. (Levi Leal, plasma-workspace MR #6779)

After

Before

Plasma 6.8

The “Bouncing app icon” launch feedback style now uses a more visually pleasing animation with a better physics model, a more appropriate easing curve, and a higher frame-rate. (The Entropyist, kwin MR #9487)

The new sliding animation for notifications now uses a more natural easing curve, so it looks even better than it already did! (Thomas Duckworth, KDE Bugzilla #522276)

There’s no longer a secret keyboard shortcut (previously Meta+Ctrl+x) that turns on clipboard actions. This was easy to press by accident, and would then make weird popups appear when you copied URLs. (Tobias Fella, plasma-workspace MR #6773)

The Digital Clock widget now requests “tabular numerals”, which are monospaced digits supported by some fonts. The use of these numerals prevents the clock from changing its width as time passed in a few edge cases where the existing code to prevent that wasn’t good enough. (Christoph Wolk, plasma-workspace MR #6797)

Discover’s old “CD and DVD” category is now named “Disc Burning”, because that’s what apps expect it to be, which explains why it only contained disc burning apps. (Nate Graham, discover MR #1350)

After

Before

And before you ask: no, we couldn’t instead change the category to include all apps related to CDs and DVDs, because it’s a standard category governed by a FreeDesktop spec, and to do that, we’d need a new one.

Info Center’s Memory page now shows a busy indicator if it takes more than a moment to load. (Kai Uwe Broulik, kinfocenter MR #305)

You can now find the System Settings page responsible for the “press and hold a key to see alternative characters” popup, so you can more easily turn it on or off or change how the delay before it appears. (Kristen McWilliam, plasma-keyboard MR #154)

The DrKonqi crash reporting wizard now tells you when it’s safe to close the window. (Antti Savolainen, drkonqi MR #397)

Notable bug fixes

Plasma 6.6.6

Hardened the Task Manager widget against maliciously-crafted .desktop files for apps (David Edmundson, plasma-workspace MR #6817).

Hardened the ksystemstats_intel_helper process against path traversal attacks. (Matthias Gerstner, ksystemstats MR #141)

Plasma 6.7.2

Fixed a recent regression that made certain screens incorrectly notify about being disconnected and re-connected in a loop after they want to sleep. (Xaver Hugl, KDE Bugzilla #521826)

Fixed a recent regression that produced corrupted visuals on some rotated screens and with some older AMD GPUs. (Xaver Hugl, KDE Bugzilla #521878 and KDE Bugzilla #521764)

Fixed a recent regression that broke the ability to drag desktop files and folders between screens. (Marco Martin, KDE Bugzilla #521713)

Fixed a recent regression that made SDR content look a bit de-saturated for some screens while in HDR mode. (Xaver Hugl, KDE Bugzilla #521759)

Fixed a recent regression that made certain ICC profiles show the wrong colors. (Xaver Hugl, KDE Bugzilla #522301)

Fixed a recent regression that made KWin lag and hang when playing certain poorly-optimized games via Proton. (Vlad Zahorodnii, KDE Bugzilla #522005)

The implementation of the new “press and hold for alternative characters” feature now prioritizes compatibility for apps, fixing a massive number of bugs. (Kristen McWilliam, plasma-keyboard MR #152)

The new Vietnamese calendar now shows the correct dates. (Trần Nam Tuấn, KDE Bugzilla #522099)

The new feature to show how much earlier or later a time zone is than your current one now correctly calculates the value for time zones with a half-hour offset that are earlier than your local time zone. Time is hard. (Michael Kohl, KDE Bugzilla #522037)

Forcing the use of the software pointer no longer makes it disappear when a window pushes a panel in “Dodge Windows” mode into its hidden state. (Xaver Hugl, KDE Bugzilla #521953)

The Mouse page in System Settings no longer shows layout glitches on X11. (Marco Martin, KDE Bugzilla #521992)

Text on the Networks widget’s Details tab can no longer visually overflow when it’s really long. (Manuel Alcaraz, KDE Bugzilla #522333)

Plasma 6.7.3

The “Kameleon” system service is now disabled by default, which prevents it from applying a color to your keyboard’s backlit keys even if the feature to apply colors to RGB keyboard backlighting disabled. The context here is that we added support for the Steam Machine’s LED strip, and this also made it work for many keyboards, but exposed a pre-existing bug. (Oliver Beard, KDE Bugzilla #521793)

Spectacle no longer includes the tooltip showing image dimensions in the final screenshot if you accept a rectangular region by double-clicking it. (Noah Davis, KDE Bugzilla #513715)

Plasma 6.8

Fixed the most common crash in Plasma, which could happen once in a while when using multiple screens. (Marco Martin, KDE Bugzilla #500044)

Minimizing the window of an RDP client no longer stops the video stream. (Shouvik Kar, KDE Bugzilla #497765)

Frameworks 6.28

XWayland-using apps no longer start to behave in a couple of weird and quirky ways after XWayland itself crashes and restarts. (Vlad Zahorodnii, kwindowsystem MR #220)

Notable in performance & technical

Plasma 6.7.3

Fixed a recent performance regression that increased KWin’s CPU usage on some Intel systems using atomic mode-setting. (Xaver Hugl, KDE Bugzilla #522075)

Plasma 6.8

Implemented support for version 1.6 of the Emulated Input system. (David Edmundson, kwin MR #9112)

KWin now internally only uses OpenGL ES, which ensures that it will always be working since everyone will be using it — at least until Vulkan support is farther along. OpenGL ES is necessary for some old GPUs and turns out to be sufficient for everything KWin needs anyway, so we don’t anticipate any downsides from this change. (Xaver Hugl, kwin MR #9488)

How you can help

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

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

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

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

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

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

Tellico 4.2.1 Released

Tellico Blog — Fri, 03 Jul 2026 16:55:14 +0000

Tellico 4.2.1 is available, with some improvements and bug fixes.

Improvements:

Added user-defined data fetch argument (Bug 516055).
Updated Google Scholar and Colnect data sources.
Updated Google Books data source (Bug 522095).
Updated external data source to allow termination by user (Bug 516057).
Updated to allow multiple ISBN values (Bug 521157).
Updated Album template to hide empty track tables and use loan information.
Increased minimum image reader memory limit.

Bug Fixes:

Fixed bug with exporting linked images (Bug 522094).
Fixed bug with parsing field names with emoji (Bug 521148).

Web Review, Week 2026-27

Kevin Ottens — Fri, 03 Jul 2026 10:36:56 +0000

Let’s go for my web review for the week 2026-27.

What happened to the fight for the Internet?

Tags: tech, politics, surveillance

Excellent piece, where are the netizens who should be fighting back those bills? Looks like we became very complacent and passivity reigns this time around. Didn’t think it was related to the pervasive centralisation already in place… but indeed that might be a strong contributing factor.

https://dustycloud.org/blog/what-happened-to-the-fight-for-the-internet/

Age verification is just a precursor to attribution of speech

Tags: tech, politics, law, surveillance

Definitely this, we can’t trust this kind of mechanism for what they open the door to.

https://nonogra.ph/age-verification-is-just-a-precursor-to-attribution-of-speech-06-29-2026

my review of uruky

Tags: tech, web, search

Several times I bump into articles praising this one. I’ve been test driving it a bit, the experience is still a bit bare but it’s clearly maturing. Definitely an option to keep an eye on in my opinion.

https://blog.sulimans.space/my-review-of-uruky/

Zuckerberg’s increasingly bizarre war on whistleblowers

Tags: tech, social-media, facebook, ethics

There might be a method behind the madness of the thin skinned autocrat heading Meta… Unfortunately it probably works.

https://pluralistic.net/2026/06/27/zuckerstreisand-2/

Chatbots vs. Ozone

Tags: tech, geospatial, ai, machine-learning, gpt, economics, ecology

More reasons why the whole “data centers in space idea” is stupidly dangerous and likely unreachable.

https://blog.dshr.org/2026/05/chatbots-vs-ozone.html?m=1

Claude Code Is Steganographically Marking Requests

Tags: tech, ai, machine-learning, gpt, copilot, trust, security, privacy

You sure you can trust those systems? It’s proprietary software and they’re clearly on a slippery slop. For something so security sensitive this is concerning.

https://thereallo.dev/blog/claude-code-prompt-steganography

Prompt Injection as Role Confusion

Tags: tech, ai, machine-learning, gpt, cognition, security, safety

Interesting paper (go to the full one for all the details) which shows that with the current architecture it’s really hard if not impossible to make safe systems with LLMs. This gives interesting insights in the weird form of proto-cognition those models exhibit.

https://role-confusion.github.io/

Text Editor: Data Structures

Tags: tech, text, editor, design

Neat introduction to the right data structures to use when making a text editor.

https://www.averylaird.com/programming/the%20text%20editor/2017/09/30/the-piece-table.html

Engineering High-Performance Parsers with Data-Oriented Design

Tags: tech, data-oriented, architecture, performance, parsing

Interesting article applying data oriented design to parsing tasks. This is really a good approach for performance.

https://www.arshad.fyi/writings/engineering-high-performance-parsers

Data Access Patterns That Makes Your CPU Really Angry

Tags: tech, cpu, memory, hardware, performance

Interesting experiment on how to totally break the performance of memory accesses. This gives good insights on the whole chain works.

https://blog.weineng.me/posts/slowest_add/

The Physics of Memory

Tags: tech, javascript, memory, data-oriented, performance

Unsurprisingly cache locality is a very important factor. What’s interesting here is that it still applies to a language like Javascript where you’d expect to not have enough control on the memory layout to reap any benefits.

https://www.dmurph.com/posts/2026/06/ecs_vs_oop_benchmark/ecs_vs_oop_benchmark.html

High-performance Rust: Understanding and eliminating memory fragmentation

Tags: tech, rust, memory, embedded, performance

Interesting Rust options to limit the amount of heap allocations if you’re constrained by memory or for performance reasons.

https://kerkour.com/rust-high-performance-memory-fragmentation-allocations

Hobby’s algorithm for aesthetic Bézier splines

Tags: tech, graphics, mathematics

Interested in splines? This is a gentle introduction which points to further resources if you want to implement them.

https://www.jakelow.com/blog/hobby-curves#fn-2

What To Learn To Be A Real Time Graphics Programmer

Tags: tech, 3d, shader, mathematics, graphics

Wondering what to learn to get into graphics programming? This is a nice list.

https://blog.demofox.org/2026/07/01/what-to-learn-to-be-a-graphics-programmer/

Announcing Box3D

Tags: tech, physics, simulation, 3d

Exciting! This looks like a neat 3D physics engine.

https://box2d.org/posts/2026/06/announcing-box3d/

The essence of architectural work

Tags: tech, architecture, complexity

This is an ongoing series, but there are good insights about software architecture work in the first few articles. Shows quite well the important tradeoffs and the usual traps.

https://www.ufried.com/blog/essence_of_architecture_1/

Every bottlenose dolphin invents a unique whistle that becomes its name

Tags: biology, nature, cognition

So using personal names is not an inherently human trait, this is confirmed through research now. Before their were signs and suspicions, but now the trail of evidences is strong.

https://spacedaily.com/d-within-the-first-few-months-of-life-every-bottlenose-dolphin-invents-a-unique-whistle-that-becomes-its-name-for-the-rest-of-its-life-and-other-dolphins-learn-that-whistle-remember-it-and/

Notes from a burning Paris

Tags: climate, ecology

This is what things will look like in the coming years. Only probably worse, and for more and more people.

https://sarahwilson.substack.com/p/notes-from-a-burning-paris

Bye for now!

Attention to Detail

Kai Uwe Broulik — Fri, 03 Jul 2026 10:23:38 +0000

A couple of months ago I improved some of our dialogs and this time I worked on some more. Did you know that you can just paste the clipboard’s content into the Dolphin file manager or on the desktop to create a new file from it?

Just paste your clipboard’s content to create a new file

Tobias Fella added a proper “platform message dialog” for Qt to use. This replaces the hideous Qt Quick message dialogs you could see in some places. With that, we are also finally able to play our message box sounds for Qt-only applications using QMessageBox (instead of KMessageBox or KMessageDialog). To do this, Qt sends an QAccessible::Alert event that is then handled by the relevant platform accessibility integration. On Windows it for example calls the win32 PlaySound API. However, I didn’t want to mess with Qt’s AT-SPI¹ stack just for this. Now that we provide a custom dialog, we might as well play the sound from there.

Just like the “New File” dialog, the paste dialog mentioned above also displays the file icon now. It also tries to guess what kind of file it is and automatically suggests a matching file extension. For example, copying something that looks like HTML will suggest the name “pasted file.html”. You are of course still free to choose a different file name and extension.

An application can also suggest a name using the custom application/x-kde-suggestedfilename MIME type. Spectacle does this so a screenshot copied to clipboard and then pasted (rather than saved directly) will nevertheless use a “Screenshot_xyz” file name. The clipboard history now remembers the suggested name when it stores an entry so when you recall it later it will still use that name as expected.

Little preview icon when configuring syntax highlighting

When dropping a folder into Kate, all files contained within will be opened. Kate has always been able to open files on remote locations thanks to KIO but the drag and drop code only worked with local folders. This is now fixed and you can drop a folder from a SMB or other share into your Kate the same way as any local one.

A nifty addition to both the menu and settings page for choosing a syntax highlighting color scheme is a little preview icon similar to the application color scheme. This lets you roughly judge the appearance of the theme before selecting it.

Finally, KWin’s debug console (Open KRunner, type “KWin”) received a “Pick Window…” button. This way you can more easily find a particular window in the potentially long list of windows. The kwindowprop tool (KWin’s equivalent to xprop) now also includes the PID of the process owning the window.

Assistive Technology Service Provider Interface, a cross-desktop accessibility framework ︎

Week 5: KWallet XML Import & Password Generator

Roshani Kumari — Thu, 02 Jul 2026 12:48:00 +0000

This week I shipped two new features for KeepSecret. KWallet XML Import (!34)

The Import menu on the wallet page is now a submenu with two options:

-KeepSecret…

-KWallet XML…

Both import formats are converted into the same internal format, allowing them to use the existing import code. I only implemented import support, since exporting to the old KWallet format wasn't necessary because KWallet is being deprecated.

Password Generator (!35)

I added a Generate button to the Create New Entry dialog. Clicking it generates a random 16-character password and fills the password field.

The password is generated in SecretItemProxy::generatePassword() using QRandomGenerator::global(), which uses the operating system's secure random source. A character set is built from the selected options (lowercase letters, uppercase letters, numbers, and symbols), and each character is chosen randomly from that set. This also allows passwords to include symbols like !@#$%^&*.

The function returns a QByteArray instead of a QString, matching the existing code and avoiding an unnecessary copy of the secret in C++.

During code review, Michael K83 pointed out that secrets stored in normal QByteArray or QString objects are not automatically erased from memory after use. He suggested looking at how ksecretd and KeePassXC handle secure memory.

Marco Martin explained that an even bigger challenge exists once the password reaches QML. The password becomes a QString inside the QML engine, where Qt may create multiple internal copies that cannot be explicitly cleared. It will be addressed separately in issue #25.

KDE Gear 26.04.3

KDE Community — Thu, 02 Jul 2026 00:00:00 +0000

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:

elisa: Change output device when global output is changed (Commit, fixes bug #512126)
kdeconnect: Fix file transfers when notification sending is enabled (Commit, fixes bug #516765)
kdenlive: Fix timeline playhead going out of view while playing (Commit, fixes bug #517494)

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.3 source info page
26.04.3 full changelog

Persistent copyright & licensing information in client-side JavaScript, CSS and similar – feedback and second proposal

Matija Šuklje (hook) — Wed, 01 Jul 2026 22:00:00 +0000

At FOSDEM 2025 I presented my (intentionally controversial) proposal how to keep copyright and licensing info in minified JS/CSS and asked for feedback, including from front-end developers.

Two months later, I took the feedback from FOSDEM and held a small workshop session with a group consisting of OSPO leaders, FOSS lawyers and a handful of FOSS developers at LLW 2025.

This blog post was finished¹ more than a year after both, so I will not be summarizing my FOSDEM talk, and suggest you listen to it (esp. the Q&A part), if you are interested in the details.

But I will summarize the results of both sessions below.

Are SDPX IDs enough for compliance or not (given their templating)¶

Someone argued that for certain licenses – specifically, e.g. the MIT and BSD family – even the SPDX License List has a some templating in place, and as such identifying it with just an SPDX ID would not fulfil the license obligations, by strict reading of the license.

That is a concern that I identified already in my original proposal and I agree that my proposed approach has a certain amount of “handwaving”, which is not 100% risk-proof.

(Spoiler: we fix this issue in the final proposal. Wait for the next blog post in this series.)

Impact on size of the minifed code¶

A common concern from web developers was how much keeping the SPDX/REUSE tags in the minified code would impact the its size.

With the help of the wonderful Lukas Taegert-Atkinson of Rollup fame, we managed to get a good idea what the impact adding REUSE/SPDX tags to all the files would have on the size of the minified code.

As an PoC Lukas made the following change to the build process of Rollup Browser, so we could compare the size of the minified code before and after the diff.

diff --git a/rollup.config.ts b/rollup.config.ts

--- a/rollup.config.ts (revision 384d5333fbc3d8918b41856822376da2a65ccaa3)
+++ b/rollup.config.ts (date 1742569205307)
@@ -152,7 +152,22 @@
  collectLicensesBrowser(),
  writeLicenseBrowser(),
  cleanBeforeWrite('browser/dist'),
- emitWasmFile()
+ emitWasmFile(),
+ {
+ name: 'add-fake-tags',
+ transform(code) {
+ return {
+ code: `/*!
+* SPDX-SnippetBegin
+* SPDX-SnippetCopyrightText: © 2021 Test Dummy <dummy@test.example>
+* SPDX-License-Identifier: BSD-2-Clause
+*/
+${code}
+/*! SPDX-SnippetEnd */`,
+ map: { mappings: '' }
+ };
+ }
+ }
  ],
  strictDeprecations: true,
  treeshake

If Rollup Browser was built as per default, the full minified code resulted in 374 KiB.

After the patch that caused (dummy) snippet-level SPDX tags to be inserted into all the code (Rollup itself and its dependencies), the size grew to 415 KiB though.

That is a 11% increase in size. Not exactly negligible, but definitely far from terrible. And if tooling were to be updated, with de-duplication we could possibly take that number down quite a bit too.

In the previous tiny Svelte + Rollup + Terser PoC, both with and without SPDX tags are 12 KiB, so we need take a magnifying glass to compare 12.681 bytes with tags, and 12.324 bytes without them – that is just a 3% difference.

And in the previous React Scripts (+ WebPack + Terser) PoC, the overall build size is virtually unchanged, but oddly enough while some files become bigger, others become smaller.

With REUSE tags, the total size of build/static/ is 536 KiB (specifically, 531.070 bytes):

build/static/css:
.rw-r--r-- 1.038 hook 3 apr 01:54  main.05c219f8.css
.rw-r--r-- 1.759 hook 3 apr 01:54  main.05c219f8.css.map
build/static/js:
.rw-r--r-- 4.534 hook 3 apr 01:54  453.2a77899f.chunk.js
.rw-r--r-- 10.597 hook 3 apr 01:54  453.2a77899f.chunk.js.map
.rw-r--r-- 143.544 hook 3 apr 01:54  main.608edf8e.js
.rw-r--r-- 1.205 hook 3 apr 01:54  main.608edf8e.js.LICENSE.txt
.rw-r--r-- 368.393 hook 3 apr 01:54  main.608edf8e.js.map

and without the SPDX tags, the total size of build/static/ is also 536 KiB (specifically, 529.880 bytes):

build/static/css:
.rw-r--r-- 779 hook 3 apr 01:53  main.f855e6bc.css
.rw-r--r-- 1.427 hook 3 apr 01:53  main.f855e6bc.css.map
build/static/js:
.rw-r--r-- 4.534 hook 3 apr 01:53  453.2a77899f.chunk.js
.rw-r--r-- 10.597 hook 3 apr 01:53  453.2a77899f.chunk.js.map
.rw-r--r-- 143.544 hook 3 apr 01:53  main.608edf8e.js
.rw-r--r-- 1.070 hook 3 apr 01:53  main.608edf8e.js.LICENSE.txt
.rw-r--r-- 367.929 hook 3 apr 01:53  main.608edf8e.js.map

Which is a difference of measly 0.2%.

Lukas was also quick to point out that a ballpark estimation of how much extra space this would take is quite easy to calculate, as all it is needed is to count all files that would be included in the final JS (or CSS) bundle and multiply that with the size of the SPDX tags. As such, the impact would be bigger on projects that have many very short source code files, while smaller on those that have fewer, but longer source code files. Again, this is without taking any de-duplication into account.

So we can come up with a generic formula:

size = normal_minified_size + (number_of_files × 4_extra_lines)

What was the cause of the problem with the Snippet-Begin and Snippet-End tags?¶

You may recall in my original proposal that there was an issue with the SPDX-Snippet-Begin and SPDX-Snippet-End tags being jumbled in the resulting minified code.

According to Lucas, this is most likely something Terser caused when associating comments to functions and then optimizing the code. He is fairly positive it can be solved though.

(Again, spoiler: this will be a moot issue in the end. Wait for the next blog post.)

Do we need tags in the minified code?¶

Of course, a very good question is whether we need the REUSE/SPDX tags in the minified code itself. Especially, given that we do not require something as strict for other non-source code (e.g. compiled code).

I admit, I do not think we actually need to.

To be honest, why that is in the original proposal, is because I was trying to push just how far we can bring license compliance in client-side JS/CSS by just leveraging already existing standards and tools. It turns out we can push it very far – arguably ad absurdum ;)

So, no, I do not think we need that, but it was a good thought experiment and I think it was necessary to get discussion going².

Alternative proposal: SBOM¶

But if we do not keep it in the code we ship, where do we keep the license/copyright info then?

At LLW 2025 we had a pretty intense session where ultimately we came up with an alternative proposal to generate an SBOM and ship that instead. This solves a lot of issues and is something that license compliance officers are already familiar with. It would also bring it closer to how we manage licensing when shipping non-web software.

The SBOM approach would require use of tooling and by the end of the day we were left with a bunch of loose threads, but in general, this sounds like a good way forward.

Conclusion: plan B in the making¶

Was all the effort now wasted?

Not at all.

Web pages and (SaaS) web applications are still a bit of a different beast, so we learned a lot in the past two years due to this exercise.

I am pretty confident we now have a way how to fulfil the license obligations:

without making the web page too heavy;
burdening web developers any more than other programmers;
shipping machine-readable compliance artifacts; as well as
making the information ready for human consumption too.

In the next blog post I will present the final proposal.

hook out → I think we’re slowly onto something …

I am truly sorry, but there was just way too much going at work and in private, so I neglected my blogging for some time. ↩
You know the old adage: The fastest way to get an answer to your question on the internet, is to provide a false anwser and wait for everyone to rush to correct you ;) ↩

This month in KDE Linux: June 2026

Nate Graham — Wed, 01 Jul 2026 18:52:57 +0000

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.

A Cross-Platform Rust UI Framework via Qt’s Bridging Technology

Qt Dev Loop — Wed, 01 Jul 2026 14:15:22 +0000

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: Public Beta for the Rust Bridge Is Out!

Qt Dev Loop — Wed, 01 Jul 2026 14:15:20 +0000

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.

Steam Deck and Wayland

Marco Martin — Wed, 01 Jul 2026 12:23:26 +0000

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.

The Steam Machine is here!

Nate Graham — Tue, 30 Jun 2026 18:48:11 +0000

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.

C++ Library Headers & CMake Config Files: Are We Serviceable?

Friedrich Kossebau — Tue, 30 Jun 2026 17:33:05 +0000

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

GSoC - Working on Marknote

Prayag Jain — Tue, 30 Jun 2026 17:00:00 +0000

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.

Your browser does not support the video tag.

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 Updates – June 2026

Andres Betts — Tue, 30 Jun 2026 13:27:11 +0000

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

https://github.com/penpot/penpot/issues

KDE Plasma 6.7.2, Bugfix Release for June

KDE Community — Tue, 30 Jun 2026 00:00:00 +0000

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:

View full changelog

Week 5: Curves Merged, Gradient Widget Begins

Yash Bavadiya — Mon, 29 Jun 2026 19:55:12 +0000

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.

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.

Monthly Report - June 2026

Krita News — Mon, 29 Jun 2026 00:00:00 +0000

Read on for a look at development news and the Krita-Artists forum's featured artwork from last month.

Development Report

Krita 5.3.2.1/6.0.2.1 Released

A 5.3.2.1/6.0.2.1 hotfix release was made to fix two serious regressions.

First, a layer-related problem causing issues like the wrong layer being selected or crashes was fixed. This reverts the behavior of the layer being changed on keyframe selection. (bug 1, bug 2, bug 3; change)

Second, a crash when inserting or removing hold frames was fixed. (bug; change)

Developments in Krita Plus

Android Donations Overhaul

On Krita downloaded from the Android Google Play store, it was possible to purchase a supporter badge as a way of donating to the project.

For the next release, Carsten has overhauled this into the ability to purchase supporter packs (change). These supporter packs will let you download resource bundles with brushes, templates, and more directly inside Krita, as a convenience compared to manually importing them. There is also a subscription, managed through Google Play, which will give access to all of the offered resource bundles.

As with all official store versions of Krita, the money will go towards supporting Krita's development, and none of Krita's features will be locked behind a paywall. Krita on the Google Play store remains free, and offers the same APKs as available on the official website.

Other Features and Fixes

On Android, a prompt to adjust the interface scale will now be shown on first startup, and it can be changed later in Settings → Change Interface Scale. (change by Carsten Hartenfels)

Multiple layers selected with Ctrl+click are no longer deselected when using the Transform Tool (bug; change by Luna Lovecraft). An issue where no layer was selected when deleting the top layer of a document and opening a new view on it was fixed (bug; change by Gregg Jansen van Vuren).

An issue where the buttons of the Selection Actions Bar and Assistant Tool panel could render entirely black, and an issue where Reference Images could cause slowdown, were fixed. (change by Wolthera van Hövell)

Invert Selection no longer selects a larger area than it should. (bug; change by Ricky Ringler)

Crashes went undoing creating a text and then making a new text shape, and when undoing multiple shapes, were fixed. (bug 1, bug 2; change 1, change 2 by Elena Sagalaeva)

A keyboard shortcut assigned to the Rotate or Zoom Canvas canvas inputs no longer crashes when used. (bug; change by Agata Cacko)

Developments in Krita Next

Exporting Recorder Timelapses on Android

Previously, Krita on Android could not render video, as it's not possible to run an external FFmpeg as is done on other platforms.

However, Carsten has found a way to instead use Android's built-in MediaEncoder to render the Recorder's timelapses (change). This is also planned to be implemented for rendering animation in the future.

Other Features and Fixes

Various other features and fixes have made their way into the Unstable builds.

The Wide Gamut Color Selector now has the saved color history feature where the color history is remembered on restart and can be saved into the document. This is part of the effort to make it a replacement for the Advanced Color Selector. (change by Wolthera van Hövell)

The Histogram Docker now scales the histogram based on the maxiumum value, and has a button to show it in logarthimic scale. (change by Wolthera van Hövell)

In the Transform Tool's Free transform mode, holding Ctrl for perspective and then letting go of Ctrl now activates a camera height adjustment mode. (change by Ralek Kolemios)

Future Developments

Testing Needed: Updated Library Dependencies

The team has been working on updating the various libraries Krita depends on for things such as file format support to newer versions. These updated dependencies need testing before they can be merged to the main builds, so check out the library updates forum topic for test packages if you want to help!

Community Report

May 2026 Monthly Art Challenge Results

The winner of the "Animals and Patterns" challenge is…

Magnolia Horse by npc

Join This Month's Art Challenge!

For June's theme, last month's winner has chosen "Something Unexpected", with the optional challenge of using filters.

Featured Artwork

This month's featured forum artwork, as voted in the Best of Krita-Artists - April/May 2026:

Hornet meets the Moss mother by desenhunos

A ruin at night by Alexandre_Perrot

A cursed forest by Alexandre_Perrot

Waterly landscape by usamafirdous

Cherry Blossoms by Aglow

Nominate and Vote For Next Month's Featured Artwork!

Participate in next month's nominations and voting to voice your opinion on the Best of Krita-Artists - May/June 2026.

Krita is Free - But You Can Contribute!

Krita is free to use and modify, but it can only exist with the contributions of the community. A small sponsored team alongside volunteer programmers, artists, writers, testers, translators, and more from across the world keep development going.

If this software has value to you, consider donating to the Krita Development Fund. Or Get Involved and put your skills to use making Krita and its community better!

Additional Changes

Krita Plus (Stable, 5.3.3/6.0.3-prealpha):

File Formats: Fix loading XMP Exif metadata where a rational number field has spaces. When attempting to save XMP Exif with invalid values, omit the invalid values and log a warning instead of failing to save. (bug 1, bug 2; change by Agata Cacko)
General: Add icons for the Getting Started, User Community, Krita Website, Source Code, and Switch Application Language actions (change 1, change 2 by Arkady Flury)
HDR: Animation: Use non-constant luminance coefficients so FFmpeg >=7 will render HDR animations. (bug; change by Wolthera van Hövell)
Android: Support stylus barrel rotation. (change by Carsten Hartenfels)

Krita Next (Unstable, 5.4.0/6.1.0-prealpha):

Comic Panel Editing Tool: Close all shapes cut with the tool. (change by Agata Cacko)
Selections: Fix moving a vector selection to not convert it to a pixel selection. (change by Luna Lovecraft)
Filters: Fix Wavelet Noise Reducer only applying to the first 512 rows of the image. (change by Sergey Kleimenychev)
General: Fix Image Split with guides being off by one pixel. (bug; change by Aditya Rout)
General: Fix the backup file suffix setting in General->File Handling to be editable. (bug; change by Carsten Hartenfels)
Selection Tools: The option to Move Selected Content was reverted due to bugs, such as making a selection showing the move cursor. (bug; change)

Nightly Builds

These pre-release versions of Krita are built every day.

Note that there are currently no Qt6 builds for Android.

Get the latest bugfixes in Stable Krita Plus (5.3.3/6.0.3 prealpha): Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5

Or test out the latest Experimental features in Krita Next (5.4.0/6.1.0-prealpha). Feedback and bug reports are appreciated!: Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5

Teaching digiKam to Understand You: Natural Language Search with Local LLMs

Srirupa Datta — Sun, 28 Jun 2026 04:33:36 +0000

GSoC 2026 • digiKam • Post 1: Design and Progress

I’ve been hanging around KDE apps since I was a teenager :), so getting to spend another summer inside one feels a bit like coming home. This time it’s digiKam!

Here’s what I want digiKam to do: Let me type “photos of mountains from last summer that I rated highly” into a search box, and have it just… find them. No complex filters, no guessing where to click, just plain English, the way you’d ask a friend who’d been on the trip with you.

That, in one sentence, is my GSoC project: interfacing digiKam’s search engine with an AI-based LLM so you can search your photo collection in natural language. For many users, digiKam’s Advanced Search is a hidden gem, powerful but a little intimidating. By adding natural language support, we’re making it accessible to everyone, from beginners to experts who want to save time. And as someone who’s used KDE apps for years, I loved the idea of bridging the gap between digiKam’s powerful features and the simplicity of just asking for what you want.

I’d recently been deep-diving into transformers, and this project stood out to me as a near-perfect blend: real software development and having to actually understand LLMs, which architectures fit where, when you want an encoder versus a decoder, and how a model behaves once it’s wired into an actual application.

This first post is about the overall design and the progress so far. The more interesting bits about the actual language model: which one, how fast, how accurate, are coming in a second post, so consider this the scene-setting.

(Mild Technical Content Ahead, but I promise to keep the scary parts optional. ;) )

The one idea the whole project rests on

DigiKam already has a powerful Advanced Search feature: a dialog packed with dropdowns for tags, dates, ratings, albums, color labels, and more. It can handle complex queries, but it requires users to know how to navigate it.

So the LLM in my project does NOT search your photos. Let me say that again, because it’s the most important design decision: the model never touches your database, never decides what matches, never invents results. All it does is translate your sentence into the exact same structured query you could have built by clicking the dialog yourself. The model produces an “intent”; digiKam’s existing, trusted search engine does the actual searching.

I like this framing because it keeps the AI firmly in its lane. The LLM is a translator sitting in front of a door that already exists: it’s not a new door, and it definitely isn’t allowed to wander off and make things up. Anything it produces is something a human could have produced by clicking. That’s the safety guarantee, and everything in the pipeline is built to enforce it.

The Pipeline in Action

Here’s the journey your query takes:

Your sentence
|
v
[ Prompt Builder ] : wraps it with format instructions
|
v
[ Language Backend ] : runs the model, returns raw output
|
v
[ Intent Parser ] : validates strictly; rejects anything malformed
|
v
[ Capability Dictionary ] : maps human words to digiKam's real fields
|
v
[ Intent Resolver ] : builds concrete search criteria
|
v
Advanced Search widgets populated —> digiKam runs the search

Walking through it:

You type a sentence.
A prompt builder wraps it in instructions that tell the model exactly what format to answer in.
A language backend runs the model and gets back its answer.
An intent parser reads that answer and crucially validates it strictly. The model’s output is never trusted directly. If it isn’t well-formed and doesn’t match the known fields and operators, it’s rejected outright. No partial guessing.
A capability dictionary maps fuzzy human words to digiKam’s real fields: “best” might mean a high rating or an “Accepted” pick label, “colour label” maps to the actual colour-label field, and so on.
An intent resolver turns the validated, mapped intent into concrete search criteria.
Those criteria populate the Advanced Search widgets, and digiKam runs the search exactly as if you’d filled them in by hand.

The nice consequence of splitting it up this way is that the model can be as small and dumb as we like, every layer after it is busy double-checking its homework. If the model says something nonsensical, the parser catches it. If it names a field that doesn’t exist, the dictionary won’t map it. By the time anything reaches your database, it’s been laundered through several layers of “is this actually a thing digiKam can do?”

Why Local Models?

A quick but important detour. The model runs locally on your own machine, not in some company’s cloud. Running the model locally isn’t just about performance - it’s about privacy.

And privacy matters more here than it might first appear. Think about what’s actually in a photo library: where you live, who your family and friends are, where you travelled and when, the inside of your home, your children, the events that matter to you. A photo collection is one of the most personal things a person keeps on a computer. And the searches you run over it are revealing in their own right, the words you’d type to find a photo say something about what you’re looking for and why.

If any of that were sent off to a remote server to be processed, you’d be trusting a third party with exactly the information most people would least want to hand over. Running everything on-device sidesteps that entirely: your photos never leave your machine, your queries never leave your machine, and there’s no account, no API key, and no internet connection required. The feature works the same on a plane as it does at home.

The catch is that a local model is a big file you have to get onto people’s computers somehow which brings me to the part I spent most of this period actually building.

Plugging into digiKam’s Infrastructure

C++ has been my favourite language since my teens, and one of the quiet pleasures of this project has been getting to brush up on it properly. Qt, though, is a different story and a familiar one if you’ve read my Krita posts. Every term I spend with Qt I learn a little more, and every term I’m reminded that it’s one of the harder frameworks to get comfortable in, precisely because it leans so heavily on design patterns. You don’t really “learn Qt” so much as slowly stop being surprised by it.

When I first thought about “the model needs to be downloaded onto the user’s computer,” my instinct was to just write something that downloads a file. Simple enough. But that instinct was wrong. digiKam already knows how to download large model files. It’s been doing it for years, for face recognition, object detection, auto-rotation, aesthetics scoring. There’s a whole system for it: a central DNNModelManager that reads a config file describing each model, and a FilesDownloader that fetches the files from KDE’s servers and verifies them. My mentor’s guidance was clear and correct: don’t build a parallel download mechanism, plug into this one.

The wrinkle is that this entire system was built for OpenCV vision models - models that look at images. My model is a language model run by a completely different library (llama.cpp). It’s a different kind of beast that doesn’t fit the OpenCV machinery at all.

The solution turned out to be pleasingly modular. By creating a lightweight DNNModelNaturalLanguage class, I was able to plug into digiKam’s existing model download system without modifying its core logic. This means the GGUF file is downloaded, verified, and managed just like digiKam’s other AI models (e.g., for face recognition). There’s an existing model type in digiKam (DNNModelConfig) that registers and verifies a file but does no OpenCV loading and that was almost exactly the shape I needed, so my wrapper mirrors it. The actual loading and running of the model happens separately, in a SearchLlamaBackend that talks to llama.cpp.

So the division of labour is clean: digiKam’s existing system handles getting the file onto your computer (download, checksum, the works), and my llama.cpp backend handles running it. No duplication, and my model gets to ride the same well-tested rails as every other model in digiKam.

Why Qwen2.5-1.5B-Instruct

A word on the model itself (much more in post two). I went with Qwen2.5-1.5B-Instruct, in a quantized GGUF form, for a few reasons:

Size vs. capability. At ~1.12 GB (Q4_K_M quantization) it’s small enough to download and run on a normal laptop, but the 1.5B-Instruct variant is genuinely good at following instructions and producing structured JSON, which is exactly what I need it to do.
It’s good at the specific job. This project lives or dies on the model reliably emitting clean, parseable, schema-shaped output. Qwen2.5 is notably solid at structured outputs.
The licence. It’s Apache 2.0, so it’s freely redistributable, which means KDE can actually host the file on its own infrastructure. Why a decoder-only model (and not BERT)

Before picking a specific model, I had to pick a kind of model and this is one of the places my transformers reading actually paid off, so indulge me for a paragraph.

The obvious-seeming choice for “understand a sentence and classify it” is an encoder model like BERT. Encoders are efficient, deterministic, and great at fixed-label tasks. But they assume a finite, predefined output space and that’s exactly what search queries don’t have. A query can express any number of constraints (“landscape photos with red labels near Paris last summer” is four constraints at once), and I’ll keep adding new searchable dimensions over time. To force that into an encoder, I’d need a pile of auxiliary pieces: intent classifiers, entity extractors, rule-based combiners and that scaffolding gets more brittle every time digiKam gains a new search field.

A decoder-only model sidesteps all of that. It generates a sequence, so it can emit a variable number of structured constraints directly as JSON, following a schema I define in the prompt. New search field? Update the schema and no retraining. And it handles ambiguity gracefully: instead of being forced to pick one interpretation of “best photos,” it can emit a clarification request inside the same constrained output. (Encoder-decoder models like T5 could generate structured output too, but they carry extra architectural and latency overhead that’s wasteful for a local, on-demand desktop feature.)

So the short version: a small decoder-only model gives me compositional, schema-shaped generation with built-in ambiguity handling, at a size that runs on a laptop. That’s the whole wishlist.

All assuming 4-bit (Q4) quantization in GGUF form, which is the standard for CPU inference with llama.cpp:

Model	Params	Size (Q4)	Licence	Notes
Qwen2.5-1.5B-Instruct	1.5B	~0.9–1.2 GB	Apache 2.0	Balanced quality/efficiency, good structured output, long context — my primary
TinyLlama 1.1B	1.1B	~0.7–0.9 GB	Apache 2.0	Lightest, fast CPU inference — fallback for low-RAM machines
Gemma 2B Instruct	2B	~1.3–1.6 GB	(Gemma terms)	Strong general language understanding
Phi-2	2.7B	~1.5–1.8 GB	MIT	Better reasoning than 1B models, heavier CPU load
Qwen2.5-3B-Instruct	3B	~1.8–2.2 GB	Apache 2.0	More capable than 1.5B, but higher RAM
Phi-3 Mini	3.8B	~2.2–2.6 GB	MIT	Best comprehension here, but slowest and largest

The pattern is a straightforward size-vs-capability trade-off. The bigger models (Phi-3 Mini, Qwen2.5-3B) reason better but want more RAM and run slower on a CPU-only laptop and since this feature has to stay usable on ordinary hardware without a dedicated GPU, “runs comfortably in ~1 GB of RAM” is a hard constraint, not a preference. That rules the heavier models out for the default.

Among the lightweight options, Qwen2.5-1.5B-Instruct hits the sweet spot: small enough for a CPU laptop, but notably reliable at the one thing this project actually needs: emitting clean, schema-shaped structured output. TinyLlama 1.1B stays in the picture as a fallback for lower-end machines where even 1.5B is too much. Both are Apache 2.0, which (as above) is what makes KDE hosting possible, a point that quietly eliminated some otherwise-tempting models with restrictive licences.

Where things stand

The pipeline already works end-to-end using a mock backend (standing in for the real model). So, prompt > parse > resolve > populate-the-search-and-run is all functioning and unit-tested. And the download integration I described above is in place: the model is registered with digiKam’s central manager, and I’ve verified it gets picked up correctly and its file path resolves to the shared model directory.

What’s Next?

Host the GGUF model on KDE’s infrastructure (in progress).
Wire up llama.cpp for local inference.
Benchmark Qwen2.5 vs. TinyLlama on digiKam-specific queries (e.g., “5-star photos”, “pick label accepted”).
Dive into model performance, fine-tuning, and caching!

Found an excuse to start drawing again :)

XDG Desktop Portal Location API for KDE applications

Volker Krause — Sat, 27 Jun 2026 06:00:00 +0000

In my last post on Android platform integration I had suggested increasing the focus on Linux on mobile phones, due to Google’s ongoing attempts to close down Android for us. I have to follow that myself then of course, starting with looking at the situation around location/positioning.

What we have

The positioning stack looks roughly as follows as far as KDE applications are concerned:

Geoclue collects positioning data from various sources (GNSS receiver, cell modem, online service, etc) and provides a D-Bus API for it.
XDG Desktop Portal has a Location API for exposing this to sandboxed applications, including permission handling. XDG Desktop Portal itself uses Geoclue as its source.
Qt Positioning provides the application-facing API for retrieving position data, and QLocationPermission provides the API for requesting permissions when running sandboxed.

There’s two main gaps here though:

Qt Positioning only has a Geoclue backend, not one for the XDG Desktop Portal Location API. This means we wont have access to positioning information in a sandbox.
Qt’s entire permission API has only a dummy implementation on Linux, meaning it will always claim all permissions have been granted, which isn’t true in a sandbox.

What I couldn’t look into is whether Geoclue is able to actually retrieve GNSS data on “real” hardware, lacking access to devices to test this on.

Developer Tooling

Testing GNSS code with real hardware is rather inconvenient anyway, you have to move around for this, and quite a bit even when you also want to test various edge cases. Much better would be a way to inject arbitrary GNSS data low enough in the stack.

Many years ago I had built something like this for GammaRay, but that works on the level of Qt Positioning, which is above the parts we want to test here. Fortunately Geoclue offers us a way to do this as well. It’s looking for _nmea-0183._tcp mDNS services that provide a NMEA 0183 feed, and will use that as a source for GNSS data.

NMEA 0183 is a decades-old serial port protocol for GNSS equipment, easy enough to implement. As there are more usecases for this below, there’s now a small library setting up such a services, announcing it via mDNS and sending NMEA 0183 messages. NMEA 0183 defines two dozen or so different message types, but since Geoclue only looks at GGA and RMC ones those are all we need.

XDG portal location spoofing tool.

Then all we need is a little GUI on top of this to select inputs on a map and have that fed into Geoclue. As a bonus we also have GPX track replay, so you can get a continuous feed of position updates automatically. The code is here.

XDG Portal plugin for Qt Positioning

Being able to “move” around the world from the convenience of my desk/couch made it then easy to implement the main missing piece here, connecting Qt Positioning to the XDG Desktop Portal Location API. The code is here, it’s just a couple of D-Bus calls and a bit of boilerplate needed for positioning plugins.

It’s registered with a higher priority than the Geoclue plugin and will be skipped if the portal API is not available.

QPermission API

That still leaves the permission handling. Qt’s API for that lives in Qt Core, so we cannot just implement support for XDG protal permissions there, as that needs dependencies from higher up in the stack, such as D-Bus and window ids.

There’s an easy way out though, by generalizing an already existing permission plugin system that so far is only provided on Apple platforms. A patch to Qt enabling this on Unix systems as well is in review currently. With that applied implementing support for requesting location permissions is then very similar to what the positioning plugin already does, you’ll find the code here.

A very convenient side-effect of having permission plugins is that we can now also build a “simulator” that allows testing permission flows in applications while running in an unrestricted development environment and without having to mess with system permission settings each time.

So I did that here, usage is pretty simple:

$ qpermission-simulator [--ask|--grant|--deny] <application-to-test>

Note that this also needs the above mentioned Qt patch to actually do anything, and it currently requires the tested application to be a QApplication in order to show its UI. It does work for all permission types supported by Qt though, not just the location one.

Other positioning sources

One unique feature that microG offers on Google-free Android is using onboard APIs of planes/trains/buses as a location source. That’s useful as the GNSS antennas of those vehicles tend to give you much better results than the one on your phone inside the metal casing of the vehicle.

Of course we have to have that as well, and it’s easy enough to build that since we have an existing library for dealing with onboard APIs already as part of KPublicTransport.

Putting that together with the NMEA 0183 server we get a small KDED module that watches for changes to the Wi-Fi network you are connected to, and if it’s one of a known onboard API it’ll offer its service to Geoclue. As Geoclue will only connect to it on demand (ie. when an application actually asks for a location) it will only poll the onboard API when necessary, so we also get practically no overhead in the idle state here.

Other sources are possible in a similar way as well, e.g. having KDE Connect provide location data from your phone to your desktop computer.

Feedback

This is mostly the result of about two weeks of prototyping, and I’d very much appreciate review and feedback on this. Does the general approach make sense? Is there something else missing around the the location/position topic? Where should the various components live and be distributed eventually (some of this only really relevant inside a Flatpak sandbox fox example)?

This Week in Plasma: Post-6.7 Bug-fixing

Nate Graham — Sat, 27 Jun 2026 00:00:01 +0000

Welcome to a new issue of This Week in Plasma!

This week members of the core Plasma team spent almost all of their time in bug-fixing mode! As usual, people unleashed their real-world setups on the new Plasma release and found some issues we missed during the development process, and that nobody reported during the two beta releases. So we made it a priority to fix those issues!

Plasma 6.7.1 was released earlier this week with the first round of fixes, and 6.7.2 is scheduled for early next week with more.

A few new features and UI improvements started landing, too.

Check it out here:

Notable new features

Plasma 6.8

You can now set up wallpaper slideshows that don’t change automatically. Instead you can manually switch the wallpaper via the item in the desktop context menu or its global keyboard shortcut. (Fushan Wen, KDE Bugzilla #518669)

Added an Esperanto keyboard layout to Plasma’s virtual keyboard. (Daniel O’Neill, plasma-keyboard MR #148)

Notable UI improvements

Plasma 6.7.2

Improved text alignment in System Monitor’s Processes page while using the tree view. (Arjen Hiemstra, KDE Bugzilla #442095)

Plasma 6.8

Reduced the number of visual frames in the Menu Editor app. (Levi Leal, kmenuedit MR #59)

Notable bug fixes

Plasma 6.6.6

Fixed an issue that could make KWin crash when some apps opened dialogs and popups in non-standard ways. (Vlad Zahorodnii, kwin MR #9444)

Fixed a regression introduced by Qt 6.11 that made the word “Undefined” appear next to Places entries in the Kickoff Application Launcher widget. (Christoph Wolk, KDE Bugzilla #521799)

Fixed a visual glitch affecting users of Deskflow that could make a clone of the pointer inappropriately remain visible on the client machine. (David Redondo, KDE Bugzilla #521486)

Plasma 6.7.1

Fixed a somewhat common case where KWin could crash on the lock screen when using an NVIDIA GPU. (Xaver Hugl, KDE Bugzilla #520842)

Fixed a recent regression that made KWin crash when using a DisplayLink monitor. (Xaver Hugl, KDE Bugzilla #520361)

Fixed an issue that could make screens plugged into a laptop with both an NVIDIA and an AMD GPU freeze. (Xaver Hugl and SungHwan Jung, KDE Bugzilla #521727)

Fixed a recent regression that broke certain shader-based KWin effects, including the popular “Burn My Windows” effects. (Xaver Hugl, KDE Bugzilla #521774)

Fixed a recent regression that broke color-related KWin effects like color blindness correction and screen color inversion. (Xaver Hugl, KDE Bugzilla #521737)

Plasma 6.7.2

Fixed the currently most common KWin crash, related to variable refresh rates with multi-monitor setups. (Vlad Zahorodnii, KDE Bugzilla #521909)

Fixed a case where Info Center could crash when trying to display information about certain NVIDIA GPUs. (Harald Sitter, KDE Bugzilla #521295)

Fixed a recent regression that broke the RDP server when run using systemd. Sorry about that! (David Edmundson, KDE Bugzilla #521776)

Fixed a recent regression that could sometimes make Chromium-based apps freeze if another window was forced into “Keep Above Others” mode. (Xaver Hugl, KDE Bugzilla #521687)

Plasma 6.8

Fixed a case where Plasma could crash after you ejected an audio CD from Dolphin or Audex. (Kai Uwe Broulik, KDE Bugzilla #522051)

Flatpak 1.18.1

Fixed an issue that made a background service for Flatpak crash if you used the KDE desktop portal dialog to allow an app to update itself while the app was still running. (Sebastian Wick, flatpak issue #6686)

GTK 4.23.2

Made the process of selecting text to later paste it by middle-clicking more reliable in GTK 4 apps. (Vlad Zahorodnii, gtk MR #10006)

Notable in performance & technical

Plasma 6.7.2

Improved full-screen video playback performance in Chromium-based apps. (Xaver Hugl, KDE Bugzilla #521960)

Plasma 6.8

Turned on triple buffering by default for NVIDIA GPUs, because the bugs blocking this from working properly in the past have since been fixed. (Xaver Hugl, kwin MR #9472)

How you can help

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

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

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

Techpaladin is hiring again

Nate Graham — Fri, 26 Jun 2026 14:30:39 +0000

Time to put on my Techpaladin Software had again: we’re hiring! David Edmundson has already posted it, so I’m here to boost the signal: we need you! Especially if you’ve got experience with Qt/KDE development.

We’re looking for someone with that plus an eye for UX & design, and another person with that plus deep tech skills, particularly around I/O and other “system plumbing” topics.

Check it out: https://techpaladinsoftware.com/joinus.html

Submit a KDE goal!

Nate Graham — Fri, 26 Jun 2026 14:13:22 +0000

KDE has now started its fifth round of “goal-setting” — a process that began in 2017.

These goals are big, high-level goals. Think “focus on large strategic topic X” more so than “fix my pet bugs A, B, and C”.

And it’s up to the KDE community to choose the goals! Up to you, up to me, up to all of us. They will then be voted on, with the top three informing KDE’s overall direction for the next two years.

KDE needs you! Your fresh ideas, your contributions, your budding leadership talent. But not your imposter-syndrome-driven fear of coming out of your shell. Overcome that!

I’ve now been the champion for two goals: “Usability & Productivity” and “Automate & Systematize Internal Processes“. I’d count the first as pretty successful; the second, less so. So at this point I feel like I have a pretty good idea of what works and what doesn’t, and I’d like to use that knowledge to help others submit their own high-quality actionable goals.

Here’s what works, in my experience:

Articulate an immediately obvious large problem or aspiration. If you’ve spent any time in KDE or using KDE software, you’ll have encountered stuff that could be better. Big stuff. That’s the topic to write a goal around! Not “Discover is too slow to refresh when I launch it” but rather “First-class software delivery UX” (you can steal that).
Have a technical lead and a communications lead. They can be different people, but you need both. Only have a tech lead? Not enough communication, people forget about it, don’t join, and the tech lead burns out. Only have a comms lead? Not enough work happens and the goal limps embarrassingly towards the finish line.
If you propose a goal, be the tech lead. You can be the comms lead too. But you should be prepared to be the tech lead. It’s much easier to recruit people to do other things than it is to recruit a tech lead to do a ton of work on your behalf that you can’t to yourself.
Don’t bite off more than you can chew. If you can’t be the tech lead on your idea, scale it back or change its scope so that you can be the tech lead. This doesn’t mean you have to know how to do everything. It just means you can do a big chunk of the technical work, and at least understand the concepts of the things you can’t personally do.

It’s really fun, and you end up having a huge impact on how awesome KDE is.

I’ve submitted a goal proposal about improving KDE’s documentation. Credible choices make voting useful, but right now we have as many submissions as goal slots, and that’s no fun. So get yours in too!

Techpaladin are hiring!

David Edmundson — Fri, 26 Jun 2026 11:33:55 +0000

If you've been around KDE, you've probably heard of Techpaladin Software

We're a consultancy that works almost exclusively on KDE, improving KDE upstream while delivering the features and functionality our clients need.

We're growing and looking for more developers to join the team. We're after experienced developers who are already familiar with KDE, C++, and Qt.

We currently have two positions available:

Someone with a keen eye for design to work on high-level features and help shape the user experience.
Someone with a more technical background to work on lower-level system integration and platform work.

In return, you'll get to work with some of the most talented and welcoming developers in this space... and also me!

If that sounds interesting, you can find more information and apply here:
https://techpaladinsoftware.com/joinus.html

KEcoLab Sprint: Two Days in Berlin

Karanjot Singh — Fri, 26 Jun 2026 10:00:00 +0000

KDE Eco organized a two-day sprint to work on KEcoLab — the energy measurement lab I maintain. A few more people came and joined on day two, which made the discussions richer. The sprint was mostly about figuring out the next steps for KEcoLab, fixing some open issues with the measurement pipeline, and trying to get a second system set up in the lab. You can find the full sprint notes here.

Thanks to KDE e.V. for sponsoring the sprint, KDAB for hosting us at their Berlin office, and Volker for the guidance and support throughout.

Headless Remote Access

The first thing we wanted to sort out was making the lab PC fully remotely accessible, which means we could use it without having someone physically in the room to debug our issues with the lab PC. SSH was already working fine, but RDP was not very reliable (it used to break sometimes). Nowadays, We had to go to the lab PC in person once to allow remote connections, which is exactly the kind of thing you do not want to do repeatedly. During the sprint, we applied a fix using flatpak permission-set to persist screen capture permissions across reboots, based on a recently merged patch (plasma/xdg-desktop-portal-kde!326).

However, the issue is not fully closed. A couple of days after the sprint, the problem came back and it was not clear what had changed. We had a follow-up meeting to discuss this, notes here. Joseph and Volker are currently testing different approaches to figure out how to properly persist the session across reboots. We will update this once we have a reliable fix.

Setting Up a Second Machine

Cornelius Schumacher donated a Fujitsu Esprimo 510 to the lab for us to add as a second System Under Test. It did not go well. The machine threw six beeps on boot, which pointed to a CPU or motherboard problem, most likely a BIOS flash failure. We tried reseating the RAM, resetting the CMOS battery, testing each RAM stick one by one. Nothing changed. The machine is not usable, but we are keeping the hardware for spare parts.

Debugging the Okular Pipeline

We ran the full Okular measurement pipeline on Wayland and hit a few problems. On day two, we saw an R error about non-numeric data. When we looked into it, the collectl files had data from pipeline runs we had stopped earlier, stopping a pipeline mid-run was causing the next run to append data to existing files, which broke the statistical analysis. We now have issues open to fix this properly:

Kill pipeline: #64
Failsafe for pipeline failure: #18
Cancel SUS script: #16

A cleanup stage has since been added to the pipeline to handle this — see !152.

The reports also had wrong durations and missing averages. That turned out to be missing stopActions in the ydotool scripts. Once we fixed those, the numbers looked reasonable. Joseph is continuing to work on this and will follow up on the remaining open questions.

There is also a broader question about the data itself. Our power draw results look very different from measurements taken at Umwelt Campus Birkenfeld back in 2022. Their data showed distinct power draw phases across tasks, while ours is mostly flat apart from the spike when Okular opens. It could be Wayland versus X11, Flatpak versus a repo package, or just Fedora versus Ubuntu. Probably a mix of all of them. Something to investigate.

Future Planning

We went through the open issues and talked about what comes next, integrating KEcoLab into a broader KDE Plasma testing workflow, planning for the Akademy BoF, and ideas around extending ydotool/kdotool to make measurement scripts more flexible. We did not get through everything but the direction is clearer now.

Outside the Lab

After the first day, Carl, Aakarsh, Joseph, and I headed to Tempelhofer Feld. It was a warm evening and the field was full of people cycling, skating, and just sitting around. We walked around for a while and talked about everything except KEcoLab, which was exactly what we needed. A big thank you to Carl and Joseph for showing us around, Berlin has a way of making you feel like you have all the time in the world, even when you have a pipeline to fix in the morning.

Not everything worked, but we came away knowing exactly what needs to be fixed and why. That is usually what a good sprint looks like.

Tempelhofer Feld