fidzu : KDE

Last weekend I joined an in-person workshop at HTW Berlin for discussing topics around mapping indoor spaces in OpenStreetMap.

Indoor mapping

Mapping indoor spaces is a somewhat niche topic in the OSM community still, but something that is quite relevant for projects I'm involved in:

• Transitous, for routing transfers through train stations.
• Itinerary, for displaying detailed maps of train stations or airports.
• Kongress, for venue maps for conferences as described here.

The term "indoor" isn't strictly referring to "in a building" here, there's many gray areas e.g. at train stations. What's usually more important is that this introduces a third dimension into the originally mostly two-dimensional OSM data. Another challenge is the need for a very high level of detail, for wheelchair routing every single step matters for example.

Since the last workshop four years ago we had quarterly online meetups to discuss modeling and tagging questions, but for some topics an hour or two in an online meeting is just not enough to properly cover this, it needs locking people in a room for a day or two instead.

Balancing requirements

While it's often not hard to find a solution for a modeling problem at hand, finding one that works well for all use-cases is hard:

• Easy to explain, use and maintain. Don't require deep domain knowledge of railway operations or civil engineering for mapping.
• (Backward) compatible with existing data and existing semantics. OSM is a database with billions of objects built up over more than two decades, with countless users.
• Usable for 2D rendering.
• Usable for 2.5D or 3D rendering. This specifically benefits from a higher spatial resolution in the third dimension (which currently is essentially floor levels, compared to the centimeter resolution in the other dimensions), but also from the ability to map visuals of vertical features.
• Usable for tactile rendering. This one is challenging as it's actively harmed by a higher level of detail. On dynamic tactile displays you have to work with as little as 100 "pixels" in each direction, and possibly just one 1 bit of "pixel depth", which requires very aggressive abstraction and simplification. 3D printed tactile maps have a higher spatial resolution and allow for some basic textures and symbols, but still way below the options you have with a visual display.
• Usable for routing, both with graph-based and area-based algorithms. The main challenge here is completeness of the data, every barrier has to be there to avoid the router taking clever shortcuts.
• Being able to model all accessibility-relevant properties. See the discussion on directional door attributes below, for example.
• Compatibility for importing BIM data, ie. digital engineering models of buildings. That's on the extreme end of the level of detail usually, and needs to be significantly reduced/simplified. But it's an attractive source of high quality building geometries for say an entire university campus.

Fortunately we had people familiar with all those aspects present at the workshop, which helps to avoid easy one-sided compromises.

What even is a door?

There's detailed notes on the discussion in the wiki, I'll just pick one topic here to show how even seemingly easy and obvious things are surprisingly complicated when digging into the details, doors.

• Is a door frame with the actual door removed still a door?
• Is a multi-segment foldable door as e.g. found in shop fronts or between conference rooms a door? If so, does that mean doors can contain doors?
• Doors are 0-dimensional features (ie. points) in OSM. That's a useful simplification, but how do we define directional attributes in that case, e.g. in which direction does the door open?
• Inside/outside is an intuitive way to do that, but that fails in more complex buildings. It would also mean evaluating door attributes requires determining an "inner-ness" hierarchy of all areas in a building, extremely unwieldy, if that would even be well-defined.
• Modeling doors as 1-dimensional features (ie. lines) brings in an inherent direction, but that is perpendicular to the intuitive direction of standing in front of a door, requiring some mental gymnastics to make this work ("I am the door").

This might seem pointlessly abstract and theoretical, but for e.g. wheelchair routing this is quite relevant. The opening mechanism and opening direction of a door have quite some impact on how easily you can get through.

Outlook

Indoor mapping will probably also be a topic at State of the Map 2026 in a few weeks in Paris. I'll be speaking about Transitous there, one of the consumers of this data.

18 Jul 2026 6:30am GMT

I spent the last 2 weeks mostly on fixing the bugs that were breaking font subsetting for annotations.

One such bug was about deleting the original font which we talked about in the last blog.
And there were some more edge-cases and type bugs.

For eg: An object could be a ref but I directly do obj->getStream() instead of obj.fetch(xref).getStream() which crashed the code.

I spent 3-4 days on writing some tests for the font subsetting. I just test 2 things for now.

1. Single annotation test: Here we test if subsetting behaves well for a single annotation. We load a file, add an annotation, save it, re-open it, and check if the annotation is using a properly subsetted font which has glyphs only for the characters we added.

2. Linked annotation test: We try to check if subsetting for a particular annotation leaves all the other annotations intact. So, we load a PDF file which has 2 annotations that use the same font, modify the 1st annotation, save and re-open, check if the subsetting works well for the 1st annotation, and check if the font binary data for the 2nd annotation is intact.

These tests required approximately 400 lines of code which is slightly surprising. This is almost the same amount of code as the subsetting logic in FontSubsetter.cc

I also used core poppler code for these tests and not an API like poppler-qt5 or poppler-qt6 because I needed a lot more control to test these things.

I also switched from Vim + terminal coding workflow to QtCreator. This was basically because I am not very good at GDB right now and wanted a visual debugger to make work easier. Switching to CLion just for it's debugger felt weird.

So I started using QtCreator and it feels okayish right now. I use it with it's FakeVim plugin.

Now, I need to work on:

1. The extra font bug in poppler: Basically, when poppler tries adding fonts for a text, it seems to be including an extra wasteful font such as Cantarell in my case. I need to investigate why this happens.

2. Make our own splitTextByFont: Right now, I just save the font-string mappings when the AP stream is generated in an annotation. This ensures consistency between what is being written to the AP stream and what is visible to the subsetter.
   However, this is not very good both performance-wise and code-wise. We store the mappings for annotations that we might never subset. And it requires change in the internal code.
   Therefore, I have to create my own splitTextByFont function inside my FontSubsetter class which takes the font and returns the appropriate font-string map.
   We need to be careful that we don't cause inconsistencies between what's visible to the subsetter and what actually gets added to the AP stream because that might cause rendering issues.

3. Fixing more bugs: Because bugs never end in moving software, do they?

Thanks for reading! Have a great day ☺️

18 Jul 2026 4:01am GMT

Welcome to a new issue of This Week in Plasma!

This week the bug-fixing spree of the past few weeks wound down as feature work and user interface polishing moved into the foreground. So let's start out with something pretty darn user-visible:

Notable new features

Plasma 6.8

KWin now automatically applies a shadow, outline, and corner rounding effect to client-side-decorated windows that lack these - such as Steam and Discord windows. Read more about this on Vlad's blog! (Vlad Zahorodnii, kwin MR #9147, kwin MR #9566, breeze MR #612, and kdecoration MR #93)

You can now assign processes to specific CPUs or groups of CPUs in System Monitor, known as setting CPU affinity. (Taras Oleksyn, KDE Bugzilla #429151)

The Task Manager widget now has global shortcuts for re-arranging tasks and switching between them. (Salman Farooq, plasma-desktop MR #3819)

Notable UI improvements

Plasma 6.7.4

Apps using the global shortcuts portal are now allowed to rename their shortcuts by requesting to re-register them. (David Redondo, KDE Bugzilla #523063)

Plasma 6.8

System Settings' Window Behavior page has been ported to QML and modernized a bit in the process, bringing it up to par with most other pages in System Settings. (Tobias Ozór, kwin MR #9370)

Notable bug fixes

Plasma 6.6.7

System Settings' Effects page now behaves properly for KWin effects whose default values have been overridden at the distribution level. (Nicolas Fella, kwin MR #8112)

Plasma 6.7.3

Fixed a recent regression that made the ksystemstats process sometimes crash when the system woke from sleep. (Iyán Méndez Veiga, KDE Bugzilla #521353)

Fixed a recent regression that caused lag and stuttering on certain websites using hardware-accelerated rendering for systems using certain GPUs. (Xaver Hugl, KDE Bugzilla #521742)

Fixed a weird issue that made the system stop sleeping according to the normal schedule if you interrupted certain monitors while they were right in the middle of shutting down. (Ameen Al-Asady, KDE Bugzilla #523001)

Plasma 6.7.4

Fixed a somewhat common way that Discover could crash while installing updates. (Aleix Pol Gonzalez, KDE Bugzilla #522255)

The bandwidth usage reported by Plasma's remote desktop server is now accurate. (Liu Jie, krdp MR #216)

Fixed a layout glitch on System Settings' Pointers page that prevented some pointer size options from being fully visible when using screen scaling. (Akseli Lahtinen, KDE Bugzilla #521187)

Fixed two layout glitches in Discover when using the app with multiple backends and looking at large items on the Installed page. (Nate Graham, discover MR #1357 and discover MR #1358)

The "Typing on the desktop activates KRunner" setting is now fully respected for Folder View widgets placed on the desktop, in addition to the embedded Folder View that is the desktop. (Christoph Wolk, KDE Bugzilla #523053)

Plasma 6.8

Fixed some positioning and theme compatibility issues with drop-down menus in Plasma and its widgets. (Filip Fila, libplasma MR #1546)

Notable in performance & technical

Frameworks 6.29

Reduced Plasma's memory usage a little bit. (Nicolas Fella, ksvg MR #113 and kguiaddons MR #224)

KDE Gear 26.12

System Settings' Connection Preferences page has been removed. Its settings were extremely esoteric and they applied to almost nothing these days, so the page was mostly just cluttering the place up. (Tobias Fella, kio-extras MR #533)

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.

18 Jul 2026 12:00am GMT

Let's go for my web review for the week 2026-29.

A Better World

Tags: funny, history, scifi

Interesting game. Want to make your own alternate history? Gives pause about what we assume of the past. It stays fun of course.

https://abw.blue/index_en.php

This is Still Not Normal

Tags: climate, europe

Those maps make things very clear regarding climate change in Europe… and concerning to say the least.

https://googlemapsmania.blogspot.com/2026/07/this-is-still-not-normal.html?m=1

The Lost Joy of Music Piracy: WhatCD, Oink, and Spotify

Tags: tech, internet, music, piracy, culture, history

Excellent article which gives a glimpse of the Internet culture around music in the late 90s to roughly 2010. It was called piracy but clearly it was a labor of love… the movement kind of faded but artists don't see much money back. It was a fight for nothing, well at least… not to the benefit of the artists.

https://www.pigeonsandplanes.com/read/music-piracy-what-cd-oink-nine-inch-nails-streaming

"Useful" is not sufficient

Tags: tech, ai, machine-learning, copilot, ethics, politics, foss

An illustration of the political and ethical acumen being low in our profession in general and in some (most?) Open Source projects in particular…

https://tante.cc/2026/07/15/useful-is-not-sufficient/

Let's Talk About the Hardware Reckoning

Tags: tech, ai, machine-learning, gpt, copilot, hardware, economics

The hardware prices are nuts right now… and there's no end in sight yet.

https://timemachiner.io/2026/07/16/lets-talk-about-the-hardware-reckoning/

Do Smart Glasses Have a Surveillance Problem?

Tags: tech, facebook, google, surveillance, hardware

Well yes… and hopefully the fashion industry won't be enough to hide it.

https://www.vogue.com/article/do-smart-glasses-have-a-surveillance-problem

AI Surveillance and Social Progress

Tags: tech, ai, machine-learning, surveillance, politics, sociology

Not what I signed up for years ago, but it's the political and social landscape we inherited… Surveillance is being on steroids now, so definitely need to fight it at every turn.

https://www.schneier.com/blog/archives/2026/07/ai-surveillance-and-social-progress.html

Cursor 0day: When Full Disclosure Becomes the Only Protection Left

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

There's clearly an issue with the security and privacy practice of those companies…

https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left

The Memory Heist

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

Those systems based on LLMs really create crazy security issues as soon as they're allowed to interact with other systems.

https://www.ayush.digital/blog/the-memory-heist

An update on the scraper situation

Tags: tech, web, ai, machine-learning, gpt, commons

The web scraper situation isn't getting better… How long can the open web still hold?

https://lwn.net/SubscriberLink/1080822/990a8a5e2d379085/

InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation

Tags: tech, graphics, simulation, generator

Nifty new approach for infinite terrain generation. This is really impressive work.

https://xandergos.github.io/terrain-diffusion/

The git history command deserves more attention

Tags: tech, git, version-control

It's definitely bringing nice moves now. It deserves to be used more indeed.

https://lalitm.com/post/git-history/

Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK

Tags: tech, graphics, linux, wayland, x11, performance

More latency exploration on Linux for games. The results are interesting. Unsurprisingly the X11 vs Wayland difference is much less dramatic than what people make of it.

https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/

Debugging performance regressions

Tags: tech, nix, guix, reproducibility, debugging, system

Declarative systems like Nix and Guix bring their own set of complexities and challenges. That said, they also bring very interesting properties in terms of full system reproducibility. It can be a real help for integration work.

https://hpc.guix.info/blog/2026/07/debugging-performance-regressions/

Where did my segfault go?

Tags: tech, unix, shell, system

If you ever wondered what is responsible for printing the "core dumped" message, here is your answer.

https://rmpr.xyz/Where-did-my-segfault-go/

Detecting Full Table Scans With SQLite

Tags: tech, databases, sqlite, optimisation, performance

Interesting trick to detect table scans with SQLite. I can see that useful in development to optimize systems.

https://tenderlovemaking.com/2026/07/15/detecting-full-table-scans-with-sqlite/

The Order of Data: defaults, performance, determinism & paging

Tags: tech, databases, performance, reliability

Or how to properly paginate results when you have a database.

https://binaryigor.com/the-order-of-data.html

Understanding the Rust hype for the busy developer

Tags: tech, rust, ecosystem, supply-chain

A nicely balanced view at Rust the language but also the ecosystem. It's not all pretty and real issues are looming.

https://kerkour.com/rust-hype

Battery packs: Let's talk about crates, baby

Tags: tech, rust, supply-chain

Another attempt at easing the pain navigating the Rust crates ecosystem? It has its merits as well.

https://smallcultfollowing.com/babysteps/blog/2026/07/15/battery-packs/#fnref:1

How Our Rust-to-Zig Rewrite is Going

Tags: tech, rust, zig

While some rewrite from Zig to Rust… others follow the opposite path. This is an interesting read pointing the strengths and weaknesses of both ecosystem. There's no one size fits all in our field so it's important to have this kind of explorations.

https://rtfeldman.com/rust-to-zig

How C++20 improved the for-loop syntax

Tags: tech, c++

C++23 gives us std::ranges::view::enumerate for this particular case now. Still, this is a good illustration of the (too) little used range-based for loop with initializer.

https://lzon.ca/posts/tips/cpp-for-range-init/

C Strings: A 50-Year Mistake

Tags: tech, c, memory

Indeed, this design choice comes with lots of issues. It might have made more sense in the 70s though.

https://longtran2904.substack.com/p/c-strings-a-50-year-mistake

What Every Python Developer Should Know About the CPython ABI

Tags: tech, python, api, abi

A not of a long introduction with generalities about APIs and ABIs. It really gets interesting when it covers the CPython specifics and the challenge they had keeping compatibility at the ABI level. This gives a good idea of the complexities needed to build wheels for Python packages.

https://labs.quansight.org/blog/python-abi-abi3t

Programming Vehicles in Games

Tags: tech, game, physics, simulation

What's in the physics simulation of cars? A lot actually!

https://wassimulator.com/blog/programming/programming_vehicles_in_games.html

How my images are dithered

Tags: tech, graphics

Another fun exploration of dithering techniques. The variety abounds in this domain I think.

https://dead.garden/blog/how-my-images-are-dithered.html

CORS: What is it protecting?

Tags: tech, web, services, browser, security

A neat and simple explanation of what CORS is and which security issues it helps with.

https://sanyamserver.online/posts/cors/

A modern HTTP request

Tags: tech, http

What's in a request nowadays? Well, lot of information!

https://nelsonslog.wordpress.com/2026/07/14/a-modern-http-request/

HTMX and Web Components Instead of React

Tags: tech, web, htmx, framework, complexity, webcomponents, react

I wish more teams would have this kind of thinking an really carry it to its logical conclusion. In most case you don't need an SPA framework.

https://kore-nordmann.de/blog/htmx-and-web-components-instead-of-react.html

What does "playing politics" mean for software engineers?

Tags: tech, leadership, management, organisation, politics

Some of it is probably a bit too cynical (often the case with this author), and yet it has good advice on how software engineers influence the organisation around them.

https://www.seangoedecke.com/playing-politics/

Ownership

Tags: tech, leadership, delegation, quality

Good check list of things to consider when you're delegating something. It's pretty much the expectations from the person who delegate to you.

https://registerspill.thorstenball.com/p/ownership

Life Hacks for Idiots

Tags: life, satire

It's not complicated, just don't be a waste of atoms, m'kay? 😉

https://impossiblesongs.blogspot.com/2026/07/life-hacks-for-idiots.html?m=1

Bye for now!

17 Jul 2026 1:28pm GMT

It's been a long time since I wrote here last time. I would like to share a few details about a feature that I'm really excited about, which landed in KWin recently.

Drop shadows are drawn either by the compositor or the application. For example, a good chunk of GTK applications employ the latter strategy, the drop shadows are drawn on the client side; Qt applications usually ask the compositor to draw a window decoration plus the drop shadow. However, there are also applications that do neither. For the consistency sake, it will be nice if you could force the compositor to add drop shadows for those windows. This is the new feature that will come in the next release of Plasma - 6.8.

For example, consider Discord with the current defaults

It has square corners, there are no drop shadows, the titlebar buttons don't look consistent, etc.

With the new changes, Discord will look as follows

There are still some inconsistency issues, e.g. the close, maximize and minimize buttons don't look consistent, but still, now, Discord blends in better with the rest of Plasma, for example it casts a shadow, it has rounded corners and there is an outline drawn around the window.

How it works

You can already achieve similar visuals in 6.7. In order to do that, you need to create a window rule to force a server-side decoration, and then go to Breeze decoration settings and create a window-specific override to hide the titlebar.

For example, here are the required steps to add a server-side drop shadow around Visual Studio Code in Plasma 6.7

The changes in 6.8 rather automate those steps for you. Unfortunately, it doesn't work with every available decoration in the wild. Decorations need to opt-in to providing only server-side drop shadows.

First, a decoration needs to declare that it supports both shadow-only and titled decorations in the metadata, e.g.

 "org.kde.kdecoration3": {
"styles": ["shadow", "titled"]
}

Then the decoration needs to adjust its visuals based on the value of KDecoration3::Decoration::style(). For example, hide the titlebar, etc.

How to add shadows around windows

If you would like a given window to have a server-side drop shadow, we added a new "Window manager draws titlebar, frame, and shadows" window rule that supersedes the old "No titlebar and frame" rule

Note that KWin will automatically add drop shadows to X11 windows that have neither a server-side decoration nor a client-side drop shadow. No such a thing will be done for Wayland windows though because of sub-surfaces. On Wayland, we may need a protocol to opt-in to such things, in meanwhile, you'll need to use window rules.

Closing words

Anyway, it's a rather quick development update. This is a small thing but I hope that people will find it useful for making their desktops look more eye-candy.

16 Jul 2026 6:45pm GMT

A summary of my three-part analysis of the EU Open Source Strategy on Tagoross. Real strengths, real design flaws. The sovereignty definition does not fit open source. The legislation, CADA and Chips Act 2.0, encourages or stays silent rather than requires.

16 Jul 2026 9:07am GMT

The Akademy 2026 Program is now live!

This year's Akademy will take place in Graz, hosted at the Graz University of Technology, both in person and online.

Akademy starts with a welcome event on Friday, 18 September, followed by two full days of talks on Saturday, 19 and Sunday, 20 September, then four days of dedicated BoFs, workshops, meetings, and training from Monday, 21, through Thursday, 24 September. Expect a community day trip midweek.

The schedule highlights:

• Talks covering What's coming up in Qt, KDE Linux at 2, Beauty in Code, and many more.
• More in-depth sessions on An Agency, A Need of Sovereignty, and KDE's Will to Conquer the Enterprise, Goals wrap-up and reveal of new goals, Are we really doing to use the same Desktop UX forever? and beyond.
• Community-driven workshops and BoFs cultivate collaboration and project momentum throughout the week.

This hybrid event model continues to grow, embracing both onsite attendance and remote participation, allowing contributors from around the globe to connect and engage.

Venue & Registration Details:

• Venue: Graz University of Technology
• In-person + Online: 19-24 September (with the welcome event on 18 September).
• Registration is open and free!
• You can explore the full program on Akademy's website. Stay tuned for our keynote announcement!

15 Jul 2026 7:00am GMT

GSoC 2026 • digiKam • Post 2: Inference, Bugs, and the Build

In my first post, I introduced the goal: type a plain-English search into digiKam and have a local LLM translate it into structured search criteria. That post built the whole pipeline - prompt builder, JSON parser, intent resolver, against a mock backend that returned canned responses, so everything could be tested before a real model was wired in. This post is about swapping that mock for real llama.cpp inference, and everything that broke along the way, which was almost never the model.

At the end of my last post I promised that this one would be about the actual language model: which one, how fast, how accurate. I've been looking forward to writing it.

Here's the thing I did not expect. The model works. It has essentially always worked. Almost every hard problem I hit over the past few weeks lived somewhere else: in a compiler flag, in a JSON type, in a git server's opinions about submodules. This post is the honest version of what it takes to put a language model inside a desktop application, and the honest version is that the language model is the small part.

Actually running the thing

Last time the pipeline ran end-to-end against a mock backend: something that returned canned answers so I could build and test everything around it. Replacing that mock with a real model meant writing SearchLlamaBackend, which loads a quantized Qwen2.5 GGUF through llama.cpp and generates tokens.

Two decisions shaped it.

The first decision was that every single llama_* call happens on a worker thread. Loading a 1 GB model takes a few seconds; generating tokens takes a few more. If any of that ran on the GUI thread, digiKam would freeze every time you searched. So the backend owns a QThread, the worker lives on it, and everything crosses the boundary through queued signals - the UI stays responsive while the model thinks.

Here's the shape of it (simplified from the real method, which has the error handling and tokenization removed for readability):

void SearchLlamaWorker::slotDoInference(const QString& prompt, int maxTokens, float temperature)
{
Q_UNUSED(temperature); // greedy decoding, determinism over creativity
llama_context* const ctx = static_cast<llama_context*>(m_context);
const llama_vocab* const vocab = llama_model_get_vocab(/* ... */);
// Start each query from an empty context.
llama_memory_clear(llama_get_memory(ctx), true);
// Greedy sampler: always pick the single most likely next token.
llama_sampler* smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
llama_sampler_chain_add(smpl, llama_sampler_init_greedy());
QString result;
while (generated < maxTokens)
{
llama_decode(ctx, batch);
const llama_token tok = llama_sampler_sample(smpl, ctx, -1);
if (llama_vocab_is_eog(vocab, tok)) break;
result += /* decoded token text */;
// Stop as soon as the JSON object closes (balanced braces).
if (jsonObjectComplete(result)) break;
}
llama_sampler_free(smpl);
Q_EMIT signalOutputReady(result); // back to the main thread, via a queued signal
}

Two things in there are deliberate. llama_memory_clear at the top wipes the context's KV cache so every query starts fresh - I'll come back to why that one line matters more than it looks. And the sampler is greedy: no temperature, no randomness, the model always takes its single most likely token. That's the opposite of how you'd run an LLM writing prose, where a little randomness keeps it from sounding wooden. But I don't want prose. I want the same query to give the same JSON every time - so a bug is reproducible, and so the query cache from the last phase stores a real answer instead of one of several possible ones. For structured output, determinism isn't a limitation; it's the whole point.

Knowing when to shut up

A small problem I enjoyed solving. The model is supposed to emit one JSON object and stop. Sometimes it does. Sometimes it emits the object, decides it's on a roll, and keeps going, producing helpful commentary, a second example, and whatever else it feels like until it hits the token limit.

Generating tokens you're going to throw away is pure waste, and on a CPU each one costs real time. So the decode loop watches the output as it accumulates and counts brace depth. The moment the braces balance, meaning the first complete JSON object has closed, generation stops. In practice this cut a typical query from a hundred-plus tokens down to about twenty-two.

It's a heuristic, and I know its failure mode: a } inside a string value would fool it. My schema doesn't have string values that contain braces, so it holds. If that ever changes, the honest fix is to attempt a real parse each iteration and stop when it succeeds. I'd rather ship the simple thing that works and know exactly where it breaks.

Three bugs, none of them the model's

Once real queries started flowing, things broke. Every single time, I assumed the small model was being dumb. Every single time, I was wrong.

A rating of 5 kept vanishing. I'd ask for five-star photos, watch the model emit perfectly correct JSON with "value": 5 in it, and watch the rating field come out empty. The parser was calling QJsonValue::toString(), which returns an empty string when the value is a number rather than a string. Not an error. Not a warning. An empty string. The model had said 5; my code heard silence.

The fix was to stop assuming. Instead of blindly calling .toString(), the parser now checks the JSON value's type first, string, number, or bool, and converts each properly (QString::number() for a number, and so on). One value arriving as 5 instead of "5" shouldn't be able to silently erase a search constraint, and now it can't.

Dates never populated. The model would emit a date. The date widget wanted a range, in the form start..end. Nobody had told the model that. This wasn't a bug in the model so much as a bug in the instructions I'd given it.

The fix was in the prompt, not the code. I added an explicit instruction: dates must always be a range in the form 2023-01-01..2023-12-31, a whole year expands to its first and last day, a whole month to its month boundaries. Plus one worked example. Small models learn far more from a single concrete example than from three sentences of rules, and once the example was there, the ambiguity was gone.

And then: "last year" meant 2022.

This one is my favourite, because it's structural rather than accidental. I typed "photos from last year," expecting 2026. The model confidently produced 2022.

It wasn't guessing badly. It has no clock. A language model's sense of "now" is a fossil of whenever its training data was collected. It has no way to know what day it is, and this is the part that matters - no way to know that it doesn't know. So it answers with total confidence, and it's wrong, and nothing in its output looks any different from when it's right.

The fix is embarrassingly simple: tell it the date. The prompt now includes today's date and spells out the conversions explicitly: "last year" means such-and-such a range. It works.

But I keep turning the general shape of this over. An LLM's confidence is uncorrelated with whether it has the information needed to answer. Every layer of validation in this project exists because of that, and I built those layers before I had a concrete example of why they mattered. Now I have one.

The practical lesson for digiKam is concrete: an LLM has no real-time awareness, and photo search is full of time-relative queries: "last year," "last summer," "two months ago." Any of those is a landmine unless the prompt supplies the one thing the model can't know on its own. So the current date now goes into every prompt, with the relative conversions spelled out. The model doesn't need a clock; it needs to be told what time it is.

Where the code lives, or: the submodule that couldn't

llama.cpp had to get into digiKam's tree somehow. The obvious answer, and the one my mentor and I agreed on, was a pinned git submodule: reference a specific tag, build it in-tree, keep it clearly separate from digiKam's own code.

I did that. I got it building. I pushed.

remote: Audit failure - Invalid filename: .gitmodules
remote: Push declined - commits failed audit

KDE's git infrastructure does not permit submodules. The server rejects the push before it lands. My mentor's response was immediate and pointed me at the right precedent: digiKam has vendored external code for years. libraw, libpgf, QtAVPlayer are all sitting in the tree as plain source. Copy llama.cpp in the same way, pin it to a tag, document where it came from.

So I vendored it. And pushed. And:

remote: Audit failure - Invalid filename:
core/utilities/searchwindow/thirdparty/llama.cpp/.gitmodules

llama.cpp has its own submodules. Of course it does.

What followed was a trim. Out went the examples, the tools, the tests, the CI configuration, the Python conversion scripts, the web UI, the Swift bindings, the benchmark JSONs. What remained was src/, include/, ggml/, and the CMake files, the parts that actually build the library. Around 400 MB became 25 MB, the audit passed, and as a small bonus a CI job that had been failing (digiKam's JSON validator choking on llama.cpp's own tooling configs) started passing, because the files it was choking on no longer existed.

For KDE's infrastructure, vendoring wasn't the better option so much as the only one that gets past the server. It's worth being honest that it's a workaround, not the ideal end state: the cleaner long-term answer is for llama.cpp to be available as a standard system package that digiKam can simply depend on, the way it does for most of its libraries. Until then, a trimmed, pinned, documented copy in the tree is the pragmatic choice.

There's a manifest file now too, llama_cpp_manifest.txt, in the same one-line format digiKam uses for every other bundled library. It records the exact commit that's vendored. At packaging time it's parsed into the Help → Components Info dialog, so when a user reports a bug we know precisely which llama.cpp is running underneath. It has to be updated by hand on every upgrade, which is noted, loudly, in the README.

Seventy-eight seconds

The bug I'm most glad I chased.

Once everything built, a single query took over a minute. The log was blunt about it:

TIMING: generated 22 tokens in 78012 ms

Twenty-two tokens. Seventy-eight seconds. Roughly three and a half seconds per token, for a 1.5B model on a machine that should manage tens of tokens per second.

I went looking for the pathology. Was it swapping? A gigabyte of model plus KV cache on a 15 GB machine, plausible but free showed plenty of headroom and barely any swap in use. Was it thread contention, too many threads fighting over eight cores? I checked top while a query ran, expecting to see the process idle, blocked on something.

It was at 750% CPU. All eight cores, flat out, for seventy-eight seconds, to produce twenty-two tokens.

That's not a process that's stuck. That's a process working extremely hard and getting nowhere, which is a much more specific symptom, and it pointed at exactly one thing:

CMAKE_BUILD_TYPE:STRING=Debug

I develop in Debug builds. Faster compiles, usable in a debugger, the sensible default. And llama.cpp, sitting in-tree, inherited that build type which meant ggml, the matrix-multiplication engine underneath everything, was compiled at -O0. No inlining, no vectorization. The SIMD instructions were available (-march=native was there); nothing was using them.

Reconfiguring with -DCMAKE_BUILD_TYPE=Release flipped ggml to -O3, and the same query dropped from 78 seconds to about 8.7. A bit under nine times faster, from one flag. It's still not fast, because a 1.5B model on a CPU never will be, but usable is the bar that matters.

Same query, same machine, same model. The only difference is the compiler optimization level of the bundled llama.cpp.

The proper fix isn't "always build Release," because I want to keep debugging my own code. It's a few lines of CMake that force optimization onto the bundled llama and ggml targets specifically, even in a Debug build, leaving the rest of digiKam alone:

if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
foreach(_llama_target llama ggml ggml-base ggml-cpu)
if(TARGET ${_llama_target})
target_compile_options(${_llama_target} PRIVATE $<$<CONFIG:Debug>:-O2>)
endif()
endforeach()
endif()

So my code stays debuggable, ggml stays fast, and the next person who builds digiKam in Debug doesn't lose an evening the way I did.

The line I promised to come back to

Once inference was fast, the feature worked. I typed a query, got the right photos, typed another, got those too. I was ready to call it done.

Then I noticed that if I searched enough times, every search started failing. Not one bad query - all of them, from some point onward. The first few worked perfectly; then a wall, and after it, every single query came back with "could not interpret the model output," permanently, until I restarted digiKam.

That "permanently until restart" is the tell. A bad query is one thing; a backend that works and then stops working forever is state gone wrong. Something was accumulating.

It was the KV cache. A language model's context has a cache of the tokens it has already seen, and llama.cpp appends to it as you decode. My inference code decoded each new query's prompt straight onto the end of that cache without ever clearing it. So query one ran at positions 0 to 40. Query two ran at positions 40 to 80 - stacked on top of query one, which was still sitting there. Every search pushed the position higher, and once the total crossed the context limit (n_ctx, 4096 tokens), llama_decode started failing and never recovered, because the cache stayed full.

The fix is the single line from the snippet earlier:

// Start each query from an empty context.
llama_memory_clear(llama_get_memory(ctx), true);

Clear the cache at the start of every inference, and each query is independent again.

What gets me about this one is why I didn't catch it sooner. Every time I tested during development, I was restarting digiKam constantly - rebuilding, relaunching, running one query, rebuilding again. A fresh process has an empty cache, so the bug was invisible. It only appears when you do what an actual user does: open the app once and search several times in a row. My whole testing rhythm was hiding it.

That's the second bug in this project that only showed up under repeated real use - the first being a compiler flag that would only misbehave on someone else's CPU. Both are arguments for the same thing: a test that runs two queries back to back, which is exactly the kind of automated inference test my mentor asked about in review. A single-query test would have passed. The bug lives in the second query.

What I actually learned

I came into this project wanting to understand LLMs, and I have. But the thing I did not anticipate is how much of "put an LLM in an application" is not about the LLM.

It's about whether a bundled CMake target can live in an exported target's link interface. (It can't, and the workaround is $<TARGET_FILE:> plus an explicit add_dependencies to restore the build ordering.) It's about a recursive header glob quietly sweeping llama.cpp's headers into every unrelated compilation unit in the project, breaking files that have nothing to do with any of this. It's about your distribution shipping OpenCV 4.6 when the project needs 4.8. It's about a git server's twenty-year-old policy on submodules.

None of that is glamorous. All of it is the job. The model was the part I understood; everything wrapped around the model was the part I had to learn, and it's the part I'm most glad to have learned, because it's the part that makes a feature into something a project can actually ship and maintain.

Key takeaways

• The model is the small part. The real work of putting an LLM in an application is integration: the build system, the packaging, the infrastructure. The inference was the piece I understood going in.
• Determinism is a feature. For structured output that feeds a cache and has to be reproducible, greedy decoding beats anything with randomness in it.
• Build flags decide whether a feature is usable. The same code went from 78 seconds to 9 with one optimization level. Always profile in Release.
• Infrastructure has opinions. KDE's git server rejects submodules outright, so vendoring wasn't a preference, it was the only way in. Know your project's constraints before you design around them.
• An LLM's confidence says nothing about whether it's right. It called "last year" 2022 with total certainty. Every validation layer in this project exists because the model can be confidently wrong, and the output has to be checked against what the collection actually contains.

Where things stand

Natural language search runs end-to-end against a real, local Qwen2.5 model. You type "photos from 2023 rated 5 stars," the model turns it into structured constraints, digiKam's own search engine finds the photos. "Red label photos rated at least 3 stars" works. Date ranges work. Relative dates work.

The pipeline tests run against the mock backend and need no model, which keeps them CI-safe, and they now include regressions for both the numeric-value and the date-range bugs above. Neither of those would have been caught by a test of the model. Both were caught by a human typing a query and squinting at the result, which tells you something about where the bugs in this kind of system actually live.

What's next

• Real-inference test: an automated test that loads the actual model and runs a query, gated on the model being present so CI stays green when it isn't. The KV cache bug above is exactly what this would catch, so it's first.
• Fix caching for relative dates: the query cache currently stores relative-date queries, so a cached "last year" quietly goes wrong once the year changes. Those simply shouldn't be cached.
• Ambiguity resolution: "landscape" is both an orientation and a subject, and the model hedges. The robust fix is validating values against the collection's actual tags and people, which the resolver already has hooks for.
• Prompt hardening: small models resist saying "I don't know." Prompt work has helped but not solved it.
• Benchmarking: the comparison I promised, Qwen2.5 against TinyLlama on real digiKam queries.

Thanks for reading. If you're curious about the project or working on something similar, you can email me at: srirupa.sps@gmail.com if you wanna discuss! :)

14 Jul 2026 8:33pm GMT

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

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

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

View full changelog

14 Jul 2026 12:00am GMT

So… another missing icon gets some attention

This time it was Kommit.

The funny thing about Git related icons is that everybody eventually ends up drawing the same thing. A couple of connected nodes, some branches in a diamond shape....

I started pretty close to the existing Git visual language adjusted to Oxygen, but after a few iterations the icon slowly started drifting towards something that felt a bit more interesting. Softer shapes, more emphasis on the flow of the branches and less "K pasted into a square". (we love k)

So here is the story of how a icon is set to life I could say a ton more things but.... heeee

This was not working for me at all need to pivot....

ok there is somthing cool here lets explore more

shading lets do shading, (the old trick) oo and what if the line was a kinda of a flowing path?

wil never work as an icon, hummm.. need to make it more boxy!

hummm maybe less red??? the previous line art was kinda cooler loking... ;(

yeah!!!.... but what if we make the lines more chubby?

ooooo yeah...."that is the way"

13 Jul 2026 9:28pm GMT

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

MR !911 opened and reviewed

Opened the Gradient widget MR this week, closing issue #1064 and referencing #2206. Jean-Baptiste reviewed it and flagged a few things.

Fixing the gradient render bug

The gradient bar was rendering as a flat, empty rectangle, only the stop handles below it showed color. Root cause: the native QStyle::drawPrimitive(PE_Frame, ...) call added for frame styling was painting its interior background after the gradient fill, covering it completely under Breeze's style. Fixed by reordering the paint sequence, frame first, then the checkerboard-for-alpha and gradient fill inside the frame's content rect, so nothing gets overpainted.

Before:

After:

Missing 32-stop cap at the model layer

The widget already capped stops at 32, but AssetParameterModel's parsing path for ParamType::GradientEditor had no equivalent check. A hand-edited or corrupted project file could bypass the widget entirely and load more than MLT's gradientmap filter supports. Added truncation at the model level so both layers enforce the same limit independently.

Handle visibility fix

The first stop's handle (black) was nearly invisible against Kdenlive's dark theme. Added a stroke around each unselected handle using the palette's text color at 50% opacity, so dark-colored stops stay visible regardless of theme.

RGBA tooltip on hover

Added a small tooltip showing a stop's exact RGBA value on hover, requested during review.

Midterm evaluation

Submitted July 10.

What's next

MR !911 is rebased on current master and pushed with all review fixes; waiting on another look from Jean-Baptiste.

13 Jul 2026 7:13am GMT

The openQA-based testing system has recently been integrated into KDE Linux (hooray!), and I thought it was about time I did a little write-up.

The nature of KDE Linux, in which the whole system ships as a single signed image rather than a pile of packages, is (in theory) wonderful for reliability. However, this raises an uncomfortable question: how do we make sure that image actually works before we ship it to people? OpenQA is the answer!

TL;DR: we boot each build in a virtual machine, run tests that interact with it to ensure the system installs and upgrades properly and that desktop functionality works. Once the tests pass, the user gets an end-to-end tested image. This replaces the rather rudimentary basic-test machinery, which simply booted up the live image and checked if the boot was blessed and if any units failed.

The test flow

A single build goes through three stages.

install-system takes the live ISO, boots it in a VM, and runs a real installation onto an empty virtual disk, just like a real user would. sanity-test then boots that freshly installed disk and verifies the system actually comes up and behaves. In between, while we're testing the upgrade path in parallel, an upgrade-system stage installs the previous release and upgrades it to the current build to check whether the previous release can actually be upgraded to the new build. Each stage hands its disk to the next.

They're wired together as a dependency chain, so in the openQA web interface the whole run shows up as a single connected graph. If installation fails, the later stages don't bother running, as there's nothing to test.

Our CI pipelines now approximately look like this:

Interesting architectural tidbits

We do a few things differently compared to your stock-standard openSUSE or Fedora openQA instances.

Selenium testing instead of needle testing

Normal openQA tests operate through "needles". These aren't sewing needles; rather, they're screenshots of the virtual machine in some desired state with some JSON metadata attached. This metadata defines certain areas to match or ignore, and the test code can click matched areas. While needles are certainly effective at interacting with the system exactly how a user would, they have drawbacks. It's quite annoying to make and constantly update needles, as well as keep them from breaking every time there are slight changes in user interfaces.

Luckily for us, we already have a battle-tested way of interacting with user interfaces for testing: selenium-webdriver-at-spi . It's already widely used across unit tests in KDE projects, hence our decision to use it affords us a lot more flexibility, maintainability, and consistency. It also enables app developers to run their own tests on KDE Linux with openQA down the track.

Essentially, we have a Python unittest script on the system that we're testing (see the sysext section below for details), which attaches itself to an application. It then interacts with the app by leveraging the AT-SPI2 accessibility API to send clicks and read the screen, in a similar vein to screen-reading software such as Orca.

Ephemeral workers in CI jobs

openQA instances usually have long-running workers that are hosted on servers. It's a bit of a painful ordeal to get all that infrastructure up and running. On top of that, hosted workers need to do an upload-download rigmarole involving large assets from the server, such as the .iso files and the generated hard disk. This makes things very slow for no good reason.

We already have CI runners that work perfectly well for this and can be spun up when needed, giving us effortlessly simple scaling. So, we spin up an openQA worker container in a CI runner, which submits jobs to the openQA server. It has its own UUID, which is shared with the job, so the worker running in CI is always assigned the right job.

This saves us from the bandwidth rigmarole because all the assets are generated and consumed within the one container, so we can simply keep all the assets on the worker and never upload them to the server. As a result, we save a lot of storage space on the openQA server, so we can run it with fairly minimal hosting requirements.

The use of systemd system extensions to inject tests

How do we actually get our Selenium tests on the system, you may ask? Enter the humble system extension , or sysext, for short.

We include a few things in our sysext:

• The Python unittests themselves.
• A bootstrap script with some system configuration, so we have an appropriate environment set up for testing.
• A venv, so we can make use of the Python ecosystem. This is created in the bootstrap script.

All of this is packaged up into an EROFS .img file, which we mount to the worker's VM. This is then automounted by an associated udev rule in upstream KDE Linux, with the bootstrapping script being triggered by an associated service shortly afterward.

Since we have the capability to inject tests and configuration into the system, we're able to test things that would otherwise be impossible to test with needles. For example, we test if essential desktop processes have ever crashed, if any systemd services failed, if networking works, and if commands we ship with KDE Linux work properly. All of these tests leverage direct access to the innards of the system.

Interaction with the system through SSH

To actually poke at the system and have the worker run these tests sequentially, we need some way of interacting with the system. openQA provides some facilities to interact with a serial terminal, but this proved to be very fragile and unreliable, with buffering issues everywhere.

Instead, we set up SSH with our sysext and use the facilities provided by the Python library Fabric to run all our tests in a robust manner.

Each test runs in a transient systemd service created by systemd-run. This runs the test as the intended user, groups its processes in a cgroup, gives it an isolated journal stream for output, and returns its service exit status synchronously. The harness can then collect the unit's journal even when the test fails, and we keep everything neat and tidy.

Staging images before we publish, and how we test updates

To prevent users from downloading an image that still needs to be tested, we create a staging directory on storage.kde.org, scoped to the imaging stage's job ID, that stores the built artifacts in a directory tree. It has a layout that mirrors the public-facing tree, so we can simply merge it in once tests pass.

However, this throws a spanner in the works when we try to test system upgrades because we obviously can't upgrade to an image that hasn't been published yet!

To fix this, the solution is simple. In the sysext, we simply point systemd-sysupdate to the staging directory we've already created. This has some drawbacks, though. For the moment, we can't test delta updates through kde-linux-sysupdated. That shouldn't be too difficult to fix in the near future, but we're waiting on KDE Linux to be entirely hosted on storage.kde.org before we jump on that. The bigger issue here is that we really don't have a good way of testing updates from the chunk store. A better story for this still needs to be worked out, but for the time being the upgrade test is good enough.

What's to come

We have a few things we're aiming towards:

• As mentioned above, testing delta/chunked upgrades.
• Leveraging openQA to allow app developers to test their own apps atop KDE Linux.
• Generalizing all our openQA glue so other projects can use the architecture we've built.
• By extension, porting the aforementioned glue from admittedly fragile bash scripts to Python or some other more appropriate language.
• Testing installs using manual partitioning and Full Disk Encryption.

…and probably many more things that we haven't thought of yet. Exciting times!

13 Jul 2026 12:00am GMT

I just finished reading Thom Holwerda's hilarious article on OSnews about being paid to use Windows 11 for a month from the perspective of being a "switcher" moving away from Linux. It's a great read; I encourage everyone to stop right now and go read it!

In a nutshell, it's truly amazing how bad the modern Windows user experience is when you're accustomed to anything else:

• Missing drivers
• Black screens
• Broken sleep/wake
• Ads and intrusive AI in apps
• No visual consistency
• An update experience that's fragmented, slow, and frustrating

My extended family includes a lot of Mac users, and I can tell you it's barely better there. They suffer from:

• Limited hardware selection
• Devices that deliberately skimp on storage space to push people towards paid cloud storage subscriptions from Apple
• Ugly and low-contrast UIs
• Terrible window management
• Slow and unresponsive apps
• Poor integration with 3rd-party services

We're ready

I've been saying for years that Linux is ready for normal usage. We often lament our bugs and failures, but under-estimate just how bad the competition is.

The reason why Windows and MacOS are so prominent is not because they're better, but rather because of their inertia and wide distribution on retail hardware. If people can't buy Linux computers in Best Buy and Mediamarkt, we'll never get there.

Inertia takes care of itself over time with success. But we can do something about distribution: we can continue to make our software pre-installation ready. I've been talking about this since my first Akademy talk in 2018, and KDE has made amazing progress in just 8 years.

It's clearly working, too.

Successes

This is why I get so excited about Valve's new Steam Machine console/PC running KDE Plasma. Five years ago, I got excited about the Steam Deck. And I'm excited about Tuxedo Computers and Kubuntu Focus for shipping KDE Plasma on all of their computers out of the box. For an up-to-date list, see https://kde.org/hardware.

I hope that in due time, I'll be excited about Framework Computer and Slimbook shipping a Plasma-based OS out of the box, too. And someday after that, Razer. I think they'd be receptive. And then Lenovo, HP, Dell, and Asus. I don't believe this is far-fetched.

When people buy one of these devices, are they going to experience some Linux-specific bugs and annoyances? Yes, it's inevitable. Nothing is perfect. But what we offer is good. Better, even. Better for users and better for hardware vendors.

What's left

Is there more to do? Yes. We need a stronger 3rd-party software ecosystem, including Linux versions of more popular pro apps. A bit more Wayland work to close the remaining gaps. Operating systems that are safe and full-featured out of the box. Better documentation. More companies capable of offering professional support. And so on.

But all of this is happening! Isn't that amazing? I find it amazing. Here we all are, offering the world a better option as some of the world's largest companies are in stage 2 or 3 of the enshittification process. And we can help. It's so cool.

12 Jul 2026 1:47pm GMT

Take this new Kamoso icon for example.

Most people will see a "webcam" with a overly large lense. Some people might notice the reflections. Almost nobody will notice the tiny details inside the lens itself, the subtle changes in materials, the little bits of visual noise that stop things from feeling too artificial, or the writing around the lense repeating KAMOSOLENS 2026. And yet....

Which naturally raises the question… why bother?

Its not like users are going to zoom into a 256 pixel icon and start inspecting reflections like art critics examining a renaissance painting, (I realy wish you dont ). Most of these details exist below the threshold of conscious perception. People don't really see them. At least not directly.

And yet I still think they matter.

The older I get the more I like to think details are a expression of love, of care. The kind of care that makes people do things that make absolutely no rational sense.

I grew up in Portugal and over here mothers have a particular way of saying "I love you". They don't usually say it. Instead they spend two days preparing enough food to feed a small village and then look personally offended when you stop eating after the third serving. The food is the message. The effort is the message. The ridiculous amount of work nobody asked for is the message.

So inevetably I think design works in much the same way.

When somebody spends hours polishing an animation that users will only experience for half a second, when somebody redraws an icon because one highlight feels wrong, when somebody obsesses over spacing differences measured in single pixels, they are saying "I care".

Now make no mistake, as a user I often feel exactly the same level of care in very minimalistic interfaces. Simplicity and care are not opposites. Some of the most thoughtful designs I know are also some of the simplest.

But sometimes overly minimal, dare I say bland, interfaces communicate something else .... disinterest. The feeling that only the minimum amount of work was invested so a feature could exist.

I think users only get to see the final thing, and as a user I find it difficult to care more about something than I believe its creators cared about it.

Thats why details matter to me. Not because people consciously notice every reflection, shadow or hidden joke buried inside an icon, but because details are little traces left behind by the people who made it.

Evidence that somebody cared enough to spend time on things they didnt strictly need to spend time on. And I think people notice that (or I hope they do).


As Plans for Oxygen in Plasma 6.8.

The biggest one is probably the work being done to make Oxygen play much nicer with Kirigami applications. Hopefully the Union effort will enable us to finally start to port things over and tackle some of the rough edges.There is also the usual stream of icons, fixes and random details that somehow consume far more time than they have any right to :)I'm also hopeful we can make some progress on icon selection options. No promises yet... but its definitely on the list of things I would like to see happen. at lest the UI.

So stay tuned, Oxygen continues to slowly move forward. Which is honestly more than i expected when i started by "just fixing a bug"... heee...

11 Jul 2026 2:24pm GMT

Welcome to a new issue of This Week in Plasma!

This week was busy! We've got some great new features to share, improved theming compatibility, UI improvements, bug fixes… and lots more! This is one of those weeks with a bit of something for everyone ­- even people who are picky about software dependencies. Take a look:

Notable new features

Plasma 6.8

Spectacle now gives you the option to record audio during screen recordings! It can grab audio from the microphone, audio that the system is outputting, or both. (Khudoberdi Abdujalilov, KDE Bugzilla #474798)

System Monitor can now measure VRAM usage as a percentage of the total, just like it can for regular RAM. (Beck Thompson, ksystemstats MR #135)

The 13-month Ethiopian calendar joins the growing ranks of supported alternate calendars! (Eyobed Awel, kdeplasma-addons MR #1079)

Notable UI improvements

Plasma 6.6.6

Improved the responsiveness of the brightness slider in the Brightness & Color widget. (Marco Martin, powerdevil MR #650)

Plasma 6.7.3

The Vietnamese lunar calendar now displays its text in Vietnamese even if your system language is set to something else, which is more consistent with other alternate calendars. (Trần Nam Tuấn, KDE Bugzilla #521787)

The feature to show alternative characters when you press and hold a key on the keyboard now triggers after 600 milliseconds of holding, rather than 200. This should make it much harder to accidentally activate. (Kristen McWilliam, plasma-keyboard MR #157)

You can now interact with the Overview and Custom Tiling overlays using a drawing tablet stylus in a Wayland session. (Nicolas Fella, KDE Bugzilla #468396 and KDE Bugzilla #522677)

Plasma 6.8

Comboboxes in Plasma now use the active Plasma theme to style their popups, rather than using a hardcoded Breeze-style appearance. And their menu highlights no longer animate in and out, either, which matches the appearance everywhere else. (Filip Fila, libplasma MR #1547 and libplasma MR #1550)

System Settings' Remote Desktop page no longer looks somewhere between "very awkward" and "broken" with a small and narrow window size, like on a phone. (Nick Haghiri, krdp MR #208)

System Settings' "Report a Bug in the Current Page" feature now works for pages that didn't come from KDE but still list a bug reporting URL. (Antti Savolainen, systemsettings MR #412)

Auto-login now works in Plasma Login Manager on operating systems with older versions of systemd, like KDE neon. (David Edmundson, KDE Bugzilla #522006)

Brightness on external monitors now changes more quickly after you adjust the brightness slider in the Brightness & Color widget. (Kylie CT, KDE Bugzilla #498913)

Frameworks 6.29

When using the default qqc2-desktop-style system (as opposed to when testing the upcoming Union system), list and grid view highlights in QML-based KDE software now respect the visual styling of the active app style, rather than having a hardcoded Breeze-style appearance. In addition, password fields no longer change in height for certain fonts when you type the first character into them. (Evgeniy Harchenko, qqc2-desktop-style MR #521 and qqc2-desktop-style MR #524)

The Breeze icon theme now includes an icon for Android app bundle files. (Tobias Zwick, KDE Bugzilla #508430)

The large fancy Kirigami tab bars seen in QML-based KDE software now switch the active tab when you scroll over them or press one of the standard tab-switching keyboard shortcuts - just like tab bars in QtWidgets-based apps do. (Tobias Ozór, kirigami MR #2123)

Notable bug fixes

Plasma 6.6.6

The Choose Application window no longer percent-encodes some characters in filenames, which looked pretty ugly. (David Redondo, KDE Bugzilla #521748)

The Media Frame widget no longer displays every other image in a somewhat sharpened and crunchy manner. (Marco Martin, KDE Bugzilla #521534)

Plasma 6.7.3

Fixed a recent regression that broke closing windows in the Overview overlay by middle-clicking them. (Xaver Hugl, KDE Bugzilla #522015)

Fixed a few remaining minor layout regressions in the Color Picker widget, so now it should always have the same size as it did in Plasma 6.6. (Tobias Fella, KDE Bugzilla #522377)

Fixed a recent regression in an X11 session that made icons of all running Flatpak apps appear unnecessarily in the System Tray. (David Redondo, KDE Bugzilla #522864)

Plasma no longer crashes if you disable the Calendar Events plugin in one Digital Clock widget when there are more than one of them with that plugin enabled. (Shouvik Kar, KDE Bugzilla #520465)

When the system is configured to automatically switch global themes at certain times of day, this switchover now takes place as expected even if the computer happened to be turned off when the transition would have taken place. (Vlad Zahorodnii, KDE Bugzilla #511740)

Plasma 6.8

Fixed a glitch related to scrolling in System Monitor's Configure Columns popup, which is now a traditional window instead. (Arjen Hiemstra, KDE Bugzilla #517723)

In the Networks widget, connecting to a network you don't have permission to edit no longer mistakenly makes all other available networks look connected. (Sergey Katunin, KDE Bugzilla #461028)

Frameworks 6.29

Fixed a subtle regression that prevented overriding settings set at the vendor/distro level (e.g. via a /etc/xdg/kwinrc file) that differed from Plasma's own default settings. This affected Kubuntu and Fedora, which turned on Wobbly Windows and Plasma Keyboard, respectively. (Nicolas Fella, KDE Bugzilla #519481)

Typst documents once again show a fancy icon when using the Breeze icon theme, fixing an issue where this stopped happening after the official MIME type for Typst files was changed upstream of KDE. (Boris Jurcaga, breeze-icons MR #554)

Notable in performance & technical

Plasma 6.6.6

Using a udev rule to set the LIBINPUT_CALIBRATION_MATRIX property now works as expected in a Wayland session. (Nicolas Fella, KDE Bugzilla #521464)

Plasma 6.8

Spectacle no longer requires the fairly chunky OpenCV software library; we found a way to implement an adequately-performant blur effect without it. (Noah Davis, spectacle MR #561 and kquickimageeditor MR #53)

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.

11 Jul 2026 12:00am GMT

Let's go for my web review for the week 2026-28.

Chat Control 1.0: EU Council forces messenger scans via fast-track

Tags: tech, europe, surveillance

This is a shady move once more… They really want to extend this security apparatus. We could hope there were enough MEPs to vote against this… but it's not been the case.

https://www.heise.de/en/news/Chat-Control-1-0-EU-Council-forces-messenger-scans-via-fast-track-11353659.html

You paid me, a long-time Linux user, to use Windows 11 exclusively for a month: here's how it went

Tags: tech, windows, funny

Funny experiment. If you're a Linux user pondering going back to Windows it'll likely cure you. Goodness the install experience is abysmal and that's just the beginning of the troubles. Of course it has a good side as well but it feels fairly limited.

https://www.osnews.com/story/145459/you-paid-me-a-long-time-linux-user-to-use-windows-11-exclusively-for-a-month-heres-how-it-went/

Democratizing Abandonware

Tags: tech, ai, machine-learning, gpt, copilot, slop, flatpak, codereview

The data set is rather small but the trend is really bad. So much reviewer time wasted due to AI slop… this time on the Flathub side.

https://geopjr.dev/blog/democratizing-abandonware

I am not a tool

Tags: tech, ai, machine-learning, gpt, copilot, ethics, foss

Really this kind of AI push is a bad move from employers, especially when interacting with FOSS communities so much. This forces people to pass the ethical issues onto volunteers…

https://eng.hroncok.cz/2026/07/07/ai-tool

Bosses Horrified as "AI Native" College Graduates Hit the Workplace

Tags: tech, ai, machine-learning, gpt, productivity, education

How is going this social experiment at scale? Not well I'd say… And some in those cohorts will end up in positions of power, that's when it'll become really "interesting" I guess.

https://futurism.com/future-society/college-critical-thinking-ai

Local, CPU-Friendly, High-Quality TTS with Kokoro

Tags: tech, ai, machine-learning, speech

This keeps being a very interesting TTS model. Looks like it's getting simpler to deploy too.

https://ariya.io/2026/03/local-cpu-friendly-high-quality-tts-text-to-speech-with-kokoro/

Cpp2Rust: Automatic Translation of C++ to Safe Rust

Tags: tech, c++, rust, compiler

Still need some work I'd say but this is interesting research. Transpiling C++ to Rust is getting more accessible. It need some improvements on the optimisation side to be more generally usable.

https://web.ist.utl.pt/nuno.lopes/pubs/cpp2rust-pldi26.pdf

Physically Based - The PBR values database

Tags: tech, shader, pbr, physics

Cool resource to have the right values for various PBR materials.

https://physicallybased.info/

How I'm using CSS View Transitions on this blog

Tags: tech, html, css, animation

A good reminder that you can go a long way to specify transitions with just CSS nowadays.

https://blog.omgmog.net/post/how-im-using-css-view-transitions-on-this-blog/

Size does matter, actually

Tags: tech, web, performance, complexity

There are ways to have a lighter web. It leads to interesting techniques too.

https://nh3.dev/blog/05-bloat

98% isn't very much

Tags: tech, reliability, statistics

Can you rely on something? Indeed, if it fails "only" 2% of the time it can mean a lot of failures… you better handle the edge cases and degrade gracefully.

https://whynothugo.nl/journal/2026/07/03/98-isnt-very-much/

a software engineering interview question I like: computing the median

Tags: tech, hr, interviews, complexity

I like this kind of questions as well. It's more interesting to aim for something simple to start with than a puzzle. Even topics considered simple have several layers of complexity.

https://krisshamloo.com/blog/007

The Lion, The Witch, and the audacity of recruiters

Tags: tech, hr, interviews

Whatever the hiring process, show some respect to the candidate. It's the least you can do for them.

https://hauleth.dev/post/the-lion-the-witch-and-the-aduacity-of-recruiter/

The myth of mind uploading

Tags: tech, scifi, science, philosophy

A long piece, but digs in details on why "mind uploading" really can't be a thing.

https://plus.flux.community/p/the-myth-of-mind-uploading

Bye for now!

10 Jul 2026 12:09pm GMT