fidzu : KDE

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

Friday, 10 July 2026

KDE today announces the release of KDE Frameworks 6.28.0.

This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.

New in this version

10 Jul 2026 12:00am GMT

Myself and others have been contributing to Koko under the banner of Techpaladin Software. Here's what we've been up to over the past year.

09 Jul 2026 1:51pm GMT

Qt for MCUs 2.12.2 LTS has been released and is available for download. This patch release provides several bug fixes and other improvements while maintaining source compatibility with Qt for MCUs 2.12 (see Qt for MCUs 2.12 LTS released). This release does not add any new functionality however as part of a continuous effort to scale Qt for MCUs to more platforms new Tier-2 board Nuvoton Gerda-4L is now available.

09 Jul 2026 3:00am GMT

Hi everyone!! So we are halfway through our journey of GSOC 2026. It's time for the midterm and new status updates we have accomplished over the past 6 weeks.

• During my first and second weeks, I familiarized myself more with the XMPP protocols and clients like Kaidan, etc., which can be used for XMPP server interactions and also created a page for the Mankala Engine using Hugo. I have successfully added the option to register XMPP accounts from within the Mankala Engine and also added an XMPP compliance check in the 2nd week, which makes sure that the selected XMPP server has all the protocols that are needed to play the game.

• For the next tasks in week 3, I worked on extracting usernames and profile player icons from within the XMPP servers and directly display it as part of the user account in the game. I also fixed the sizes for the different components in the profile page and gave it a proper redesign.

• For weeks 4 and 5, I spent time creating the tournaments. I experimented a bit with the connectivity to connect more than 2 players to an XMPP server, and then created a detailed tournament page for the number of wins, losses, and player match details, and thus implemented the round-robin tournament style. Some more features, like setting up the time limits for each move and accepting game invites, were also added.

• In the 6th week, I gave a talk at the ILUGC (Indian Linux Users Group Chennai) virtual meet and got feedback from the players, and implemented better sounds and a sound button for the game. I also added animations for the shells so they get smoothly displaced to their destined pits after each move.

Challenges I faced

The most difficult part while implementing tournaments can be said to connect multiple players and track their moves in real time across the games. The best possible way to fix this was to create a XMPP MUC and then join the player using that and track the moves being sent across the channel. So, for example a move played by Player 1 will be sent to Player 2, to do this we send the request from Player 1's account track the request through the MUC and display it on the Players 2's board and same goes for multiple players present in the game.

Goals for upcoming weeks

A couple of changes were added based on our GSOC proposal, and a lot of new things and features were implemented. In the next half of GSOC, I plan to work on text- and voice-based chat options within the Mankala so that players can communicate with others during their matches. I also plan to add another variant of tournaments, which gives the players a broader number of options to choose from, and add the feature to create a user-defined AI to play against another person or an AI over the network.

Thanks for reading 🚀

08 Jul 2026 1:51pm GMT

This week I implemented clipboard auto-clear for KeepSecret (!36).

When a user copies a password, it shouldn't stay in the clipboard indefinitely - that's a real security risk if the clipboard gets inspected, synced, or accessed by another application.

What was implemented:

After copying a password, the clipboard is automatically cleared after 30 seconds. A Kirigami.InlineMessage countdown notification appears in the entry page showing "Password copied. Clipboard will be cleared in X seconds", updating every second. The clipboard is also cleared when the app quits via QCoreApplication::aboutToQuit. Instead of QClipboard::clear() (which on X11 reverts to the previous clipboard entry), the clipboard is overwritten with an empty string. A single repeating QTimer of 1 second handles both the countdown and the clear - subtracting 1 second each tick, stopping and clearing when it reaches 0. The timeout uses std::chrono::seconds as suggested by Marco Martin during review.

Klipper history protection:

One tricky KDE-specific problem: even if you clear the clipboard after the timeout, the password could still be sitting in Klipper's clipboard history. The fix is to add the x-kde-passwordManagerHint MIME type (set to "secret") alongside the password data when copying. Klipper specifically checks for this hint and skips adding that entry to its history entirely - so the password never gets recorded there in the first place. This approach was pioneered by KeePassXC.

07 Jul 2026 8:14am GMT

I attended my first KDE sprint in Graz, Austria, travelling abroad for the first time. In this late blog post, I discuss the things I did and my thoughts on travel.

07 Jul 2026 7:40am GMT