TL;DR https://codeberg.org/cryptomilk/crane-wyoming

Where I started

I use Home Assistant, and for text-to-speech (TTS) I’ve been running Piper through Wyoming Piper.

Piper is a fast, local neural TTS engine originally built for the Rhasspy project and now maintained by the Open Home Foundation. It’s designed to run entirely offline, even on modest hardware like a Raspberry Pi.

Wyoming is the open protocol Home Assistant uses to talk to voice components like TTS, speech-to-text, wake word, voice activity detection (VAD, which decides when someone has started or stopped speaking) over the network, so any service that speaks Wyoming can be plugged in as a satellite. Wyoming Piper just wraps Piper so it can be served this way.

Both work well and I have no complaints about reliability. My issue is quality: the German voices aren’t great. Piper depends on open datasets for training, and good open German speech data is scarce, so the German models lag behind the English ones. I also run TTS locally on my desktop for event reminders, so voice quality matters to me beyond just Home Assistant.

Looking for something better

I wanted better output quality, so I started looking at alternatives and found Crane, a Rust inference
framework built on Candle.

An “inference model” is a trained neural network used to actually produce output like text, speech, an image, rather than to learn from data (that’s “training”). An “inference framework” is the software that loads such a model and runs it efficiently: managing GPU/CPU memory, batching requests,
and exposing an API around it. Piper and Crane are both inference frameworks.

Crane already had Qwen3-TTS support, and its Serena voice’s German output sounded noticeably better. I also wanted to try Voxtral-4B-TTS-2603, Mistral’s open-weight TTS model, so I added support for it. Voxtral TTS produces expressive, natural-sounding speech across 9 languages including German, with low time-to-first-audio and streaming support. It is a good fit for a voice assistant that needs to start speaking quickly.

Adding Wyoming support

Once Voxtral was working in Crane, I built crane-wyoming, a standalone Wyoming protocol server, so Home Assistant could use these models as its TTS service. To make that possible, I added the Tts trait and the surrounding TTS abstractions to Crane, since there was no stable interface for driving a TTS model on its own, separate from Crane’s full inference engine (tokenizer/LLM/VLM machinery). Those abstractions have since been merged upstream: lucasjinreal/Crane#44.

crane-wyoming depends on Crane only for that Tts trait and the concrete model types it needs to construct, not Crane’s engine crate. So it carries its own small TTS-only model runtime (one dedicated worker thread per loaded model) and its own on-disk response cache.

The project grew into a small Cargo workspace. Besides the Wyoming server
itself, it now has cw-say, a standalone CLI client for scripting.

It also has sd_crane_wyoming, an output module for speech-dispatcher. speech-dispatcher is the common Linux TTS abstraction layer that screen readers like Orca, and other accessibility tooling, talk to. It launches output modules as subprocesses and speaks to them over stdin/stdout, using its own line-oriented, SMTP-style protocol. sd_crane_wyoming translates that into Wyoming requests against a running crane-wyoming server. That way, the same server process and cache serving Home Assistant can also serve the desktop. After registering it in speechd.conf, spd-say -o crane "..." works. So does anything else built on speech-dispatcher, like Firefox’s “Read Aloud” or Orca itself. All of it gets the same voice quality as Home Assistant, without running a second TTS backend.

What’s next

• Speech-to-text. I’ve added Qwen3-ASR support for utomatic speech recognition (ASR) into Crane. This needs to be wired in crane-wyoming next. Also Voxtral-Mini-4B-Realtime-2602 is interesting.
• VAD. Crane already has a Silero VAD implementation. Adding it for STT is straight forward.
• Wake word. Once VAD is in place, add Open Wake Word support or similar.

With all of that implemented, you’d have a complete self-hosted Wyoming voice stack with no cloud dependency.

Current limitations

The catch is that you need a GPU to run it well.

If you only need TTS for occasional things like reminders, short announcements, running it on CPU with caching is enough, since repeated phrases just get served from cache instead of resynthesized.

All of this is for advanced users and hackers right now. There’s no polished packaging yet. Systemd units exist for both system and user services, including socket activation, but you still have to build from source.

However testing and feedback are welcome.

https://codeberg.org/cryptomilk/crane-wyoming

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

Development Report

Developments in Krita Plus

Dependencies have been updated in the Qt5 builds (Krita 5.3.x). This updates many libraries Krita depends on for things like file format support. (change)

Luna and Agata have continued improving the Selection Actions Bar. Now it remembers the distance from the selection on restart, and there's a button to pin it to the bottom of the canvas widget instead of next to the selection. (change)

In the Python scripting API, the View class now has signals for 'currentToolChanged', 'currentBrushPresetChanged', 'foregroundColorChanged', and 'backgroundColorChanged'. (change by Moritz Staudinger)

Developments in Krita Next

Wolthera and Dmitry continued working on HDR improvements. CICP values can now be read from and written to ICC profiles, and a "Krita Rec. 2100 Perceptual Quantizer (80cd/m²)" profile has been added (change). PQ reference white can now be read from ICC profile (change).

The Line Tool nows show the angle alongside the length in the floating message popup. (change by Moritz Staudinger)

Future Developments

Testing Needed: Android Animation Export

Last month's new feature of rendering timelapses using Android's built-in MediaEncoder is now being brought to animation export. But it needs testing before it can be merged to the main builds, so so check out the animation export on Android forum topic for test packages if you want to help!

Community Report

June 2026 Monthly Art Challenge Results

The winner of the "Something Unexpected" challenge is…

Join This Month's Art Challenge!

For July's theme, last month's winner passed the choice of topic to runner-up Paint4Thought, who has chosen "An Imaginary Friend". The optional challenge is to place the character(s) in a well-developed environment that contributes to telling the story. Show us what lurks in the depths of your imagination!

Featured Artwork

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

Nominate and Vote For Next Month's Featured Artwork!

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

Krita is Free - But You Can Contribute!

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

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

Additional Changes

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

• Text: Fix various font loading issues. Use default vertical caret in non-variable fonts. Fix Regular font style not showing and defaulting to Italic. Fix duplicate fonts causing fonts not to load. (bug 1, bug 2, bug 3; change by Wolthera van Hövell)
• Animation Timeline: Switching between frames should always complete, rather than sometimes showing the new frame while leaving the old frame active. (bug; change by Elena Sagalaeva)
• Edit Shapes Tool: After splitting a path, allow moving the new point immediately instead of needing to move the cursor to change state. (change by Luna Lovecraft)
• Toolbars: Add icons for 'Quick Group', 'Quick Clipping Group', and 'Quick Ungroup' actions. (change by Arkady Flury)
• Qt6: Transform Tool: Fix perspective transform getting stuck waiting to complete when the transform became concave. (bug; change by Luna Lovecraft)
• Qt6: Windows: Fix the canvas widget being transparent and letting other open documents show through. (bug; change 1, change 2 by Dmitry Kazakov)

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

• Toolbars: Add widgets for the 'Choose Foreground Color', 'Choose Background Color', 'Swap Foreground and Background Colors', and 'Reset Foreground and Background Colors' actions. (change by Arkady Flury)
• General: Allow choosing any installed application style instead of only Fusion, macOS (on macOS), Haiku (on Haiku), and Breeze (on Linux distribution builds). This unrestricts using Windows style (not just on Windows), windowsvista/windows11 (on Windows), and styles available on Linux distro builds. (change by Halla Rempt)

Nightly Builds

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

Note that there are currently no Qt6 builds for Android.

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

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

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn’t as critical.

Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.

Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.

If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.

This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.

But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.

So a way to make this approach more feasible is to reduce your OS’s scope of concern.

For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.

It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.

What’s not the solution?

Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.

This is the worst of all worlds!

• Users get outdated software that’s full of bugs and security holes fixed long ago
• Software developers get un-actionable bug reports from angry and confused users
• Distributors get frustrated communications from software developers that damage or destroy important relationships

Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.

How do I know this?

Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:

In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.

In 2026, they’re up to 71%.

This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.

So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.

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.

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 ☺️

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

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!

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.