Skip to content

Thursday, 22 October 2026

A patch-set that removes more code than it adds is always much appreciated. Code that doesn’t exist cannot have bugs after all! KWin, our fantastic Wayland compositor and window manager, like many others, has an Alt+Tab switcher (“tabbox”) for quickly cycling between windows. Of course having been created by KDE, there’s plenty of options for how it should behave and what it should look like.

Flip Switch – a pseudo-3d stack of Windows floating over the blurred desktop
It was the fashion at the time…

A while ago I noticed that the preview feature in System Settings stopped working for full-screen effects like “Flip Switch” (a Windows Vista-like pseudo-3D diagonal list of windows) and “Cover Switch“ (like the good old iTunes Cover Flow). The reason was that they set their Window type to “Popup” which normally makes sense but when loaded into the previewer helper program it had no parent window, so it refused to open. The previews also became increasingly outdated as they included various screenshots of applications.

A horizontal window switcher with large thumbnails, showing: Dolphin, Konqueror, KMail, System Settings
The old preview with fake windows for reference

What if we just made KWin do the preview?

This way it would also use the user’s current desktop wallpaper and whatever open windows there are, removing the need for a fake list and the infrastructure around it. Since you can actually configure a screen edge to trigger the window switcher, there clearly was already a way to bring it up programmatically without the user pressing Alt+Tab. All we needed to add was an interface for the settings module to show the switcher temporarily with the theme to be previewed.

As a result, I was able to remove around 700 lines of code from KWin’s vast code base as well as a Megabyte worth of screenshots. They will of course live on in git’s history but no longer have to be installed to the user’s hard drive.

Tuesday, 20 October 2026

Whether you are reviewing Qt Quick or Qt Widget code with Qt’s agentic skills, you can reduce your token consumption significantly by upgrading to the latest versions while getting the same review quality.

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

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

This release adds a week’s worth of new translations and fixes from KDE’s contributors. The bugfixes are typically small but important and include:

View full changelog

Monday, 19 October 2026

Here are the new CMake changes in Qt Creator 21:

So... this is an "icon".

It's for, a KDE application made by a great friend of mine, Sebas. You might have seen him in. on a video about some thing turning 30 🙂

I spent several days working on this thing. I lost count somewhere after 30 hours. It's a fish covered in disco mirrors, wearing sunglasses and headphones when Sebas told me the app name was seabass, and that it was an app for DJ's ..... Obviously it was going to be this. It had to be done 😀

But, I keep wondering... what is it worth?

Is it worth something because I spent more than 30 hours drawing, tweaking, fixing, and obsessing over tiny details? Is it worth something because it looks cool? Or is it just a silly fish, and all that time was my own problem?

We make a lot of software and art in open source. We give things away, we share them, we let other people use them and build on them. That's one of the things I love about it. But sometimes I wonder if we confuse free with worthless. If something costs nothing, does that mean it has no value? Or can the fact that someone chose to make it, and chose to give it away, be part of what makes it valuable?

I'm not sure there is a universal answer. I don't think value works that way.

Right now, AI tools are still pretty useless for producing the kind of SVG icon I wanted here. You can't even get something that looks vaguely right. So the amount of work behind this image is fairly obvious to me.

But that won't necessarily stay true. Maybe soon they be able to generate thousands of icons with AI.
Using denoising tools and other techniques you probably already can), and then curate them into a complete set. They might not even be SVGs. They might look OK. They might be consistent, useful, and take a fraction of the time.

Would that set have value? heehhh... some??

Would it have the same value as this fish?

Well... that depends on what YOU! value.

If you just need an icon that looks "good", perhaps the answer is yes.

But for me, there is something else here. I know what went into this image. I know how long I spent getting things right, how many little decisions went into it, and how much of myself I put into something that, in the grand scheme of things, is completely unnecessary.

Or... no. Let me rephrase that. It's completely necessary. Maybe even mandatory, if we want what we make to mean something to someone, rather than becoming just another mindless exercise in mass production and sameness!!!!!.

This matters to me.

I think about my friend Kevin Ottens when I think about this. He has often described his work in terms of craftsmanship, even using the idea of haute couture ;). There is a particular kind of work where the effort isn't just a way to get to the result. The effort is part of the result. The choices, the skill, the time spent getting things right. The things that could have been done more quickly, but weren't.

I never actually asked Kevin if he meant it in quite the same way, but that's how it felt to me. Some work carries a sense of the person who made it. You can feel the difference, even if you can't explain exactly where it comes from.

And no, I don't think everything needs this kind of treatment. There are some things were there is no intrinsic great value say a code mockup for example just to test an idea were it can make sense,

But when we decide that something deserves more, when we spend that extra time because we care about the result, I don't want us to lose the ability to recognise that as a kind of value in itself. And I have the suspition it will be the key differentiation factor in the near future

The machine-made thing is necessarily worse at least the afctual result. The human effort does not make everything be good. We've all seen enough terrible handmade things to know that well lest not spend time on that.. . 🙂

It's because I don't want the effort to become invisible just because it can be avoided.

If we want people to feel some connection to the things we make, we need to leave room for that kind of care. To make things that carry a little of the person behind them. Things that talk to you in the same way art does. (And I don't think my designs are any sort of art form, but... well, perhaps that's not really the point.)

Maybe that has no measurable value. and.... I'm OK with that.

Anyway, if you want to see me ramble a little more about creativity, design, and the effort we put into the things we make, reminder KDAB have published a video featuring yours truly and we also put a great deal of effort in it. and you know the deal 😉 views numbers sets the value ;( ...

Sunday, 18 October 2026

Bending is the hardest thing to learn on a harmonica, mostly because you can’t see it. You change the shape of your mouth and throat, and the only feedback is whether the note sounds right, which is exactly what a beginner can’t judge yet.

The bending trainer is the screen in Harmonicon for practising that, one bend at a time. There’s no song and no score. You pick a hole, play, and see where your pitch goes.

The bending trainer: settings across the top, a target card with a pitch rail in the middle, and the harmonica’s bend diagram on the right

The screen has three parts: a settings strip at the top, the target card in the middle, and the harmonica diagram on the right.

Settings

The settings strip: Setup, Scope, Practice, the metronome, and Advanced

Setup picks the harmonica key and the pitch detector (here, “C harp · FFT”). Scope and Practice control the drill, covered below. Then there’s a metronome with tempo, click and straight/shuffle feel, and Advanced.

Setup and Advanced open as floating panels, so the pitch display doesn’t move while you’re using it.

The target card

The target card for hole 2’s half-step bend, with a rail from the natural G4 to the target F#4 and the Distance, Stability and Hold readouts

The card shows the current target, here hole 2 draw bent a half step, and how it has gone for you so far.

The line under the title only reports on the selected hole. Silence, the wrong hole and an unstable signal each get their own message. You only get a cents reading when you’re actually near the target.

The rail runs from the natural note (G4) to the target band (F#4). While you play, a marker shows your pitch and a trail of dots shows the last few seconds, so you can see whether you slid in smoothly, scooped, overshot or held still. On holes with several bend depths, the shallower ones are marked along the way.

Below the rail are three separate numbers: distance from the target, stability, and how long you’ve held it.

Natural and Target play both notes as reference tones. Check natural note is optional: play the hole unbent and the trainer measures where that reed really sits on your harmonica, then judges the hole against that instead of the textbook value.

The diagram

The bend diagram for a C harmonica, with every blow, draw, bend, overblow and overdraw laid out by hole

The diagram shows every note the harmonica can make, by hole and technique. Blue notes are blown and orange notes are drawn, so overblows are blue even though they sound above the draw note.

Click a cell (or use Tab, the arrow keys and Enter) to make it the target. A hint for the selected bend appears underneath.

After some practice the diagram doubles as a progress map. Each cell is tinted by how reliably you control that bend, with a bar along the bottom showing the same thing, so it’s readable without telling red from green.

Practice and the drill

Practice sets what counts as one success:

  • Free exploration: nothing, just play.
  • Find and hold: reach the target and stay there.
  • Bend and release: go down to the target and back to the natural note.
  • Repeated bends: bend on the metronome beats.
  • Bend ladder: step through each bend depth and back.
  • Overbend response: attack and release an overblow or overdraw.

Scope sets which targets the drill uses: First bends (holes 2 and 3 draw, the default), All bends, Blow bends, Overbends, or Custom, where you click cells to add or remove them.

With Drill on, the trainer picks targets from that scope, favouring ones you haven’t tried, control less well, or haven’t practised lately. It moves on when you complete the practice shape. Skip moves on immediately, and silence doesn’t count against you: an attempt only counts once the microphone hears that hole. Progress is saved between sessions.

Advanced

Advanced sets the tolerance, hold time, attempt timeout, A4 reference, and how much history and smoothing the rail uses. It also shows stats for the current attempt: mean distance, spread, best hold, and vibrato speed and width.

The trainer only reports pitch. It doesn’t claim anything about breath, embouchure or reed health, because a microphone can’t measure those.

Esc or the back arrow leaves the trainer, and drill progress is saved on the way out. The code is on GitHub.

Saturday, 17 October 2026

Since Tellico is turning 25 years old, I decided to use the current generative AI tools to create several new entry templates. There may be some quirks I didn’t find, but they cover a variety of layouts and design themes. Install them from within Tellico via the Settings ➜ Templates dialog. They’re also in the Tellico Add-ons Repository. Enjoy!

Modern

Anniversary

Dark Orbit

Jewel Case

Vintage Catalog


Depending exactly on when I mark the date, Tellico is turning 25 years old this month. The ChangeLog tells me I released Bookcase 0.1 on November 4, 2001. Bookcase was the original name of the application. I renamed it to Tellico after I was contacted by another software developer.

I thought it would be fun to look back at a few of the milestones.

November 2001
Bookcase 0.1 is released.
February 2002
Bookcase 0.2 is released, notable since the second release is harder than the first, right?
November 2003
The first home page goes live.
January 2004
Images are added to the collection for Bookcase 0.8. along with several new collection types.
September 2004
Bookcase is renamed Tellico, with version 0.12 the first release with the new name.
May 2005
The tellico-users mailing list is first established, hosted by Novell Forge.
September 2005
Tellico 1.0 is released!
June 2006
Templates for what later became KDE Store were launched.
May 2009
Tellico moves into KDE Extragear, hosted by KDE itself, and away from Novell Forge (which shut down not too long after).
August 2009
Tellico gets its own domain name, tellico-project.org. Having a dedicated domain finally implies a real project, no?
September 2009
Tellico 2.0, the first release for KDE4, is made available. I was very excited about it but rather quickly found a bug.
May 2011
Tellico followed the lead of many programs and transitioned from subversion to git.
November 2016
Tellico 3.0 is released, the first version using Qt5 and KDE Frameworks 5.
February 2022
The first testing version of Tellico for Windows is built.
September 2024
Tellico 4.0 is released, the first version to leverage Qt6 and KDE Frameworks 6.

All told, it’s been a fun journey, with fits and spurts of development or personal life leading to a pause. I use Tellico for my books, videos, old music albums, and coin collection, personally. We’ll see how long it continues!

Just a teaser of a small thing I’m working on.

Our amazing meta-meta-builder tool kde-builder (just like its predecessor kdesrc-build) is indispensable if you’re building many KDE things from source.

The only problem I have with it is that it is overly verbose. It generates ~10 lines of text for each project it compiles. This requires a lot of scrolling for people with a slight OCD (like me) that want to keep track of everything built and everything that failed to build while the tool is working.

For this reason, I wrote a Python (go figure, me and Python) script that processes the output from kde-builder and renders it in a terse single-page dashboard.

KDE builder dashboard
KDE builder dashboard

The dashboard shows the project that is currently being built, a list of projects that failed to build and a list of projects that were built successfully. It also collects all optional dependencies that different projects reported as missing and lists which projects have those dependencies.

It also allows for an easy access to build logs – just click on the failing project, and it will open its error.log in $PAGER (in a separate TMUX tab if you are using TMUX).

Clickable build failures
Clickable build failures

Similar to this, if you click on a project that reported some optional dependency, it will open cmake.log so that you can see all the dependencies that project has.

Clickable dependency reports
Clickable dependency reports

I’ll publish it to invent when I clean up the code a bit, and when I fix some of the remaining issues.

Not a group photo from Akademy – Excalibur (1981)
Not a group photo from Akademy – Excalibur (1981)

I spent last week in Bern, Switzerland, for the second edition of the Open Transport Community Conference, attending that but also being part of the organizer team.

Group photo of Open Transport Community Conference 2026 attendees, standing in the foyer of the SBB headquarters.
Open Transport Community Conference 2026 group photo

Open Transport Community Conference

Compared to last year the event has grown quite a bit. The event got merged with the OTP Summit, a yearly event by the OpenTripPlanner community with a lot of overlap in topics.

Besides the two unconference days there now also were two less structured “hack days”. Due to venue constraints those had to happen before the unconference part, which worked for the larger project teams that already knew each other and had prepared agendas, but would probably have been better the other way around for new people not knowing anyone yet.

A lot of work had also gone into moving the event under the umbrealla of the FOSSGIS e.V.. That enabled us to handle sponsors and (optional) paid tickets this year, to cover lunch for all days. And it hopefully put the event on a sustainable base for years to come.

There were about 140 people attending at the peak, from all over Europe as well as a few people from North America. German speakers were still over-represented, while e.g. the French community was clearly under-represented. We had a good mix of people representing different roles and stakeholders though, covering transport operators, public agencies, standardization, research, politics, FOSS and Open Data projects, etc.

I’m very happy we managed to find an organization to host the event again with SBB and opentransportdata.swiss. Hopefully we can continue this, and keep rotating between different countries, to give more people a chance to attend.

Hack Days

So much for the organizer perspective, now to the content. During the hack days I mainly discussed Transitous and KDE Itinerary topics:

  • Meta stations in Transitous, ie. what happens when you search for a journey from Paris to London. The expectations there is usually not an exact route between city center points, but between appropriate major transport hubs such as major railway stations or airports. Large cities can have more than one of those though, which means all of those should be considered (ie. treating those as one “meta station”). It’s however non-trivial to define exactly what the expected outcome is here, and we went through many different approaches for which we found unfixable counter-examples. There’s two possible approaches left now that could work generically and mode-independent, those would need to be implemented for more wider testing.
  • Geocoding issues in Itinerary, ie. searching for locations resulting in unexpected or confusing results. Jonah improved result merging for this, and we found some issues with parsing Photon responses that added misleading results.
  • Decoding Spanish and Norwegian train ticket barcodes. Updates to the Train Ticket Wiki and the Train Ticket Kaitai Spec repository are under way.
  • Implementing the MOTIS journey refresh API for KPublicTransport. Turned out the partial results we were seeing there were due to not setting all required parameters correctly.

There’s of course many more things that other people worked on, see for example the notes in the Transitous wiki. Transitous now also covering the Chinese railway system is another significant outcome.

Máté showed an experimental iOS port of Itinerary. The amount of code changes needed for that throughout the stack looked manageable from what I saw, and the first patches to KDE Frameworks are already being upstreamed now. The big challenge for bringing that to production is the building, packaging and delivery part though.

Photo of Itinerary running on an iPhone showing train connections and looking almost like on any other platform.
KDE Itinerary running on iOS.

Unconference

Session planning for the unconference part went a lot smoother this time, despite having fewer rooms for parallel sessions. The selected topics seemed even broader than last year.

Whiteboard with a grid of colorful post-its with the unconference session schedule.
Unconference session schedule
  • Evolving data standard like GTFS, GTFS-Flex, NeTEx and SIRI. I’m particularly excited seeing the community getting more and more actively involved in shaping these.
  • Deckplan data. This is very relevant for wheelchair accessibility but also when traveling with bikes or a stroller. Also nice to see that the standardization work there isn’t limited to trains but contains anything from a simple bus to a larger ferry.
  • Opened Data. Somehow this term stuck, referring to all kinds of legal, technical or political approaches to obtain data that isn’t voluntarily Open Data.
  • Crowd-sourcing data. When data cannot be obtained or isn’t available, people are increasingly looking for ways to fill those gaps themselves, with increasing scope and creativity.
  • Ticket standards. A somewhat niche topic, but an amazing examples of how the entire domain got infiltrated and taken over by the community, from reverse engineering a few years ago to now working on the next generation EU ticket standard with an official mandate. We need more of this.
  • Dynamic traffic data. This has already been a hot topic at OSM events recently, with various bits of ongoing work presented here.
  • C-ITS was also a prominent topic in this context, but also for e.g. priorizing public transport at traffic lights and the additional security implications that come with it.
  • Routing algorithms and journey planners like MOTIS and OpenTripPlanner, as consumers of much of the above.
  • Aligning schedule, stop and infrastructure data with OpenStreetMap, as well as upstreaming data to OSM or building OSM QA tooling. This matters as we ultimately route on the OSM data, and for that need to be able to match e.g. realtime elevator data to the right OSM object.

There were also more sessions this time focusing on primarily political aspects rather than technical ones, such as passenger rights and illegal border controls.

We also had a small session about onboarding in the Open Transport community in general and the conference in particular. Open Transport encompasses a lot of different very specialized topics meanwhile, with many of the conversations being very jargon- and abbreviation-heavy, which can be off-putting.

Much of this has grown organically over time from local and fragmented efforts, so it’s not always easy to find who to talk to about a specific topic. We recently added the Open Transport Community Matrix space to make it easier to find the right communication channel, ideally we’d also turn the open-transport.org website into a more general entry point. Help welcome.

Most sessions have notes that can be found in the wiki, next to the lightning talk slides.

Outlook

The event got again very positive feedback, people seemed to enjoy it and consider it useful, as e.g. also Brede’s report indicate. There’s clearly interest and demand for a third edition, but we still need a venue and people doing the work for this. If you happen to have a lead on a venue or want to help out by other means, please get in touch, via the conference Matrix channel or by email.

There’s several options to meet before that as well, a few members of the Transitous team will be at the upcoming OSM Hackweekend in Berlin next week for example, and there’s already work ongoing for organizing the Open Transport presence at 40C3 and FOSDEM 2027.