As you might already know, Transitous is a project that runs a public transport routing service that aims to work wold-wide. To make Transitous results more useful, there needs to be a simple way to book the individual sections of a multi-modal route. It is important to mention that Transitous can not legally sell tickets itself, and there are no plans to change that, so booking in this case means directing users to a ticket shop that can sell tickets for the route.

Ticketing Extension

Transitous is primarily based around the GTFS format for its transport schedules, although NeTEx is increasingly being used as well. The first step naturally was to implement reading ticketing information from the schedule files. Although ticketing is not a core part of GTFS, there is the Google Transit ticketing extension.

Its most important feature is specifying booking urls and a way to pass the stop ids, trip ids and times to the ticket shops. The extension also allows to define ids for stops and trips that the ticket shop can understand. This is important because often the ticket shop software is different from the piece of software that writes the GTFS files. These don’t necessarily have to agree on the identifier they use.

If each trip had it’s own booking deeplink, the size of the schedule would increase massively, as well as the size of the data we’d need to store on the Transitous servers. To solve this, the ticketing extension only stores the base url, and assembles the parameters for each deep link only if needed.

However, this requires a separate shop-specific server side step to convert the standardized parameters to something that the ticket shop understands.

My work

Transitous is mostly just an instance of the MOTIS routing engine, so much of the work happened there.

This work has partially been funded by NLnet through the NGI0 Commons Fund with financial support from the European Commission’s Next Generation Internet programme.

Unfortunately that did not magically give us booking links everywhere. The ticketing extension does not (yet) play such a big role in the open-data / open-source GTFS ecosystem. However since Google Maps supports it, many feeds made for it already contain ticketing_deeplinks.txt. Maybe you can get your local transit operators to add support for it as well :)

To do my part in improving the situation, I added support for it in some of my own GTFS feeds and the library I use for creating them.

Since the problem of needing to translate the url parameters for the ticket shops comes up in every inofficial feed, I also wrote a generic server for doing the redirecting. Adding support for a new ticket shop there is very easy. Since I already host it, it also removes the burden of needing to run a server side component for each feed one publishes.

You can see the results on Transitous: Route from Nikšić to Podgorica.

It also already works in KDE Itinerary.

Adding Ticketing

Adding ticketing to your own feeds is fortunately quite straightforward in many cases. These examples are based on my gtfs-generator rust crate, but it would be very similar in other language ecosystems.

Assuming there is one shop for all trips in the feed, you only need to add one ticketing link:

generator
    .add_ticketing_deep_link(TicketingDeepLink {
        ticketing_deep_link_id: "tickets-zpcg".to_string(),
        web_url: Some("https://jbb.ghsq.de/ticket-redirect/zpcg/".to_string()),
        android_intent_url: Some("https://jbb.ghsq.de/ticket-redirect/zpcg/".to_string()),
        ios_universal_link_url: Some("https://jbb.ghsq.de/ticket-redirect/zpcg/".to_string()),
    }).unwrap();

If the IDs the ticket shop and the feed use are already the same, you already know the IDs and just need to copy them over:

generator.add_ticketing_identifier(TicketingIdentifier {
    ticketing_stop_id: stop.stop_id.to_string(),
    stop_id: stop.stop_id.to_string(),
    agency_id: "zpcg".to_string(),
})?;

Then all that’s left is editing the agency entry to reference the new ticketing link. For more complicated cases, you can also reference a different ticcketing link per route.

If the IDs don’t match, chances are this is still relatively easy. Often the ticket shops’ autocompletion allows to retrieve a full list of stops, ideally including coordinates as well. Then matching these to your stops is relatively straightforward.

If you import your feed into MOTIS with these changes, you should already get a clickable “Tickets”-button. To make it redirect somewhere useful, the redirect server needs to be tought how the url scheme of the ticket shop works by adding a little function like this:

func redirectZpcg(w http.ResponseWriter, r *http.Request, from []string, to []string, date []time.Time, trip []string, departure []time.Time, arrival []time.Time) {
	baseUrl, _ := url.Parse("https://www.tickets-zpcg.me/en/rezultati.php")
	q := baseUrl.Query()
	q.Set("from", from[0])
	q.Set("to", to[len(to)-1])
	q.Set("date", date[0].Format("2006-01-02"))
	baseUrl.RawQuery = q.Encode()

	http.Redirect(w, r, baseUrl.String(), http.StatusSeeOther)
}

The parameters are arrays, since in the ticket links allow to buy multiple tickets via one link. This feature might not be possible to support with every ticket shop.

Maybe this motivated you to add support for this in some new corner of the world :)

Svenska språket uppfinns.

“Hej! Här kommer en uppdatering av våra villkor! Du kan nu använda upp till två tusen ord i månaden med vår gratistjänst, sedan måste du uppgradera till Basic Plan för 129 kr/månaden. Ska du använda svenskan i jobbet kostar det som innan 1299 kr/månaden. Behöver du läsglasögon? Våra enbart godkända leverantörer finner du här. Vi påminner om att pensionärsutgåvan finns inte mer. Vi hörs!”

Wow. Vilken teknologi. Vilken innovation. Vi alla köper.

År 2026, och så har det varit ett tag, så är det så här uttrycksfrihet fungerar på nätet. Vill du skriva till någon som är på Facebook men du är inte? Går inte. Vill du ta del av samhällsaktörers meddelanden och debatt utan annonser och material från den vinstdrivande aktören X? Sorry. Vill du chatta med dina kompisar på SnapChat med en app som är designad på ett helt annat sätt? Det får du inte. Välja leverantör av din feed på TikTok? Nope. Och så vidare.

Grunden i Internet, så som e-post och webbsidor, som byggs upp av specifikationer och organisationer, var designad runt att vara öppen. Du kan välja e-postprogram, webbläsare och vem som helst kan skapa en webbsida. Syftet med dess design var att hålla Internet neutralt, utan så kallade proprietära teknologier och nedlåsning med vinstdrivande intressen. Detta bidrog till stor del till dess succé, och varför det är bra. (Och gammal teknologi, uttrycksfrihet och demokrati har också sina utmaningar.)

De lager och applikationer som vi alla använder i nuläget är långt i från det. Det hela kännetecknas av vad ekonomer kallar marknadssvikt: de sociala medier-apparna tjänar oss konsumenter dåligt.

De samhällsproblem så som psykisk ohälsa och en systemisk sänkning av vår förmåga är ett resultat av hur teknologin och juridiken ser ut. Vi vill digitalt kommunicera och ta del av media, men kan i nuläget inte välja hur eller faktiskt vilket innehåll. Att hålla vinstdrivande aktörer samhällsmässigt ansvariga fungerar inte, men de respekterar marknadens spelregler. Ändra dem.

Så här finns det utrymme för innovation. Dra ihop jurister, samhällsvetare, teknologer och uppfinn de moment i form av teknologi (tänk API:er, referensimplementationer, specifikationer), lämplig juridik och de (supranationella) samarbeten som behövs för att göra den korrektion som är nödvändig. Teknisk separation mellan den app som visar och konton med material? Obligatoriska standarder? En EU-motsvarighet till Finansinspektionen? Här är några utmaningar med det: dåligt betalt, folk fattar inte riktigt poängen, och klurigt.

Kanske det är viktigt nog. Vad är första steg?

This is the second half of what changed in Dolphin 26.08. The first half is what you can see: the features, the behaviour changes, the bugs. This one is what you can measure.

Dolphin does very little file work itself. It asks KIO, so the numbers below are mostly KIO numbers: 6.25 is the version that shipped alongside Dolphin 26.04, 6.29 is the one that ships alongside 26.08, four framework releases and 294 commits apart. The last section is 6.30, the release still to come, since several of its changes are large enough to be worth showing early.

Every figure here was measured on the same machine, with the two versions built the same way and run one after another, round by round. Where a number is not solid I say so rather than rounding it up.

Memory and object lifetimes

The 26.04 post ended by saying the next thing was to point LeakSanitizer at Dolphin. It turned into a lot of fixes, and into a CI job: KIO now runs its tests under LeakSanitizer on every merge request, which is what stops the list below from growing back.

Sebastian Englbrecht was the busiest contributor to Dolphin this cycle by commit count, and most of that work was lifetime and ownership: killing in-flight KIO jobs in destructors, deleting the Konsole part, destroying owned objects before the KIO cache tears down and fixing unowned allocations. He also added a smoke test, eight places-panel unit tests, and a rule forbidding bare QTest::qWait() with the existing waits replaced by signal-based ones, which is the sort of thing that makes the rest of the CI trustworthy. Wendi Gan fixed an occasional use-after-free crash in KConfig::sync() during exit, closing two reports, 516481 and 518433.

My own share was in both projects. In Dolphin: aborting the folder stat job when the Information Panel is destroyed, a use-after-free of the current version-control plugin, a leaked submenu in the folder-icon action and a leak in the trash settings page on exit. In KIO, besides turning the sanitiser on in CI and teaching the tests to wait for what they allocate to be deleted, three fixes are ones a user could have met: the "Move Into New Folder" drop action had done nothing at all since 6.25, because the menu was parented to a plugin destroyed the moment the action fires while the folder creation it starts runs asynchronously; FilePreviewJob armed a repeating timeout timer it never stopped, so with a context menu held open the orphaned timer could fire on a finished job and re-enter emitResult(); and KDirModel dereferenced the node of a directory that had already left the model when an earlier listing completed late.

Performance improvements in KIO between 6.25 and 6.29

The big one is the in-process worker transport. For local files KIO has for some time run the file worker in a thread of the application rather than a separate process. Even in that thread it still talked to the application over a socket, serialising every command and every block of file content through a QLocalSocket pair. In 6.29 that channel is a new ThreadConnectionBackend, an in-memory queue, and kio_file hands over owned byte arrays instead of copying them, which makes in-process reads zero-copy. This is the first half of the improvements described in the copy post from July.

Second, CopyJob no longer re-probes the destination filesystem type for every file. It called KFileSystemType::fileSystemType() per file for the FAT and NTFS checks, and on libmount builds each of those calls parses the entire mount table. Copying N files parsed /proc/self/mountinfo N times. It is determined once now. Each parse is about 57 microseconds on a host with 39 mounts, and it scales with the number of mounts.

Third, and this is the memory one, the directory lister cache got much smaller. A directory that no lister was showing any more went into a cache of ten and stayed there until nine others had displaced it. For a picture folder of 50000 files that is a lot of KFileItem and UDSEntry retained for nothing. The cache now holds three directories, which is what going back a level or two actually needs, and drops anything no lister has asked for in three minutes.

Fourth, UDSEntry got smaller, which saves memory. An entry now keeps its numbers and its strings in two separate vectors, which buys a byte for every field an entry holds. And loading now sizes each vector from what the entry actually holds: both vectors used to be sized from the count of fields alone, a third of it for the strings and two thirds for the numbers. A stat of a local file gives one string, the name, and eight numbers, so the numbers grew past their room while the strings kept more than they needed. That sizing change on its own takes a listing of 200000 local files from 528 bytes an entry to 400, which is 105.6 MB down to 80 MB, 25.6 MB saved. Loading also stopped hunting for a shared value on the fields where values cannot repeat: no two entries of a listing carry the same name, url or local path, so comparing them with the entry before never found anything to share. Reading one entry of a local folder off the wire went from 530 to 488 nanoseconds.

Smaller ones worth naming: KFileItem no longer reads .directory on slow filesystems when working out an icon name (6.28, closing bug 519189), Sebastian Englbrecht fixed QPluginLoader, QLibraryPrivate and thread lifecycle leaks in the worker machinery (6.28).

Nineteen reports were closed by fixes in KIO across those four releases. Most of them are filed against the applications rather than against KIO, since that is where a user meets the problem: Dolphin, Plasma, Konsole, KWin.

Benchmarks

Methodology

I built KIO 6.25.0 and 6.29.0 from their tags, Release on gcc 16.2.1 and Qt 6.11.1, and ran the same harness against each. The arms are interleaved one round at a time, so a CPU frequency or load excursion hits both equally, and the best of N rounds is reported.

Everything ran on one 13th Gen Core i7-1365U with 30 GB of RAM, kernel 7.1.4, on ext4, with the benchmark processes pinned to the same two cores.

Copying

KIO::copy() of N files into an empty directory, timed from job start to the result signal. Source files are created untimed, the destination is cleared untimed. cp -r is there as a raw-tool floor, not as a target.

Copying many small files is more than twice as fast as it was in April. The gain falls off as files get larger, which is what you would expect: the fix is to the per-file overhead, and once each file carries a megabyte of actual I/O the overhead stops being what you are waiting for.

There is still a gap with cp, discussed at length in the July post. KIO is doing more than cp does, but not five times more, and the batching work that closes most of the rest of that gap is still in progress.

Deleting

KIO::del() over a freshly created tree, best of three rounds. rm -rf is the raw-tool floor here, as cp -r is above, and it is handed the same list of paths the job is given rather than the folder that holds them.

Deletion improves less than copying, as expected: a delete carries no file content, so the zero-copy half of the transport work does nothing for it. What is left is the cheaper per-command round trip, 1.23x on the smaller tree and 1.25x on the larger one.

rm -rf is six times quicker than 6.29 on both trees, a wider gap than copying shows against cp. That fits: a copy at least spends real time moving bytes, where a delete is almost nothing but the per-file round trip, so what KIO adds is most of what there is to measure.

How the job is asked matters as much as the count. These runs hand KIO::del() the 5000 files one by one, the way a select-all in a file manager does. Handing it the one folder instead takes about a fifth of that on the same filesystem, because the worker then walks the tree itself instead of taking a command per file. rm given the folder rather than the 5000 paths goes from 69.4 ms to 66.8, which is the difference the filesystem charges for the two shapes. The rest of it is KIO's. That second path is the one the 6.30 section below measures.

Listing

One KCoreDirLister over an existing directory. The cold number is the first listing in a fresh process. The warm number is a later listing of the same directory, which KCoreDirListerCache answers without going to disk. The second chart is the resident growth while the lister is still showing the folder, which is what a file manager displaying that folder actually costs.

Listing is about 9 percent quicker on the 5000-file folder and 15 percent on the 50000-file one, and holds about 14 percent less memory in both cases. The memory part is the UDSEntry work described above. The warm listing is unchanged either way, 2.6 ms against 2.8 ms on the 5000-file folder and 37 ms on the 50000-file one, which is the cache answering rather than the disk.

Memory kept for folders you have left

Of everything measured here, this is what a long-running Dolphin notices most. Walk twelve directories one after another, the way you do going down and back up a tree, and then look at how much memory the process is still holding. Nothing is on screen in either case, so all of it is held for folders nobody is looking at any more.

In 6.25 a directory nothing was showing any more sat in a cache of ten and stayed until nine others displaced it. Browse through a few large folders and you are holding all of them. The cache now keeps three, and drops anything no lister has wanted for three minutes. Repeat listings do not suffer for it, which is what the warm listing above shows: re-opening a folder you just left still finds it. What the eleventh slot bought was going eleven folders back, and every user of a large folder paid for it.

6.30 improvements

None of this has shipped, so treat it as a preview rather than a result. 6.30 has several commits that touch exactly what this post measures, so I built it as a third arm and ran the same harness.

Most of what 6.30 gains comes from one change: handing over what a message carries as it is when the worker runs in the application's own process. kio_file runs in a thread of the application, but used to write its data down with QDataStream the way a process-based worker has to. Except it does not need to. Avoiding that serialisation is where the fewer allocations come from, and the entries cost less memory besides, since one no longer reserves room for fields most files never carry. Nothing changes for a worker in another process, which still has a socket between it and the application.

The other major improvement was a dormant issue. It had been there for years, and benchmarking made it visible: 50000 files listed in 1233 ms while 5000 listed in 36, 10 times the files taking 34 times as long, where listing should be close to linear.

A profile of the large case revealed 42 percent of the whole listing is KFileItem copy construction and destruction, all of it under KCoreDirListerCache::DirItem::insertSortedItems calling QList::reserve once per batch of entries. Except reserve has no relocatable fast path: on the growth path it allocates exactly the size asked for and copy-appends every element already there, even for a type declared Q_RELOCATABLE_TYPE as KFileItem. Since the previous call had sized the buffer exactly, every batch reallocated and copied the whole list. Heaptrack counted 239 such calls for 50000 files, so about six million copy constructions for fifty thousand items.

Deleting the reserve call and letting the list grow geometrically takes that listing from 1233 ms to 531 ms, over 2x quicker. What cost the time was inside those reallocations, copy-constructing every KFileItem already in the list, and a KFileItem copy is a refcount bump that allocates nothing at all. So none of it showed up in an allocation count, which is why it took a cycles profile to find.

Deleting a folder gained from af3d9e0e7, which removes a tree with the system's own calls instead of walking it, and how much depends on the shape of the tree. openat and unlinkat work from a descriptor for the directory an entry was read from, so they stop resolving a whole path for every entry, and the deeper the tree the more that is worth. Fifteen thousand files on tmpfs, deleted as one folder, with rm -rf over the same tree as the floor:

6.29 costs more the deeper the tree, four times as much at 800 levels as at ten. 6.30 does not care how deep it is, and stays within a third of rm -rf at every depth, which is about as close as a job that reports progress and can be cancelled is going to get to a tool that does neither.

Closing

The copy path still has more in it than 6.29 ships: the batching that closes most of the remaining gap to cp is written and measured in Making KIO copy many files fast and is not finished yet. The listing path has an open question of its own, which is that an entry could carry its fields more cheaply again; a branch that does it trades about two percent of listing time for eleven percent of the memory an entry holds, and which of the two is the better trade depends on how many entries you are holding.

Enjoy the speed.

Hello fellow KDE contributors and users!

The Font Subsetting for FreeText annotations merge request got merged today and this means Poppler now supports font subsetting for FreeText annotations.

You can try it out by using Poppler from the master branch or wait for the next release. You can enable/disable it by passing -DENABLE_HARFBUZZ=ON/OFF when running CMake although it is enabled by default.

We worked on the following in the past 2 weeks,

• Re-generating the CIDToGIDMap after subsetting.
• Re-generating the width array after subsetting.
• Working on code reviews on the MR.
• Regression testing and fixing bugs.
• Some small architectural code changes.

What's remaining:

• The Font Subsetting for Form Fields merge request is under review and is currently being regression tested for bugs. After this is merged, font subsetting shall be fully supported in Poppler.

Watch out for a demo video/blog showcasing the results after doing font subsetting soon!

Thank you,
Ojas

Dolphin 26.08 has been released. Here is more of what changed in it, and in the KIO framework underneath it.

The version of KIO that shipped alongside Dolphin 26.04 was 6.25. The one that ships alongside 26.08 is 6.29, four framework releases and 294 commits later. A fair part of this post is about that, because the largest performance change of this cycle is not in Dolphin at all. If you only read one thing, read Making KIO copy many files fast, which is the story behind why copying a folder of small files in 26.08 takes less than half the time it did in 26.04.

New features

Grouping is no longer tied to sorting. Ramil Nurmanov added an explicit group role, so grouping by type no longer forces you to sort by type as well. The old "Show in Groups" toggle is replaced by a "Group By" menu, which lets you turn grouping off, keep the old "Same as Sort" behaviour, or pick a criterion outright. Inside each group the normal sort role is still used as a secondary key. (989c0f4f0)

The filter bar tells you what it is doing. Alessio Bonfiglio replaced the hidden auto-detecting regex behaviour with an explicit mode selector offering Plain Text, Glob and Regular Expression, plus a case-sensitivity toggle. The old behaviour tried to guess: typing a name containing *, ? or [ silently switched the bar to a regular expression, which made a file genuinely named [draft].txt impossible to filter for. An invalid expression now turns the bar red instead of quietly doing something else. (3084a4e11)

A "Folder Name" column in the details view, by Jussi Räsänen, closing a request from 2021. It is most useful when a search or an expanded tree puts files from several folders on screen at once. (4a7be9f25)

Per-folder zoom, by Wagner Soares. When you are not using global view properties, the zoom level is now remembered per folder like the other view properties are. (0f7a9c681)

"Focus Other View", by Felix Ernst. The "Switch between views with Tab key" setting is gone, replaced by a real action you can bind to whatever you like. It moves focus to the inactive split view, and opens a split if there is not one yet. (12b4a8a91)

Close tabs to the left or right, by Ramil Nurmanov. (91e7c0c1e)

A button to restore view properties to their defaults, which I added for the per-folder view properties case. It enables and disables itself depending on whether the current folder already matches the defaults. (70f34211c)

Type-ahead feedback in the status bar, by Felix Ernst. As you type, the status bar shows the keys you have typed and which file name they selected, so a type-ahead that lands somewhere unexpected is no longer silent. (1e13c6abb)

The terminal panel can be resynchronised with F5, by Antti Savolainen, closing bug 510557. When a foreground program is running in the panel, the terminal and the view can drift apart. Konsole does not signal when that program exits, so responding to F5 is the practical answer. (07baa7bb6)

KDE Connect integration, by Kai Uwe Broulik: an "Open KDE Connect" button when browsing the kdeconnect scheme (d5903bd81), and a proper placeholder for a KDE Connect folder (dfef28748).

Session restore for the first instance, by Sergey Katunin, closing bug 464693. If Dolphin is not already running and something launches it with --new-window, as browsers and Kate do, the session is restored rather than discarded. (173794ce1)

Behaviour changes

These are the changes most likely to surprise you, so they are worth naming explicitly.

• Create New Folder is now two actions. Ctrl+Shift+N and the context menu entry shared one action, so the menu advertised a shortcut that did something subtly different: the shortcut creates in the viewed directory, the menu entry in the folder you clicked. They are separate actions now, and the context menu one has no default shortcut. (705e366aa)
• "Empty Trash" moved in the context menu, by Antti Savolainen, closing bug 518713. It now sits with the other destructive actions rather than next to harmless ones. The reporter had been emptying the trash while reaching for something else. (7d81e3092)
• "Open Terminal Here" only appears for folders, not for files, by Brijesh krishna. (8a9f7d9d4)
• The play arrow over video previews in the Information Panel is gone, by Ryan Nosurname. There is already a play button and a seek bar directly beneath it. (71f8db089)
• Icon overlays are drawn at a fixed size rather than composited into the thumbnail and rescaled with it (bug 498211). Emblem size was previously inconsistent from file to file, because each thumbnail was rescaled by its own factor, and slightly cropped at fractional display scaling. (63f21036e)
• Special folders keep their saved view properties even with global view properties enabled, by Pan Zhang (bug 520089, 2e665e1b5).
• Names like file.2.txt sort naturally, by Pan Zhang (bug 411707, 0d10eff37).

Who wrote it

Counting commits that are new in 26.08 and not already in a 26.04.x release, and leaving the translation robot out of it:

The busiest by a wide margin:

Commit counts and line counts do not rank people the same way. Ramil Nurmanov and Alessio Bonfiglio wrote two commits each and still added more lines than anyone except the top two, because grouping by a separate criterion and the filter bar modes each arrived whole. Ryan Nosurname's single commit is the opposite shape: removing the video preview play arrow takes away 43 lines and adds none.

Thirteen people landed their first Dolphin commit this cycle: Antti Savolainen, Areeb Faisal, Brijesh krishna, Evgeniy Harchenko, Filip Fila, Florian RICHER, Jussi Räsänen, Ketal Wang, Oleksandr Bondar, Ramil Nurmanov, Ryan Nosurname, Sebastian Englbrecht and Wagner Soares. Kudos to them! Several are long-standing KDE contributors who had simply not touched this repository before, so read it as new to Dolphin rather than new to KDE.

The other 110 commits were mainly translation commits. Thank you, translators!

Bugs fixed

Nineteen bugs are fixed in 26.08 that were not already fixed in a 26.04.x point release. Ten of them are the changes described above, so here are the other nine:

Two regressions worth knowing about

Icons could be missing entirely. On a freshly opened view every item drew a blank where its icon should be, and it stayed that way until the view mode was switched or the zoom slider moved (bug 523228). A regression from per-folder zoom, fixed in 9c652faca. That fix brought one of its own, turning previews off in icons view rendering at 16 pixels rather than the 32 that mode is set to (bug 524606), fixed in 57c6b10e1. Both are on the release/26.08 branch and ship in Dolphin 26.08.1, due in the first half of September 2026.

Service submenus disappeared from the context menu. Entries that a service menu file groups into a submenu were missing from the context menu, in any application that builds one with KFileItemActions, Dolphin included (bug 524239). A regression from 148b9253d in 6.29, fixed by Luis Bocanegra in 774defb94, which ships in KDE Frameworks 6.30, due in the first week of September 2026.

Neither was found by a test, and both have one now: dolphinitemlistviewtest, which is new, and three cases in dolphinviewtest for the per-folder cache, and testServiceMenuSubmenuActions with a submenu.desktop fixture in KIO.

Closing

If you want to help, the leak and lifetime work above is a good way in, and so is picking a bug from the list. The KIO copy path still has more in it than 6.29 ships: the batching that closes most of the remaining gap to cp is written and measured in Making KIO copy many files fast but not yet finished.

That's all, folks.

Remote desktop has been one of the weaker areas of the transition to Wayland. There's a lot of software written exclusively for X that has a direct Wayland equivalent. Within KDE, we already have a Plasma-native RDP and VNC solution for Wayland, but we're aware that it hasn't yet reached the level we want it to.

Throughout the path to Plasma 6.8 it has been an area of focus, with contributions from me, Shouvik Kar, Nick Haghiri, Oliver Beard and Wensheng Tang.

Improved Unattended mode

There are a few different use cases for remote desktop:

Support Mode

This is the typical remote session. You see exactly the same thing on the remote client as on the host, with the contents matching the size of the monitors on the host machine.

This is great when there's someone at the host machine and someone else remoting in, and you want to work together while both seeing the same content.

Unattended mode

The above mode isn't so great when there's just you. If I'm connecting to my home PC from a tiny laptop, it's very unergonomic to have the remote screen be larger than my laptop display and have to scroll around it.

Additionally if my remote PC is in an office, I don't want my colleagues to see my cursor moving around clicking on windows when I'm not there.

We have a new UX that solves all of these issues:

• On connection, the remote machine shows the login screen.
• For the sesssion you log into, the host machine's screens are removed, ensuring privacy and security.
• The remote screens are resized to match the size and layout of the client's screen setup.
• When streaming in a window, the remote screen dynamically resizes to match the window size.
• Best of all, after the remote session is closed and the user logs back into the host machine, all their windows return to where they were last positioned on the host setup.

The underlying work also sets us up nicely for the full headless case.

Clipboard

Clipboard support has been massively improved with bi-directional text snippets and upcoming work for file transfers, including support in KRDC.

Performance

We've been cutting down latency throughout the system. A new timing mechanism tracks every frame throughout the entire process, letting us see where delays build up, from receiving the raw frame and encoding it, through transmission over the network, to rendering on the client and finally receiving the acknowledgement.

We now coalesce frames that are still waiting to be sent to the client. A new algorithm determines the optimal number of frames to keep in flight, while improved backpressure handling keeps latency lower during network dropouts.

There's also work happening to send multiple streams or even areas of the same desktop at once.

KRDC will also benefit from improved performance in 26.12 as an extra source of latency compared to the xfreerdp3's model performance has been addressed.

Better compatibility

One of the core reasons we have an RDP server is that there's a huge range of existing clients out there. That only helps if we actually support those clients, which isn't trivial given how much variation there is between them.

We now support both RemoteFX Progressive encoding as well as full hardware accelerated H264 encoding with improved fallback for when H264 encoding fails. We also fixed NLA authentication for Windows clients.

libei port

Another large refactor is the port to libei: a library/protocol for sending emulated input to the compositor that's a lot more fleshed-out than the basic 'move mouse' 'send keysym' that existed directly in the XDG Portal specification. libei is far more robust: it can support any number of devices at once and provides the infrastructure for us to also support remote tablet and touch.

We also have massively improved support throughout the stack for sending any keysym that isn't in the current keymap. i.e even if the host keyboard is set to US, you can still input on the remote side characters like ẞ, to even fully composed UTF-8 strings like "안녕 ".

What's next

Multi-user headless

Whilst I am confident that we will have a great single-user story in time for Plasma 6.8 even for truly headless setups, it is unlikely we will deliver a remote server that handles multiple concurrent users at this time. It is far from trivial, and feature freeze for Plasma 6.8 is upon us.

Standardisation

Ultimately, it's frustrating that we're in a situation where we have to maintain this entire service at the KDE level, when much of it should be a solved and shared problem.

Having our own implementation has been useful to work out how to provide tight integration with Plasma, but there are many competing remote-desktop services that should be able to benefit from the same underlying infrastructure.

Others feel the same way, and there is some effort to start standardising the work for headless setups. I hope to have more news on that front shortly.

Call to action

As this remains a critical path for X11 holdouts, we need people to test and contribute. If you can, please run master builds and report any bugs you find. The final merge-requests for the parts mentioned above should be landing soon. Bug reports help; patches even more so!

After working on the UI of TM Tab in Lokalize during the first phase of GSoC, I got back to work on the backend. Currently, only a single TM can be searched in TM Tab. My changes enable querying across multiple selected TMs as per translators' feature request.

A little about threads and mutexes before I share week-wise updates. The GUI runs on the main thread, while TM operations (querying, opening/closing databases, removing files) run as jobs on a separate worker thread pool, TM::threadPool(). This pool is explicitly capped to a single worker thread at startup- setMaxThreadCount(1). This means TM jobs never actually run concurrently with each other, they queue and execute strictly one at a time (this can be changed given my new changes but will have to be careful).

QSqlDatabase connections can only be used on the thread that created them, which is why each job looks up or clones a connection specific to the current thread before querying.

A queued connection is what lets a signal emitted on the worker thread safely invoke a slot on the GUI thread: rather than running the slot's code immediately on the emitting thread.

A mutex protects shared or concurrently-accessed data.

Week 7

I spent week 7 exploring other approaches for quering multiple DBs and merging the results. QSqlQueryModel is only useful to get query results from a single db. It just enabled std::move(*job->query) and there was no way to append results from other TMs.

I felt that my proposed approach, to fire N ExecQueryJobs, merge them in an in-memory SQLite db, and then pass it on to the view, was making things unnecessarily complex and somewhat redundant. I'm sharing the discarded ideas as well in case it helps someone in the future.

• Use ATTACH to add other db(s) and perform UNION on the search query. There were some concerns over the complexity of ATTACH and also Lokalize supports remote TMs (PostgreSQL) which doesn't have the provision of ATTACH.
• Then, I looked into QConcatenateTablesProxyModel which some KDE apps already use, but there is some bug with its working with QSortFilterProxyModel. I could have had "N TMDBModel instances" (which doesn't seem like a good idea) for each TM and later join them.

Week 8

I decided upon QAbstractTableModel. Unlike QSqlQueryModel (which is a subclass of it), it's more flexible and I had to refactor some of the code. This also meant lazy fetch couldn't be preserved and the results would be stored in QSqlRecords (to preserve all the existing usage on results).

Manually tested against a single TM. Rewrote the TMJob Test too. I find it strange that we always write a test for it to pass. Also from one of the articles I read: "Use test driven development. When you write the test just before the production code, you would never write a monster test, would you?"

Week 9

setFilter() is modified such that ExecQueryJob is fired for each TM. slotQueryExecuted() accumulates each job's rows into the model as they arrive, and only fires resultsFetched() once every selected TM's job has reported back. Row count is also reported directly at the end.

Well, contrary to what I wrote in the last blog, I did end up with an approach quite similar to what TMView does. Are mentors always right?

The part on which I spent a lot of time was what happens if someone retypes their query, or checks/unchecks a TM, while the previous search's jobs are still mid-flight. Stale results shouldn't be allowed to land on top of a newer search's rows. The fix is a generation counter to keep track.

After a lot of coding and debugging, seeing the resuts from multiple TMs made the entire hard work finally pay off.

While testing, the bug mentioned in the previous blog kept pestering me so I fixed it too. I was so fixated on empty/short string that I did not think that the place it was being used could be a problem. It's nice to see the Art of Debugging materialize out of pages of Roger S. Pressman's textbook.

I'll begin to work on TM View once these changes are reviewed and merged.

In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026.

For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).

The fellowship is time-limited, so I am intending to make the time I currently have count!

So, what’s planned?

I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview:

Freedesktop.org, Specifications and Organization

I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.

While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway).

Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.

In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).

AppStream

A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.

AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project.

I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.

PackageKit & System Upgrades

Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.

My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.

In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.

That’s a lot of tasks!

Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.

Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .

You can also expect blog posts about key features or interesting changes, so stay tuned!