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

People tend to think an icon is a single drawing.

One thing I think people miss (or at least some do) is that an icon isn't really one icon at all.

The KRecorder microphone above exists as several different versions depending on size. In total that's 16×16, 22×22, 32×32, 48×48, 64×64, 128×128 and 256×256 PNGs, plus a number of SVG versions (6 six more files ). And don't always stop at 128×128 for the vectors either. Sometimes I end up making much larger vector versions simply because I want the extra detail to be there. (I have issues )

Talking about "issues"...

I couldn't resist rendering a version at almost 1024×1024 just to see how far I could push it. Look at the metallic reflections in the bottom half of the microphone. I spent a completely unreasonable amount of time tweaking those and honestly... I regret nothing

Which does make me wonder...

Should we ship those absurdly detailed versions too?

Probably not.

...but then again, if somebody wants to inspect an icon at 1024 pixels wide, who am I to stop them?

...but maybe.

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

The Akademy 2026 Program is now live!

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

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

The schedule highlights:

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

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

Venue & Registration Details:

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

15 Jul 2026 7:00am GMT

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

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

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

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

Actually running the thing

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

Two decisions shaped it.

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

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

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

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

Knowing when to shut up

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

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

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

Three bugs, none of them the model's

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

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

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

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

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

And then: "last year" meant 2022.

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

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

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

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

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

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

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

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

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

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

So I vendored it. And pushed. And:

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

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

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

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

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

Seventy-eight seconds

The bug I'm most glad I chased.

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

TIMING: generated 22 tokens in 78012 ms

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

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

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

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

CMAKE_BUILD_TYPE:STRING=Debug

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

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

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

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

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

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

The line I promised to come back to

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

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

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

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

The fix is the single line from the snippet earlier:

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

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

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

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

What I actually learned

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

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

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

Key takeaways

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

Where things stand

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

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

What's next

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

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

14 Jul 2026 8:33pm GMT