My post about responsibility for bug reports on old software versions the other day stirred up quite some discussion, and I wanted to drill a bit more into what I think is the crux of the dispute: the difference between legal obligations and the social contract.

---

When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: "make the source code available," "don't change the license," and so on.

You might also notice the absence of a warranty, or silence about responsibility for bug reports.

So let's return to the question:

Who's responsible for bug reports on old software versions?

An accurate legal reading is "Nobody, unless you've signed a work contract with a developer or purchased a commercially-sold OS." But it's also not the whole picture, because there's another potential non-obvious legal obligation:

Trademark

Trademark law varies across the world, but at least where I live in the USA, "unregistered trademarks" are a thing, and in a professional context, you've got a legal obligation not to violate a product's trademark - registered or unregistered - by referring to it as something that it isn't, or changing it and saying it's still what it originally was.

Ah, but how much to you have to change it before that kicks in? That's definitely not something that I - a non-lawyer - am qualified to assess. And my understanding is that this varies a lot across the world's legal regimes, too.

But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer's own bug fixes) probably doesn't count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.

Which brings me to what I think is the most important part:

Doing only the legal minimum

"Follow the terms of the license agreement." "Don't mis-represent trademarks you don't control." "Don't steal." "Don't murder."

These are good places to start. But what if that's all anyone ever did - the bare legal minimum?

I think the world would be a pretty miserable place. There's no law requiring anyone to love you or soothe your feelings when you're upset. There's no law requiring you to find a source of joy or direction in life, or help others unbidden.

What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.

Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you'll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.

Applying the social contract to this situation

Let's say that I write an app, and someone distributes it with a feature patched in that I didn't write, or a visual change that I didn't make. How mad at them am I going to be?

If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they've created what I believe to be a derivative work that reflects poorly on the original.

No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.

But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I'll even reach out and ask them to submit their change upstream and help maintain it. There's a 0% chance I'm going to threaten to invoke trademark law or give them a hard time about it.

That's the power of respecting the social contract that exists between us.

But what is the FOSS social contract?

Like the definition of "derivative work", it's unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can't contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the "FOSS social contract":

Using FOSS

• If you didn't pay any money, appreciate what you've gotten for free. It's a modern miracle.
• Understand the basic software lifecycle of the OS you're using, and choose the one that suits your needs the best.
• Accept the "no warranty" clause. Understand that support may be slow, and that if you need it fast, you'll need to pay for it.
• If you don't like the software you're using, use something else.

Bug reporting

• Endeavor to report bugs in the right place, to the best of your ability.
• Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.
• Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.
• Treat people kindly with the benefit of the doubt, even if they don't respond to your bug report in a timely manner, or at all.
• If your needs are urgent, pay a person or company to address them; don't make demands of people working for free.

Software development

• Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don't ghost people.
• If you aren't distributing your own software in a way that's suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren't doing it in exactly the way you would prefer.
• Work with your distributors to help them showcase your software in the best light. They don't know it as well as you do.
• Don't piss off too many of your users. You're doing this for them, not just for yourself.
• Only make your software publicly available via a FOSS license if you're willing to accept people using it or distributing it in ways you might not have expected or preferred.

Software distribution

• Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don't ghost people.
• Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.
• Clearly communicate your OS's software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.
• If you meaningfully change the software you distribute (outside of backporting the developers' own bug fixes or similar), accept that you've created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).
• If you distribute software that you know is or soon will be outside of its developers' support window, change the bug report URL to your own, or remove it entirely if you don't have the resources to offer support for old software.
• Only create an OS in the first place if you're willing to take responsibility for the support needs of the people who will use and depend on it.

Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We'd end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it's my hope that we can all aspire towards these ideal with our actions and words.

21 Jul 2026 10:35pm GMT

Minuet is a KDE's application for music education. It helps students and musicians train their ears with exercises for intervals, chords, scales, and rhythms. Minuet 26.08 is shaping up to be a particularly exciting release, with new ways to practice, a redesigned interface, and support for more platforms. We would love your help testing these changes before the final release. Try the exercises described below, explore the application on your devices, and tell us about any problems you find.

CI builds are beta snapshots rather than finished releases, so please do not rely on them for important work. Installation instructions are at the end of this post.

A redesigned, responsive interface

Minuet has a new interface built to work well on both desktop and mobile screens. The home page and navigation drawer make exercise categories easier to find, while the exercise browser presents each activity as a card with a short description. Your current category remains highlighted, and the new search field filters exercises by their translated names and descriptions. Exercise pages have also been reorganized to use the available space better on narrow windows and phones.

Things to test:

• Browse every category from the drawer and return to the home page.
• Search using full and partial exercise names, descriptions, different letter cases, and your system language.
• Check the empty-search-results message and clear the search afterward.
• Resize the window from very wide to very narrow and look for clipped controls, overlapping text, unnecessary scrollbars, or lost navigation state.
• Try keyboard, mouse, and touch input where available, as well as both light and dark color schemes.
• Answer questions correctly and incorrectly and check the answer animation, keyboard, staff, and controls.

The new exercise browser with several descriptive cards visible and a search term entered in the drawer

Guides for first-time users

The first melodic, rhythmic, singing, or clapping exercise you open now offers a short interactive guide (based on new Kirigami-addons onboard module). Each guide points out the controls and feedback relevant to that type of practice. You can decline the guide, finish or cancel it, and open it again later with the Help button.

Things to test:

• Accept and complete each of the four guides: melodic, rhythmic, singing, and clapping.
• Choose Not Now, leave the exercise, and confirm that Minuet does not repeatedly interrupt you.
• Cancel a running guide and check that the exercise returns to its normal state.
• Start a guide again from the Help button after completing or declining it.
• Check that callouts point to the correct controls at different window sizes.

An exercise page with an onboarding callout highlighting the answer controls

More control over practice and sound

The new settings page gathers Minuet's everyday controls into Practice, Sound, and Microphone groups. You can change exercise speed, rhythm tempo, the number of rhythm patterns, test length, playback volume, melodic instrument, and percussion sound. Singing and clapping settings include the microphone input, voice class, pitch tolerance, timing tolerance, and calibration guidance. A collapsed Advanced section exposes detection algorithms and thresholds for difficult microphones or noisy rooms, with an option to restore the defaults.

Settings are persistent, so your choices should still be present the next time Minuet starts.

Things to test:

• Change each basic setting and confirm that the next exercise uses the new value.
• Select instruments from different General MIDI groups and try several percussion sounds.
• Restart Minuet and confirm that your choices were saved.
• Test microphone selection with no input device, one device, and multiple devices if possible.
• Expand and collapse the Advanced section, adjust its controls, and use Reset to Defaults.
• Check helper text, control labels, ranges, keyboard navigation, and layouts on narrow screens.

The settings page showing the basic controls sections

New melodic-interval exercises

Minuet previously separated ascending and descending melodic intervals. The new Melodic intervals collection mixes both directions, requiring you to identify the interval itself rather than anticipate its direction. It includes focused groups such as seconds or sixths, combinations such as fourths and fifths, and broader challenges covering compound intervals all the way through the fifteenth.

Things to test:

• Confirm that questions include both ascending and descending intervals.
• Work through focused, mixed, and compound-interval groups, including Second to 15th.
• Replay questions and compare what you hear with the piano keyboard and staff.
• Check enharmonic spellings, accidentals, ledger lines, answer choices, and scoring.
• Start and stop a test run and verify that its length matches the configured number of exercises.

A compound melodic-interval question with its notes visible on both the staff and piano keyboard

Read and sing

Intervals and scales can now be practiced with your voice. After you choose Read and sing, Minuet plays a count-in and a reference note, listens through the microphone, and compares your pitch and timing with the target. The exercise view provides live input, pitch, and onset feedback. Scale exercises extend the same feedback across a complete sequence of notes.

Things to test:

• Sing intervals and scales in each voice class: soprano, alto, tenor, and bass.
• Try accurate notes, notes that are deliberately sharp or flat, early or late entries, and incomplete scales.
• Change the pitch tolerance and confirm that the result becomes stricter or more forgiving.
• Calibrate silence in a quiet room and with moderate background noise.
• Try built-in, USB, and Bluetooth microphones where available, including switching devices while Minuet is running.
• Deny and later grant microphone permission on platforms that request it.
• Check that the interface remains responsive while audio is being analyzed.

A scale-singing exercise showing the target notes, live input meter, and pitch feedback

Read and clap

Rhythm exercises now offer a Read and clap mode. Minuet displays a rhythm, gives you a four-beat count-in, records your claps, and compares their onsets with the expected beats. The view includes an input meter, silence calibration, and timing feedback, while the settings let you tune the accepted timing tolerance.

Things to test:

• Clap easy and medium patterns at slow, moderate, and fast tempos.
• Try clapping exactly on the beat, near the tolerance boundary, and deliberately early or late.
• Add, omit, or double a clap and check that the feedback identifies the mistake.
• Change the timing tolerance and verify that scoring changes accordingly.
• Calibrate in quiet and noisy environments and watch the input-level meter.
• Check that the count-in finishes before Minuet begins evaluating your claps.

A completed clapping exercise with the rhythm cards, input meter, and timing feedback visible

Rhythms with rests

New Easy with rests and Medium with rests categories mix sounded notes with silent positions. You can identify these patterns by ear or read and clap them. In listening mode, Minuet avoids presenting answer choices that would sound identical; in clapping mode, every note-and-rest combination remains available.

Things to test:

• Listen to easy and medium patterns and verify that notes and rests occur in the displayed positions.
• Check that the available listening answers are audibly distinct.
• Clap through the rests without adding sounds and confirm that silent beats are evaluated correctly.
• Replay patterns, vary the rhythm tempo and pattern count, and try both single questions and test runs.
• Look for incorrect rest symbols, spacing, playback duration, or answer evaluation.

An Easy rhythm question containing several clearly visible rests

Minuet on more devices

Minuet's interface and audio stack have been made more portable. Android builds now use FluidSynth and share the same streamlined interface as the desktop version. macOS builds are available for both Intel and Apple Silicon, with fixes for application data, translations, icons, audio, and microphone permissions. This cycle also introduces initial iOS build support, although iOS packages are not yet published by the CI pipeline.

Things to test:

• Install, launch, close, and reopen Minuet on as many supported devices as possible.
• Check the application icon, splash screen, About page, system language, light/dark theme, and screen rotation where applicable.
• Run listening, singing, and clapping exercises and check playback, latency, recording permissions, and device selection.
• On mobile, test drawer gestures, the on-screen keyboard, compact layouts, safe areas, and back navigation.
• On macOS, compare Intel and Apple Silicon builds if both kinds of hardware are available.

Minuet's home shown side by side with desktop and mobile form factors

Under the hood

The visible changes are backed by a substantial technical update. Staff rendering now follows the Standard Music Font Layout (SMuFL) metadata from the Bravura music font, improving the placement of noteheads, stems, accidentals, ledger lines, clefs, and braces. FluidSynth support has been improved across platforms, while Aubio microphone analysis runs in a worker thread to keep the interface responsive. The QML and C++ code has also been split into more focused controllers and components, and automated coverage has grown for exercise evaluation, rests, audio analysis, and settings.

Things to test:

• Inspect simple and dense notation, including chords, accidentals, compound intervals, ledger lines, treble and bass staves, and narrow layouts.
• Listen for missing notes, wrong instruments, stuck sounds, timing drift, or audio that continues after leaving an exercise.
• Navigate rapidly between exercises and settings while audio is playing or the microphone is active.
• Run long singing and clapping sessions and watch for freezes, delayed feedback, excessive CPU use, or crashes.
• Check that existing chord, scale, interval, rhythm, test, replay, and give-up workflows still behave as they did before.

A dense staff containing a chord, accidentals, and stems

Installing a CI build

Open the list of successful release/26.08 pipelines and select the newest pipeline. On its Jobs page, find the deployment job for your platform and use its download-artifacts button. Extract the downloaded ZIP archive before following the platform-specific steps below.

Artifacts are temporary: the Windows, macOS, and Android packages normally expire after three days, and the Flatpak packages after seven days. If a download is no longer available, return to the pipeline list and choose a newer successful pipeline. These packages are development snapshots and may trigger warnings about installing software outside an app store.

Linux

1. Download the artifact from the flatpak-amd64 job. The archive is named Flatpak_artifacts.zip.
2. Extract the archive and open a terminal in the extracted directory.

Launch Minuet from your application menu or run:

flatpak run org.kde.minuet

To test translations, also install the locale bundle:

flatpak install --user ./minuet-locale.flatpak

Install the application bundle:

flatpak install --user ./minuet.flatpak

The archive also contains minuet-debug.flatpak, which is useful for debugging but is not required for normal testing.

Windows

1. Download the artifact from craft_windows_qt6_x86_64.
2. Extract the archive and open its kde-ci-packages directory.
3. Run the included Minuet installer and follow its prompts.
4. If Windows displays a security warning for the development build, review the publisher and file details before choosing to continue.

The CI package targets 64-bit Windows on x86-64 processors.

NOTE: audio drivers are particularly worse on Windows, you can find some false negatives on such platform when compared to Linux, Android, and macOS.

macOS

Choose the job that matches your Mac:

• craft_macos_qt6_arm64 for Apple Silicon Macs;
• craft_macos_qt6_x86_64 for Intel Macs.

Download and extract the artifact, open kde-ci-packages, then open the included Minuet disk image or package and install the application. Because this is a development snapshot, macOS may show a Gatekeeper confirmation the first time you open it. Please also check that Minuet requests microphone access when starting a singing or clapping exercise.

Android

Choose the package matching your device:

• craft_android_qt611_arm64 for most current phones and tablets;
• craft_android_qt611_x86_64 for a compatible x86-64 device or emulator.

Download and extract the artifact, locate the Minuet APK in the package directories, and open it on the device. Android may ask you to permit installations from the application that opened the APK. Review the prompt, install Minuet, and disable that permission again afterward if you do not normally sideload applications.

Alternatively, developers with Android platform tools can connect a device or emulator and run:

adb install /path/to/minuet.apk

If an older development build is already installed and Android rejects the update because its signature differs, uninstall that build first. This removes its local Minuet settings and data.

iOS and FreeBSD

The 26.08 branch contains initial iOS support and is checked by the FreeBSD CI build, but the pipeline does not currently publish an installable package for either platform. The download instructions above therefore cover Linux, Windows, macOS, and Android only.

Send us your results

Please report bugs through KDE's Minuet bug tracker. Include the pipeline or commit you tested, your operating system and hardware architecture, clear steps to reproduce the problem, and what you expected to happen. For singing, clapping, or sound problems, microphone and audio-device details are especially helpful. Screenshots, short screen recordings, and relevant terminal output can make layout and audio issues much easier to diagnose.

A special shoutout and thanks to the KDE Sysadmin team for handling dependency additions, regenerating the CI images, and providing support with all the required CI/CD infrastructure.

Thank you for helping us make Minuet 26.08 a solid release for music learners everywhere!

21 Jul 2026 4:41pm GMT

This post has been long overdue, but let's say I've been busy and the reason will be obvious in this short piece. ☺

As you might have heard a couple of months ago, the Sovereign Tech Fund did a large investment in KDE software development. From the announcement the details can be a bit sparse on what it actually entails. Especially regarding the part which says "the frameworks underlying its communication services". It turns out this is what enioka Haute Couture is contracted by KDE e.V. to work on. Let me bring a bit more details about it.

What? Why?

The overarching theme of the investment is to make the KDE ecosystem more desirable for enterprise and public institution uses. The desktop shell (Plasma) and having a strong base to distribute it (KDE Linux) obviously comes to mind, but it's also about the Personal Information Management (PIM) space. Nowadays a good chunk of the institutional life (public or otherwise) is to deal with email, contacts and calendars. So we set sail to strengthen Kontact, KMail, Korganizer and friends. More specifically, we want to strengthen its underlying infrastructure: Akonadi and its resources.

So what exactly are we working on currently? Well, I propose you attend the Akademy 2026 talk of my colleagues which will cover what we do on KDE PIM!

The Work

OK, OK, you're still here? So read on for a few more details even though I obviously don't want to steal their thunder.

There are three axis we're focusing on:

• Quality
• Protocol support and modernisation
• Ease of use and deployment

Quality

Those who know me also know what it means: more tests!!!

To be fair on the Akonadi server and resources side, we're not too bad in terms of unit tests. The underlying protocol libraries as well have some unit test. The DAV side is maybe a bit weak and we hope to fix that, but on the IMAP side things aren't too shabby.

That being said, we didn't really have a test suite which would cover all the components integrated together. Those are more expensive and less fun to develop, so we'd be working on that by adopting a proof of concept done by Dan Vratil a while ago. It changed quite a lot but is becoming stronger with a comprehensive test suite covering IMAP and DAV.

Unsurprisingly it uncovered quite a few bugs we didn't know about before starting the work, and gave us a nice environment to reproduce long known bugs that we had a hard time to chase down previously.

Of course, we're working through the list of failing tests to fix everything we can. Some of my long hated bugs are already gone! Well, I use the master branch… so I live in the future from you dear readers, and the future is definitely better here.

Protocol Support and Modernisation

Our PIM suite supports many protocols… but in the case of enterprise use in a sovereign context (so having some control on the server side, and using open protocols), IMAP4, CalDAV, and iTIP (for invitations) are kings. So we're focusing on modernising our support for them.

In particular we're aiming at better support of IMAP4rev2 enabled servers, but also QRESYNC. This should bring a better use of network resources and faster resync.

On the DAV side, we're looking at supporting push notifications. This is currently not completely standardised but we'll be ready as soon as it is. Everything will be in place to track the specification as it matures. Thanks to this work, we'll also improve the syncing code of the DAV resource, again using less network bandwidth.

Obviously iTIP support benefits from both. It also highlights issues on the DAV support which we're fixing as we find them.

Ease of Use and Deployment

The architecture of Akonadi means that a user setup of the solution has quite a few components to configure. This is not necessarily a problem in itself, but we could make things easier and at times it's mostly about configuring each protocol manually and separately.

Of course, there's a specification proposed to support autoconfiguration based on just an email and a password. We got some partial support for it in KMail, but we'll work on completing this and bringing it closer to System Settings. Couple that to some device management facilities in say… KDE Linux and that starts to look like a strong proposal for enterprise.

Finally, we'll look into the Flatpak version of our PIM suite and see how to make it easier to integrate in the desktop. The possibilities are fairly limited for now and we'd like to make it first class going forward.

What to Expect

Obviously for the time being we can expect more activity in KDE PIM which is good. We have quite a few patches in the PIM repositories at this point and some of the improvement will be released really soon as part of 26.08! Some more will come in the next release (26.12) of course but it still required too much QA and missed the freeze. No matter, it's not a long wait.

Also, we hope that it'll be easier to deploy and setup when we get to tackle the Flatpak related tasks. Really looking forward to this! We hope to deliver this by the end of the year or early 2027. Which would mark the end of the project for us.

Later on, I hope this infrastructure work will attract more users and contributors again. Indeed, there's still interesting work needed on the application side of things, but if the protocol support and quality of the base system is stronger, it makes it easier to try new things with the applications, less pieces to fight with will make the whole endeavour more desirable.

21 Jul 2026 7:06am GMT

Tuesday

I arrived at Nuremberg after a very long travel and nearly no sleep, so I didn't go to the "warming up" party in the bar, but instead met up with C. and we went to a Balkan restaurant (Balkan Spezialitäten) for dinner. We got Cevapcici sausages with some kind of bell pepper sauce (called ajvar) and some sort of sour cream (kaymak, which confused me greatly since in Poland it's a name for a sort of caramel) on the side, with some very nice bread (börek). The food was fine, but not amazing. But the restaurant was pretty quiet, probably because it seemed to be more focused on locals than tourists and it was pretty small, so we could talk.

Wednesday

State of Libre Graphics by MABarbe

The first actual day of LGM started a bit late, at 1 pm, but I used all that time in the morning just to sleep. First item on the agenda was the State of Libre Graphics, which is always exciting since you can learn about many small projects you don't know existed.

Some of the projects that are quite interesting:

• Blockbench - a simpler 3D modeling tool, made for low poly models, with painting tools and even animation. They have a partnership with Mojang, which uses Blockbench for models for Minecraft, and with Hytale so it becomes the main modeling tool for the modding community.
• Coollab, Processing, p5.js and OpenRndr - they all seem to do roughly the same thing, which is procedurally generated 2D graphics. Coollab seems to be a software with a node editor, while others seem to be libraries you can use to code the graphics. I haven't explored them enough to know for sure what would be differences in how they work; I have only seen how OpenRndr works, and it seems like it's a coding library in Kotlin which spawns a window with the graphics you coded. It also has some capabilities to make a GUI in that window.
• Friction - a motion grahics software, I believe that's an alternative to Natron and Adobe AfterEffects.
• Glaxinmate - a 2D vector animation tool. It's still in version 0.6.0, and it's part of KDE.
• Graphite - a software for vector graphics and animation. It provides morphing between shapes, it has both layers-based compositing and node-based generation of graphics. And it's supposed to release 1.0.0 version really soon. (Seems already more advanced than Glaxinmate).
• Pixiv - another node-based pixel art and animation, both frame-by-frame and generated
• OurPaint - a digital art software, it has some elaborate pigment implementation.
• Hyper 8 - if I understand correctly, it's a static page generator (like Hugo, which is what Krita's website is built on), except focused on videos. It has browsing, searching, playlists, localisation, collaborative editing, and interactive searchable transcripts, and all that while promising the setup to be really easy, not requiring any database, programming nor maintenance, and compatible with all webhosts.
• Ladron de Flores - that's actually a movie that uses lots of FOSS software like Inkscape, Krita, Opentoonz, Kdenlive, Audacity and Aegisub (a subtitling tool).
• Ossia Score - a software for live art installation
• Stellarium - desktop planetarium, it is used now in Vera C. Rubin Observatory
• TiXL - realtime/live motion graphics (which I guess makes it similar to Ossia Score?)

Trying out Blockbench

After the LGM I went through different projects to check them out; I already made a voxel lamp in Blockbench and imported it into Blender. It took very little time to achieve this result. With polygonal editing, I had a bit more trouble, especially since Blockbench has alt-clicking for some shortcuts, and that of course causes trouble on my Linux. I really hope I'll get a hang of the polygonal editing too, since voxel editing is still a bit tedious (especially since I don't really see a way to merge the cuboids together), but if not, it's still great.

Trying out PixiEditor

I also checked out PixiEditor. Not gonna lie, the website and the software itself looks really fancy and modern. You can clearly see the modern web influences in the design. The Steam page looks pretty good too. You can see that the people working on it know what they're doing. There are also some fun quirks of the interface; there is for example a mushroom guy who's giving you tips like the old Clippy, but more adorable, and some text in GUI that clearly shows that it was written by a Polish person that is also not the overly formal language you see in Krita (for example "Ale tu pusto!", which means roughly "wow, how empty is this space!" on the empty list of projects). It also has quizes on the documentation page to check your understanding of the topic. Makes learning the software more fun and makes the software itself look more casual as opposed to formal and stiff.

For painting it's still a bit limited because it doesn't have many ready-made brushes; I think there is only six of them. I knew there is some node-based engine within so I duplicated a brush, edited it, and finally found a way to the node editor, and I have a bit of mixed feelings about it. Obviously it's amazing to get nonlinearity, but I have this impression every time I actually try to do something with nodes that it's a very inefficient system of writing that nonlinearity. In PixiEditor it's of course still a new system, so you can't expect it to be already perfectly adjusted for optimal use and I've never actually used any node system extensively, so I'm not a good judge of it. It looked promising, though, so I want to try to make some of my favourite brushes there to test the painting side of it properly. Layers system is also node-based (more specifically, a proper directional graph, instead of a tree like in Krita with Clone layers introducing a bit of nonlinearity). I haven't really explored the full potential of the software yet.

Freeze+Press - talk by Christoph Haag

Freeze+Press seems to be a small printing workshop of sorts that is focused on experimental printing and using FOSS and CC. Currently they have a website where you can buy some stickers (ImageMagick's wizard, git's logo, broken image logo, the Canonical tiger), posters and books. A portion of the talk in the beginning was about Christoph's own story in FOSS and graphics design and how Freeze+Press was created.

The elephant in the room: who owns the rights to an image? - talk by Eylul Dogruel

After the coffee break, there was a talk by Eylul with a title "The elephant in the room: who owns the image?" which was, how you can guess, about AI generated images. I highly recommend you to watch the recording on the Chaos Computer Club website: https://media.ccc.de/v/lgm-2026-110662-the-elephant-in-the-room-who-owns-the-image.

At first, she changed the question into "Who owns the monkey-generated photo?", and I understand that it might be similar from a legal standpoint, but for me, that's not a good analogy, because monkeys are sentient. It would be more comparable to a baby taking a photo, or maybe a intellectually disabled person (since a baby would grow up to become an adult with all the rights and capabilities), taking a photo. From that standpoint, imho the owner of the image is that person or that monkey, and since they can't represent themselves, then the guardian should represent them and control the copyrights. That's of course all completely not applicable to an AI… Monkeys aren't trained on stolen images, monkeys also aren't blindly generating average photos out of all the photos they've been trained on. In case of AI, the AI is the combination of all that stolen data. A monkey might have an owner or a conservation organisation that should handle their copyrights; but AI was created by the company that owns it, from all the pieces of stolen data. There is, unsurprisingly, a lot of differences between a monkey and an AI.

It's a shame the time for questions was so short; I could imagine quite a long discussion about it. I also noticed that, in general, there is a bit of disconnect between the way artists and programmers see AI; and since LGM is sort of a mix of both (when some days layer someone asked who is an artist and who is a programmer, nearly all people raised hands to both questions), you could see voices from both sides. Artists are usually (not always) very against AI on ideological basis, while programmers often just see it as more of a tool.

ctx vector desktop - rasterizing as late as possible - talk by Øyvind Kolås

The next talk was about a ctx vector desktop. I'm still not exactly sure what it is, but it might be because it seems to be many things at once. The main part is a software rasterizer for vector graphics, and everything else seems to be something on top. There is a terminal that is capable of ctx vector graphics and also audio (the terminal itself also written to use ctx), there is a protocol that you use in the terminal to draw the vector shapes, and of course the vector rasterizer itself that later combines it into raster so the downstream (a display server?) can render it as it usually renders all windows. I might be wrong though. If it seems interesting, go watch the talk, Øyvind surely explains it better and without the confusion I have.

Beginner-friendly shader programming in p5.js v2 - talk by Kit Kuksenok

P5.js is a Javascript library that is used for making procedural art, but also focused on teaching users how to code. For the 2.0 version they want to simplify the API for shaders even more so that the user can start coding and making art with as little previous knowledge as possible.

The part of p5 for shaders is, I believe, called p5.strands. The user doesn't have to define their shader completely, doesn't have to know how the lights work or anything, instead they can add modifications over a default shader. It's also written in a way that is familiar to users who used p5.js sketches (which art programming still on CPU). The point of it is that users get familiar with shader programming concepts while still using more familiar syntex. P5.js also supports proper GLSL shaders, so they are also available for more ambitious students.

Phosphor for Tectonic Typefaces - talk by Émile Greis

The last talk was about Tectonic Typefaces in Phosphor. If you are, like me, unfamiliar with font-specific lingo, a tectonic typeface is a kind of typeface that's composed out of usually same-shaped small elements, usually dots. It gives the typeface this blocky appearance. I think all pixel-art typefaces could be defined as tectonic typefaces. The main point is that it can be defined as a table with some cells being filled and some not. Then the rendering can be more creative, you can add slopes and rounded edges and different sizes for different cells. Looks pretty interesting, though I can imagine that it's pretty niche.

Dinner time

After the talk there was a photowalk planned, but I was at the (very brutal) photowalk the previous year, and I knew going to the castle meant quite a lot of workout, because it's on a steep hill, and that would probably just be a part of the attraction, so I decided to skip it.

For dinner we went to Tucher Mautkeller on the Mauthalle street, hoping for better food and maybe some space to talk as well, but it was unfortunately very loud (and quite expensive). I ordered the salmon trout on spinach with rosemary potatoes, and a side salad. The side salad was definitely not a side salad, and not very great either, but the fish was great.

Thursday

Re:WIRE workshop

On Thursday there was a workshop focused on the past and future of the LGM. I made some notes about the past. The future was still discussed later on BoF and the workshop on Friday.

(This was a place where I wanted to include a photo of a page of the first issue of the LGM magazine, because it contained some funny information about Krita and Gimp I think; unfortunately, I couldn't take the photo at the moment I saw it, and then I forgot. I also took some notes about the history of LGM, but maybe I'll write about it next time).

Lunch

For lunch we went to grab something easy to eat from the main train station. I found an amazing chicken wrap in one of the stores in the food court there (place called Dean & David, the wrap was called "Chicken & pesto", 4.95 euros, I bought two more for my travel back and it was so worth it).

Soldering workshop with Simon Budig

Later we went to the soldering workshop. I signed myself as intermediate, even though I've never held a soldering iron in my hand before (but how hard can it be, right?). The theory is relatively easy, but we started from the resistors, which are incredibly tiny and finnicky to solder onto the board. First you had to heat up the tiny pad on one side, and then put solder on it so a tiny bit of melted solder stays there; then, using tweezers, put the tiny resistor in between the two tiny pads, and finally heat up the other pad and add some solder to it. The next step was adding LED bulbs; they had a much longer "legs", so you in theory didn't need to be as precise anymore, but they had a tendency of bouncing off of the board when you weren't looking, and keeping both legs flat on the board wasn't that trivial. Unlike the resistors, they also had a correct and an incorrect orientation: you had to make sure to solder the shorter one to the pad marked with L. Thankfully I didn't make that mistake. For the "spider" with a switch, the only difficulty was that you can only heat up one pad and one drop of solder at once, so preparing all three pads on one side is a mistake. But it was still managable. The last part was the battery holder, which wasn't really complicated, though for that you needed an inside knowledge that you can heat the holder's pad up from inside of the holder after putting the solder on the pad, which binds them together. I think I did it correctly the first time, actually, but I wasn't sure, so I redid that part (and getting a battery was tricky, so I only checked with battery after everything was done). I also had to redid one of the LED bulbs since one of the legs jumped out of the solder. But all the lights worked correctly the first time I put the battery in. Hurray! Full success. (Just don't look at the finished board).

The soldering workshop was located in a reception area of a local theatre, because the venue didn't have appropriate fire safety certification or something. We did have to remove some carpets from the floor though. After the workshop, I tried to teach M. and C. how to play Star Realms with Polish cards; we were sitting among all the chaos, so it was of course a disaster. The main rules were explained though. No one won, because we had to finish abruptly when the workshop ended and there was time for cleaning up the space.

There was a group photo made during the coffee break.

Gimp: A community, free software - a talk by Jehan

Last year I could see for myself how Inkscape works and organizes themselves, so I hoped to learn the organisational structure of Gimp this year as well; the talk was good, but I hoped it would go a bit more into details. Then, of course, I spent a whole day with Inkscape (which was delightful) and Gimp only had 20 minutes to describe themselves. One of the things I noticed is that they have a lot of success with their GSOC students, with most students becoming regular contributors after the project ends. I think we can still improve on that aspect in Krita.

Dinner time

Later me and some others went to a burger place near the main road in the Old Town. I got a classic one, it was pretty nice. We talked about so many things - definitely a bit about AI, about an illustrator, who lost nearly all of their commission work (presumably to AI), about more ethical AI projects, and then of course NFTs, and then finally stumbled upon pigments mode for digital art software (and color management in general). And that lasted the next two hours. There are three separate topics in it: one for proper color management and what is really even is, one for HSX "models" which are just coordinate systems for the RGB color space (so they change depending on the RGB profile you're using, but there are better and worse ones for different purposes), and the last one, for the pigment mode.

Friday

Counterpunch Font Editor: Faster, Safer Complex-Script Design - talk Yanone

Counterpunch is a font editor with a great name. And it was made by a person who designed font that Krita uses for its logo. It's browser-based and I can't really tell you much about it, because I haven't made a font in my life, but it's in alpha and apparently it fixes some issues that other font editors often have.

ReWiring the Video Editor - Timeline as a Node, a talk by MABarbe

MABarbe did an amazing talk about a new concept for a video editor, node-based, but also with timeline (or more precisely, timelines, since it is a node and you would be able to have multiple of them at once). It would have some auto-adjusting capabilities so if you want to just reorder clips, even if they are not the same length, you can just switch them around and the rest of the timeline will be adjusted to the new state automatically. MABarbe also said that the common workflows should all have their own nodes with GUI instead of requiring users to fight the node system for something it wasn't meant for. I was very impressed with this idea; I have tried to use Kdenlive, and even when I knew exactly what I wanted to do, it was not that trivial to use it with the rigid timeline system. Of course I'm not really a video editor and I don't even know Kdenlive that well, but the system M. was talking about just seemed more suited for the way I'm thinking about video editing (my internal paradigm).

It's all still in the idea phase, there isn't even any proof of concept, but I (a layman) was convinced. I wonder if it would be possible to implement it into Friction or Natron instead of a brand new software; but that of course depends on many things.

Lunch

On lunch we went to a falafel place. I got a classic falafel sandwich, while C. got the Arabic one, which turned out to be cut into 6 or 8 pieces and served in a takeaway salad bowl. It was fine, though I felt like it would benefit from more tomatoes. At the end of the break, I tried to rehearse my lightning talk, but I didn't manage to say it in full. It was very nice that people wanted to listen to it, though, since they were bound to hear it again very soon.

Live Coding for Artists and Designers - workshop by Abe Pazos Solatie

The workshop about OpenRndr was very interesting. Such a shame I didn't bring my laptop. M. was sitting next to me though, so we were sort of coding together. To get OpenRndr to work, you need to install IntelliJ Idea (to get Kotlin), and then just downloading the template project from the git repository of OpenRndr. The full guide is here: https://guide.openrndr.org/setUpYourFirstProgram.html. The language looked quite alien to me at the first glance, but I had to be brave and act as an expert to M. (who doesn't know much programming at all) and explain what things mean when I still wasn't exactly 100% sure yet. But, ultimately, it's just a bit different syntax, that's all. You just need to know what to put where, and having an example source file, you could guess quite a lot. (Turned out that most of the confusing syntax was just lambdas over lambdas with brackets being an unnecessary part of the syntax in those cases, therefore omitted, therefore nothing looked like normal functions).

What's interesting about OpenRndr is that apparently unlike other live coding projects, when you create shapes, you can take them in vector form and apply all sorts of transformations and calculate more things from them. For example when you create a contour from a set of points, you don't just get to draw that contour, you can get the vector shape characterised by that contour and for example add arrows representing normal vectors to it. The program is also interactive, so you can make it listen to mouse clicks and for example change colors. It also knows the passage of time, so you can animate the shapes. There is a lot of different packages it can use, most notably you can also make a GUI for your graphics to, for example, control the thickness of the lines while the program is running. Overall it looked a bit like a game engine, just with a way more 2D vector graphics options. I was considering using it for prototyping some things like a gradient editor for Krita I've been thinking of (with defined curved lines across the HSY space).

Which also reminded me of Seexpr library in Krita. Such a shame it's so user-hostile and so limited. I hope that I could someday get into it and implement two important features: being able to output opacity, and using Seexpr as a filter, using the projection of the layer below as a base. If those two things are done, then we'd have to make the GUI less user-hostile. Maybe someday we could have an easy-to-use shader layers in Krita.

Lightning talks

I won't be describing each lightning talk, but there was one that caught my attention. It was an ad-hoc talk about mental health. Started very well, encouraging the atendees to take care of their mental health. I totally agree, that's a very important topic, something that everyone needs to pay attention to. But then it went downhill, towards, I'm sad to say, pseudoscience; the speaker mentioned that we have no evidence that the consciousness is formed in the brain (which is untrue, we definitely do have evidence of that) and discouraging people from taking psychiatric medication (which is straight up dangerous).

Especially the last one bothered me, because there are several different disorders that improve greatly from being treated with medication, and many kinds of those medication is proven to work really well. We have good anti-psychotic medication and schizophrenic people really need it. We have good mood stabilizers and people with bipolar really need it. We have good ADHD meds and people with ADHD, maybe for different reasons than people from groups mentioned above, really need it too. And sure, there is a lot of people with depression and anxiety and our antidepressants and anti-anxiety medication isn't as effective as some other medication, but it is still proven to work in a decent percentage of people, and there are multiple kinds if one of them doesn't work on you; and encouraging those people to not take medication is also harmful: especially if someone is easily influenced and stops taking it abruptly. Depression can be deadly and stopping taking medication like that increases the risk even more.

And sure, psychiatry and psychology is still in infancy when compared to standard medicine, because it only started being treated seriously way later. But it's still the best we have, and it contains only and all the things that we know about human psychology. We can't just say "oh but it's not perfectly advanced yet" and discard *the only thing we know for sure* for some feel-good notes and "common sense" theories or "spiritual healing". Discouraging people from seeking evidence-based help can, in my opinion, lead to all kinds of adverse effects. Spiritual healing can always be applied on top of actual medicine.

Of course, that was just a lightning talk, improvised just that day. Still, I think it's an important topic that requires quite a bit of care and foresight applied when talked about.

I also talked about putting your FOSS application on Steam if you're so inclined. If you know a few basic rules on how to do it and follow them, you're going to have a much greater success than if you just used Steam as if it was any other storefront. Unlike any other, Steam will promote you if you gain its trust (or blessing). The main point is that launch on Steam is something you need to prepare for for months, gathering wishlists and polishing the Steam page. Since Steam is a closed platform, you might not want to do that, but if the fact that you can distribute software without DRM there (like Krita and other open source software does; like Blender, Godot, OBS, PixiEditor and probably more I don't know about) is enough, it can be a properly valid source of funding (of course actual amounts depend on so many things… but it might be worth a try).

Liblast 3D asset pipeline - talk by Tobiasz 'unfa' Karoń

The talk about Liblast was mostly showcasing the pipeline for creating assets for the Liblast game (which is a 3D shooter) that allows them to create decent-looking 3D assets pretty fast. I wrote more about the pipeline further down, when talking about the workshop.

Tixl Skill Quest - talk by Thomas Mann

TiXL has an interesting idea for onboarding new users: they created a whole tutorial series in the software itself. TiXL is a software for real-time motions graphics, I believe it's purpose is the same as ossia score. The tutorial seems to be sort of kid wheels for the software, you are guided to do tasks that use more and more advanced features. It reminded me of the Godot's GDQuest's tutorial series.

Design Students Experimenting with Free Software - talk by Lila Pagola

This talk was really interesting. Lila is a teacher in some kind of design school and she tries to open the minds of her students to FOSS software in a pretty creative way. She gives them an assignment to choose one FOSS software that seems like it could be useful for one of their typical design or graphical projects (since they are on very different paths, their typical projects differ significantly, so each student just chooses the one that fits their work), do that task in that software, and then evaluate the software, and I think even the feedback was supposed to be divided into two different categories: actual problems with the software, and issues caused by their lack of familiarity with the software. She said that in the past she just wanted them to evaluate the software on its own, without having a project they have to do in it, and she said it didn't bring much success: students actually using the software was crucial. She also said that after her classes, some students do start to use FOSS software. They are often surprised that it is possible to do things in free software, while up to that point the only thing they knew was one specific "industry standard" program they were required to use for some other classes.

Evening

Before dinner me, C. and M. played Star Realms again, this time successfully, in an empty community area. I was also showing the good quality black pens you can buy in Poland that are perfect for drawing.

Later for dinner me and M. went to the burger place again, taking C. with us. This time I ordered some weird burger with potato chips. It was way too big to eat it the normal way, so I had to split it horizontally in half and eat it with a fork and a knife. I wanted to try it to understand the reasoning for potato chips on a burger, unfortunately, this experience didn't enlightened me. Maybe if I added them myself, they'd add crunch, but that way it didn't really do anything, and the flavour was somewhat lost among all others. So I think it's just a gimmick.

Saturday

Imposition methods for bookbinding - talk by Tom Lechner

Tom Lechner has this very interesting software called Laidout, which is a desktop publishing tool with some vector graphics capabilities. The talk was mostly about various methods of imposition, meaning arranging pages onto physical paper sheets. There are several different usecases, for example when you want to print a sewn together book, you need to print text pages in specific order so when you fold and sew together all the pages, what the reader sees is actually all pages in order. You might want to print a big poster or maybe a sewing pattern on a home printer which only prints up to A4, so you'd want to arrange pages first so you only print the parts you need. Or you might want to print a folded pamphlet, or maybe a sphere-like polyhedron with a map of Earth. It can also be any other 3D shape (from what I can tell), as long as it consists of polygons.

Learnings from Our first 3D Game in Godot - talk motion ensemble (an animation studio) and Alexander Lehmann

I'm writing this part more than two months later, so I don't remember the details, but I couldn't just omit this talk. Or rather, this game. The studio was tasked to make a game for an organisation or institution whose whole job is asking the government for information and bothering them until they give that information. Just paperwork after paperwork. So, they made an incremental game (think cookie clicker, but better) in 3D in Godot (see the screenshot below) where first you gotta write the letter, then print it out, then send it, stuff like that, and each stage is shown with this low poly 3D in a very organic way - you can see every letter, everything. Later of course you can advance and get more funding and buy stuff that makes you faster, and what's best, at the end you can hire more employees, and each and every employee you can hire is a direct representation, with a face, of an employee of that organisation. I really loved this idea. And the game looked fun (at least for the first hour, hard to tell how complex it can really get. The screenshot below is just a small part of of it, of course, but it shows the process of writing, and the stamping).

Lunch

During lunch me and C. stayed in the community area in the venue. We intended to play the game again, but somehow talked through the whole time. For sure we were talking about the Welcome Page widget, and C. was trying to prove to me that converting a 8bit/int image to 16bit/int image in Krita creates incorrect results. Turned out the conversion works fine, but the dialog for the conversion is a bit user-hostile - I believe it's the same widget that's used for creating a new image, and when you switch from 8bit/int to 16bit/int, the default colorspace switches from sRGB-trc to a linear sRGB. That caused difference in rendering. Switching it manually back to sRGB-trc in the dialog and only then converting solved the problem.

Liblast 3D asset pipeline - workshop by Tobiasz 'unfa' Karoń

Later I went to the Liblast 3D asset pipeline workshop. Liblast is a libre multiplayer 3D game. There is an older legacy version and a newer one, with rewritten codebase, still not yet feature-complete comparing to the old one, but much faster. The workshop is about the tools they use to create relatively good using assets in a short amount of time.

The basic idea is relatively simple: use pre-made normal map, automatically applied onto the mesh, for as much of the content as possible. When unwrapping, the script in Blender compares the faces with areas on the normal map and assigns the UVs in a way to add bevels to the edges of the faces. The normal map includes a few different sizes, both square and rectangular, and there are both vertical and horizontal rectangular shapes, so if you later want to for example add dripping paint to the material, the unwrapped UVs are consistent with the orientation of the face in the world (the bottom is always in the same direction). There are two types of bevels, square and rounded, and there are multiple other additions and some space if you want to add something more. You can change the scale between the normal map and the mesh so it fits your mesh best. Sometimes you need to adjust the UVs, either because it's a more difficult framgent (not perfectly rectangular), or for other reasons, and of course you also need to mark the seams. Besides normal maps, there are also some dirt maps and common markings textures (warning markings, metal plaque, this sort of things, because the game itself has an artstyle with a industrial, brutalist vibe).

Tech-wise, the key element of the pipeline is a Blender addon called DreamUV by Braam Eulaers. It requires an atlas. The atlas in liblast case is called "hardsurface_atlas_0". A TexTools addon is also recommended. There are some more maps as well, not just normals.

To test it yourself, first you should watch the talk, then go to Liblast repository: https://codeberg.org/liblast, and download a runnable project here at branch devel-unfra: https://codeberg.org/Liblast/liblast-framework/src/branch/devel-unfa (or maybe specifically at hash https://codeberg.org/Liblast/liblast-framework/commit/a2781c6726255ac026cc8cc5c67ff04c84d5f262). You gotta use it with Godot 4.6.2. For the atlas, go to liblast-assets at branch feature-hardsurface: https://codeberg.org/Liblast/liblast-assets/src/branch/feature-hardsurface or even more precisely, https://codeberg.org/Liblast/liblast-assets/commit/4ca78bd5501f49811c61125f4b5f42632d318aad (they are at textures/hardsurface_atlas_01/export).

UpStage - talk Helen Varley Jamieson

Upstage is a sort of a video call application where you can do a lot of things to the way the main screen is presented. You can add images, text and other elements, you can scale things down, add a background, add a video stream with green screen applied. It can be used for artistic and theatrical installations.

Evening

After the ending we went to the hotel to switch some things up (I wanted to leave the card game there, and get all the warm clothes I could get, and I also made myself a hot tea as well in a thermos cup), and then we went to look for something to eat. We walked past the talafel place, saying that the sandwiches were pretty small, but as we went into the Old Town, I think we, or at least me, started regretting it, not seeing anything suitable to grab to eat on the go.

Finally found a street with many different options. Some people opted for a kebab, but me and K. went for an unsuccessful search for some different kind of wrap. After a few failures, we decided to step into a fast food place with fried chicken. I got a long sandwich and a round sandwich, knowing one fast food sandwich would be too little. There was an option for Polish in the self-order kiosks, but it was clear from the first screen that you should only use it for amusement and not for actual ordering, since the first question, takeout or for eating in the restaurant, had takeout translated to "Podnieść" (which sure, means "picking up" literally, but not only it's a wrong grammar, but also the word is only used for literally lifting things up in the air; the appropriate translation would be "Na wynos". There were several other funny mistakes later, as K. noticed).

The meetup place was a small plaza next to the castle, with a café and many restaurants around. The only trouble was that the floor was paved with a big, uneven, slippery rocks, and the filling in between them didn't reach the top of the rocks, so you couldn't really sit comfortably on it. But it had nice a view, there was a lightened up tree over us, so we spent all time until half past eleven talking. After that we returned to the hotel and, after saying goodbye to M., the rest of us decided to play the game in the hotel lobby. C. really wanted to explain the game, and then he was of course winning again, but with a few carefully directed "a selected enemy discards a card from their hand" cards I took the lead and it started to seem like I might win, but then we had to stop playing since we were all a bit too tired to finish it properly.

Sunday

On Sunday we ate breakfast together and got to the station. I bought my favourite wraps at the station food court (amazing decision). Travel went pretty smooth, despite the fact that I had to use a replacement bus for part of the train journey; thankfully it was sufficiently marked, I got there in time, and I also got to the later train station way before the departure as well. After two trains and one bus I also hopped onto two trams and finally, very late in the evening, got home.

Note: I wanted to write about and describe every single talk, but it was just too much. It's already pretty long.

20 Jul 2026 11:18pm GMT

The Qt folks have taken inspiration in our successful KDE Goals and are starting the Qt Project Goals.

The idea is to select goals that help focus on activities that we believe to be the most crucial for the near Qt future.

Since KDE uses Qt extensively some of you probably have good goals ideas for Qt.

Announce email: https://lists.qt-project.org/pipermail/interest/2026-July/040479.html

Wiki: https://wiki.qt.io/Category:Goals

20 Jul 2026 9:18pm GMT

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

20 Jul 2026 1:09pm GMT

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

20 Jul 2026 12:00am GMT

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.

19 Jul 2026 6:45pm GMT

19 Jul 2026 11:38am GMT

A hotfix release of kf6-core24 to work around a Snapcraft 9 bug that was breaking Qt-based snaps, plus an update on current Debian packaging and snap development work.

19 Jul 2026 12:00am GMT

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

Indoor mapping

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

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

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

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

Balancing requirements

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

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

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

What even is a door?

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

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

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

Outlook

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

18 Jul 2026 6:30am GMT

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

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

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

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

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

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

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

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

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

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

Now, I need to work on:

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

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

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

Thanks for reading! Have a great day ☺️

18 Jul 2026 4:01am GMT

Welcome to a new issue of This Week in Plasma!

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

Notable new features

Plasma 6.8

KWin now automatically applies a shadow, outline, and corner rounding effect to 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.

18 Jul 2026 12:00am GMT

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

---

A Better World

Tags: funny, history, scifi

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

https://abw.blue/index_en.php

This is Still Not Normal

Tags: climate, europe

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

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

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

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

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

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

"Useful" is not sufficient

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

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

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

Let's Talk About the Hardware Reckoning

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

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

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

Do Smart Glasses Have a Surveillance Problem?

Tags: tech, facebook, google, surveillance, hardware

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

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

AI Surveillance and Social Progress

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

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

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

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

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

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

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

The Memory Heist

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

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

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

An update on the scraper situation

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

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

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

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

Tags: tech, graphics, simulation, generator

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

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

The git history command deserves more attention

Tags: tech, git, version-control

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

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

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

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

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

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

Debugging performance regressions

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

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

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

Where did my segfault go?

Tags: tech, unix, shell, system

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

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

Detecting Full Table Scans With SQLite

Tags: tech, databases, sqlite, optimisation, performance

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

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

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

Tags: tech, databases, performance, reliability

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

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

Understanding the Rust hype for the busy developer

Tags: tech, rust, ecosystem, supply-chain

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

https://kerkour.com/rust-hype

Battery packs: Let's talk about crates, baby

Tags: tech, rust, supply-chain

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

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

How Our Rust-to-Zig Rewrite is Going

Tags: tech, rust, zig

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

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

How C++20 improved the for-loop syntax

Tags: tech, c++

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

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

C Strings: A 50-Year Mistake

Tags: tech, c, memory

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

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

What Every Python Developer Should Know About the CPython ABI

Tags: tech, python, api, abi

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

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

Programming Vehicles in Games

Tags: tech, game, physics, simulation

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

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

How my images are dithered

Tags: tech, graphics

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

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

CORS: What is it protecting?

Tags: tech, web, services, browser, security

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

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

A modern HTTP request

Tags: tech, http

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

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

HTMX and Web Components Instead of React

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

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

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

What does "playing politics" mean for software engineers?

Tags: tech, leadership, management, organisation, politics

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

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

Ownership

Tags: tech, leadership, delegation, quality

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

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

Life Hacks for Idiots

Tags: life, satire

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

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

---

Bye for now!

17 Jul 2026 1:28pm GMT

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

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

For example, consider Discord with the current defaults

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

With the new changes, Discord will look as follows

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

How it works

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

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

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

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

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

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

How to add shadows around windows

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

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

Closing words

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

16 Jul 2026 6:45pm GMT

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

16 Jul 2026 9:07am GMT