31 Aug 2026

feedPlanet KDE | English

Kdenlive 26.08.0 released

We are happy to announce the summer release of Kdenlive 26.08. Continuing the efforts from the last version, the core team has been focusing mostly on stability - fixing bugs and crashes while also doing lot's under the hood improvements.

This release comes with 11 crash fixes as well as improvements to the undo/redo stack for compositions and sequence creation. Work has also been done to modernize the codebase in the Qml loader for Clips and Compositions.

The majority of the new, nifty and shiny additions and enhancements in this release were made by new contributors! This seems to have become a tradition in 2026, and we couldn't be happier about it.

Highlights

Timeline

Automatic Track Creation

Added functionality to automatically create audio tracks when adding a clip to the timeline in case there are not enough. Implemented by Vineet Tiwari.


Reorder Tracks

Added a long awaited ability to reorder tracks. Implemented by Vineet Tiwari.


Markers At Gaps

Added option to add markers at gaps between timeline clips. Implemented by Yash Bavadiya.


Playhead Snapping When Dragging

ALT + drag the time cursor (playhead) in the timeline ruler, it now snaps to nearby snap points like clip edges, guides, markers, and zone in/out. Implemented by Yash Bavadiya.


Copy Selection To New Sequence

It works similarly to "Create sequence from selection" except that it does not remove the clips from the original sequence and replace them with the new sequence clip. Implemented by Vineet Tiwari.


Clip Color Configuration

Added an option to configure colors for video, audio, title, image, and slideshow clip types.

Color Clip Configuration


Playhead/Mouse Zoom

Added a button in the Status Bar to toggle between zooming to the mouse cursor position or the playhead position. Implemented by the mrfantastic.


Multi-Clip Speed Changes

Added the ability to change the playback speed of multiple clips at once either by directly Ctrl + dragging in the timeline or by using the Clip Speed tool. Implemented by Vineet Tiwari.

Title Editor

Snapping

Added snapping in the Title Editor. Implemented by chocolateimage.


Rounded Corners

Rectangles now can have rounded corners. Also notice the draggable spinbox ability to change the radius. Implemented by chocolateimage.


Copy/Paste

Added the ability to copy and paste elements in the Titler. Implemented by chocolateimage.


Automatic Clip Replacement

Added option to automatically replace a title clip in the timeline with the new title clip being edited. Implemented by Eduardo Guedes.


Miscellaneous

Additive Soloing

Added the ability to do additive soloing in the audio mixer by shift clicking. Implemented by Patrick Williamson.


Adjustable Rotation Anchor

Added the ability to set the rotation anchor in the Transform effect. Implemented by Jean Baptiste Mardelle.


Other Noteworthy Changes

Give back to Kdenlive

Releases are possible thanks to donations by the community. Donate now!

Need help ?

As usual, you will find very useful tips in our documentation website. You can also get help and exchange your ideas in our Kdenlive users Matrix chat room.

Get involved

Kdenlive relies on its community, your help is always welcome. You can contribute by :

For the full changelog continue reading on kdenlive.org.

31 Aug 2026 6:05pm GMT

Qt Extension 1.16.0 for VS Code Released

We're excited to announce the release of version 1.16.0 of the Qt Extension for Visual Studio Code! This release brings:

31 Aug 2026 2:24pm GMT

Harmonicon: a rhythm game you play on a real harmonica

For once, something on this blog that isn't C++.

Harmonicon is a rhythm game for blues harmonica. Notes scroll toward a hit line and you play on an actual harmonica, into your microphone, and the game listens.

The idea

The harmonica is cheap, fits in a pocket, and it hides everything: the reeds are inside, your tongue and throat do most of the work, and nothing about the instrument tells you whether the note that just came out is the note you meant. You can practise a bend wrong for a month quite happily.

Let the instrument be the input. Harmonicon captures the microphone, runs pitch detection on it in real time, and scores what you actually played against the chart. Every note you score is a note you genuinely hit.

Playing a song

The 2D play mode: a lane per harmonica hole, with notation and a tab readout above

The default view is one lane per hole: ten for a diatonic, twelve for a chromatic, taken from whatever the chart was written for. Blue notes are blows, orange are draws, and the number on each is the hole you need. Above the lanes there's the phrase in standard notation and as harmonica tab, because those are the two ways harmonica players actually read music, and the panel on the right tells you which harp to pick up and which position you're playing in.

There's also a 3D view, which is the same game rendered around a harmonica model that moves with the beat.

The 3D play mode: notes travelling down toward an animated harmonica model

Getting away from charts

Charts are good for learning a song and bad for learning to play. The Jam Session mode drops the scoring entirely and gives you a rolling 12-bar blues to improvise over.

Jam Session: a 12-bar chord grid on the left, a live-tinted hole map on the right

The useful part is the hole map on the right. As the backing moves through the bars, each hole recolours: gold if it's a chord tone of the bar sounding right now, green if it's elsewhere in the blues scale, dim if it's going to sound wrong. You follow the colour instead of trying to recall theory at tempo, and the theory arrives later, on its own.

Lessons

The lessons list, grouped into units from fundamentals to jazz

There's a curriculum underneath all of this, grouped into units and gated by prerequisites - from getting one clean single note out of the thing, through bends and articulation, up to improvising over a blues. Some lessons are scored drills. A few aren't scoreable at all: tongue blocking sounds identical to puckering from the microphone's point of view, so that one is instruction you mark as done and the game trusts you.

Under the hood

Rust, with Bevy for the engine and cpal for audio capture. The interesting problem is the pitch detection, which is why there are five algorithms to chose from: FFT, YIN, pYIN, MPM and NMF.

Status

There's a lot in it - a bending trainer, an in-game song editor with MIDI import, adaptive difficulty, A-B looping, latency calibration, a spectrogram - but "early/experimental" is an honest label rather than modesty.

It's MIT licensed and the code is at github.com/tcanabrava/harmonicon. If you own a harmonica and a microphone, that's the entire hardware requirement.

31 Aug 2026 12:00am GMT

30 Aug 2026

feedPlanet KDE | English

KDE Connect redesign is ready for testing

And I think it's pretty nice

30 Aug 2026 12:00am GMT

28 Aug 2026

feedPlanet KDE | English

This Week in Plasma: QtWidgets Apps Join the Union

Welcome to a new issue of This Week in Plasma!

This week saw the first stirrings of support for QtWidgets-based apps in KDE's new Union theming system, which is a very exciting milestone.

But that's not all! This week is also packed with UI improvements, performance improvements, bug fixes, and a few more features, too.

Plasma 6.8 is rapidly shaping up, and all this work reflects it. Check it out:

Notable new features

Plasma 6.8

The new Union theming system has gained initial support for styling QtWidgets apps! (Akseli Lahtinen, union MR #270)

Dolphin file manager styled with Union
I'm sure you can see numerous visual glitches in the screenshot above. This is a first draft with many known visual bugs, and we'll work on getting those smashed as quickly as possible. But still, very exciting! The Union theming system is coming together nicely. Read more about it on Akseli's blog.


Plasma's built-in RDP server now supports adjusting its quality level to the network's available bandwidth to keep the frame rate as consistent as possible. (Nick Haghiri, krdp MR #238)

Plasma's Strongswan VPN support now allows the use of EAP-TTLS authentication. (Wyllian Bezerra da Silva, plasma-nm MR #636)

Notable UI improvements

Plasma 6.7.5

Discover now only offers to open and install .deb packages on operating systems natively supporting that package format. (Aleix Pol Gonzalez, plasma-desktop MR #3957)

Plasma 6.8

When you copy a password or other piece of text that the app says is a secret, the clipboard history UI now makes this clear rather than hiding it and letting you wonder why nothing appeared there. (Tobias Fella, KDE Bugzilla #508326)

Warning about sensitive data on the clipboard

The indicator that a screen recording is in progress now only appears if it actually is in progress, which handles the case of apps that open screen recording sessions early, but start the recording later. (David Redondo, xdg-desktop-portal-kde MR #597)

KWin's Overview effect is now a little bit easier to open with a four-finger swipe touchpad gesture. (Remy Farley, kwin MR #9486)

All of the text for calendar events in the Digital Clock widget is now selectable. (Nate Graham, KDE Bugzilla #433668)

System Settings' Drawing Tablet page now has a less awkward design for the dialog window to choose what the buttons on your tablet's pen do. (Joshua Goins, KDE Bugzilla #524720)

New New
Old Old

The Bluetooth widget now shows its "Configure" button in the same place that all other widgets do, for better functional consistency. (Tomáš Hnyk, KDE Bugzilla #516134)

Connecting to an enterprise Wi-Fi network for the first time now takes you immediately to the place where you can enter your credentials, instead of making you navigate there manually. (Ramil Nurmanov, plasma-nm MR #635)

Clicking a System Tray icon that opens a widget can no longer make that icon immediately disappear; now, it will always stay visible until the widget's popup closes, giving you the opportunity to click on it a second time to close the popup. (समीर सिंह Sameer Singh, KDE Bugzilla #521115)

Using the clipboard's "Keep the selection and clipboard the same" setting no longer unnecessarily disables other settings. (Tomáš Hnyk, KDE Bugzilla #492840)

If your system is in such a poor state that there are many crashes, your System Tray no longer fills up with dozens of little sad face icons; now only one appears, and clicking on it will show the full list in its own window. (Tobias Fella, KDE Bugzilla #420443)

Frameworks 6.30

In-window dialogs in Kirigami-based apps are now better highlighted against the rest of the window content when using a dark theme. (Marco Martin, KDE Bugzilla #447965)

System Monitor graphs now request "tabular numerals" for the legends when using a font that supports them, improving alignment. (Christoph Wolk, kquickcharts MR #109)

New New
Old Old

Notable bug fixes

Plasma 6.6.7

Fixed a security issue that made the screen locker fail to lock if you manually configured it to turn off the screen after the "don't require password to unlock" period. (Xaver Hugl, KDE Bugzilla #523504)

Plasma 6.7.5

Fixed a pretty bad bug that made Discover get stuck while checking for updates when its Snap backend was present, but there were no upgradeable Snap apps. (Dustin Trumps, KDE Bugzilla #524077)

Fixed a case where non-KDE apps running in Plasma could sometimes crash when you closed a dialog. (Balló György, KDE Bugzilla #523039)

Fixed a recent regression that impaired pointer movement in VMs using non-accelerated graphics drivers. (Base Devel, KDE Bugzilla #524280)

Using a right-to-left language like Arabic or Hebrew no longer prevents force-quitting processes or apps in System Monitor. (Jakob Petsovits, KDE Bugzilla #522233)

Fixed a weird little bug that made the panel's tooltip in edit mode become malformed after right-clicking on the panel. (Christoph Wolk, KDE Bugzilla #488578)

If your system is in a super-duper messed-up state, it can at least no longer cause the DrKonqi crash handler to crash in a loop, feeding itself with crashes that exhaust the system's memory. (Harald Sitter and Alexander Berg, KDE Bugzilla #524048)

Plasma 6.8

Fixed the second-most-common crash in Plasma, which could happen while logging out. (Tobias Fella, plasma-workspace MR #6973)

On System Settings' Plasma Search page, the "Defaults" button and non-default settings highlighting now work as expected. (Tobias Ozór, plasma-desktop MR #3973)

With multiple Application Launcher (Kickoff) Widgets, all of them are now capable of returning search results for not-yet-installed apps, not just the first one. (Christoph Wolk, KDE Bugzilla #511220)

A logout sound no longer delays the logout process more than it needs to. (Ramil Nurmanov, KDE Bugzilla #491745)

Notable in performance & technical

Plasma 6.7.5

Improved the way HDR content looks when using an ICC profile. (Xaver Hugl, KDE Bugzilla #524038)

Plasma 6.8

Improved the performance and power efficiency of many kinds of full-screen content when using an Intel or NVIDIA GPU with HDR, ICC profiles, and/or the Night Light effect. (Naveen Kumar, kwin MR #9640)

KWin now supports HDR content using the HLG transfer function. (Xaver Hugl, KDE Bugzilla #508817)

Reduced screen-casting latency throughout Plasma and KWin (including for the built-in RDP server!) by one frame. (David Edmundson, kpipewire MR #274)

Reduced the resource usage required to show thumbnails in notifications and the Activities sidebar. (Kai Uwe Broulik, plasma-workspace MR #6966 and plasma-desktop MR #3967)

Reduced the resource usage required for the Trash widget. (Kai Uwe Broulik, plasma-desktop MR #3965)

Screenshots made with Spectacle that don't have any transparency no longer include an alpha channel, slightly reducing file sizes. (Kai Uwe Broulik, kwin MR #9798)

Disabling a System Tray widget now frees up its memory immediately, rather than only after Plasma or the system is restarted. (Tomáš Hnyk, plasma-workspace MR #6983)

The showConfigurationInterface() function now works in Plasma scripting. (Remilia S., plasma-workspace MR #6977)

If you've broken, misconfigured, or removed all of Plasma's wallpaper plugins, Plasma will now launch without them and just show a plain background, instead of failing to launch at all. (Ramil Nurmanov, KDE Bugzilla #524875)

Frameworks 6.30

KWallet no longer spams your log with errors in certain non-default configurations. (Nicolas Fella, KDE Bugzilla #524500)

KDE Gear 26.12.0

System Settings' Proxy page has been rewritten in QML, which lets it work on Plasma Mobile. The design is nearly identical, so you shouldn't notice any obvious changes to it. (Tobias Fella, kio-extras MR #536)

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.

28 Aug 2026 9:14pm GMT

Initial Release of Union QtWidgets

It has begun.

After couple months of work, I have now finally managed to cobble together the QtWidgets side of Union.

This means that your QtWidgets apps, such as Dolphin, KMail, Kate etc. can now use the Union CSS files as the source of their styling.

However, temper your expectations, as this is the first initial release!

My lizard fursona making an smile face.

Do note that there are visual bugs and oddities! I'm still working on things!

So yes, as you can see, some things look off. Not Breeze at all! Some things are just different, some other things have wrong colors.

These are all fixable and I will do my best to get as many things as possible fixed for the Plasma 6.8 release.

But some other oddities are kind of expected: This is the first time ever Breeze QtWidgets and QtQuick style have same shared source-of-truth as an easily editable file! (Excluding colorschemes.) So some of these designs are made with QtQuick in mind, so they can look a bit off in QtWidgets.

I'll go through here what I did and what still needs to be done, but this was a huge undertaking, so I'm having a small celebration for the very first release of this. :)

Hold on, can I try it!?

Yes! It should be released in Plasma 6.8, unless someone tells me no. As of writing this, nobody has said no.

You can make your own CSS files and see them affect QtWidgets apps too. Just expect some breakage and report all the bugs!

Go crazy with the themes. Try everything. Bring back whimsy to computers. Tell us about the theming experience in general.

Have fun. Your computer should be just as cool as you are.

The rest of this blogpost is more a technical rant and ramble as I am venting all the exhaustion over this thing, lol.

QStyle is difficult

QStyle themes, which are the styles that modify the look of QtWidgets applications, are not easy to work on. Most themes I've seen take an existing one, such as Fusion or Breeze and make their changes on top of those.

But for Union, we had to start from scratch. I took the very basic base of QStyle, which is called QCommonStyle (kind of a fallback theme), and began building on top of that.

Then, there was multiple parts:

Thankfully redstrate had already made the painting part for the very simplified proxystyle (which took Breeze and modified it a bit), so I did not have to modify that too much. I mostly had to poke at it to make it work with my hierarchy system. So thanks! <3

It's hard to put it into words how much work there was involving the actual QStyle itself and creating a sort of "framework within a framework" so that the Union rules would translate better for the QStyle rules.

For example, when a widget, such as a PushButton, wants to be styled, it informs the QStyle about it with something called QStyleOptionButton. This class holds bunch of information about the button, and the style can use that information to decorate it better. But of course, the styleoption does not necessarily need to exist. If there is no styleoption, the style can use the QWidget itself for style information. But even that can be empty! And at that point, you do not know how to style something, since you do not even know what it is.

What made matters even worse was that the documentation just Does Not Exist.

Sure, there is the QStyle documentation, but it is more about "what" and not "why" or "how." I could have used somekind of tutorial for how to make a QStyle from scratch, but I could not really find anything, except super old information from Qt4 times. So very very often I resorted to just reading the raw source code itself, which is also not very easy to read. There is a lot of variables that are just named pw or w. So even the codebase is very undocumented..!

Most of the work had to be done with trial and error! "What happens if I change this value?" "What if I use debugger to follow this variable, where will it lead?" I also used Breeze as my information bank a lot, as it had gone through it all before. That was very helpful.

But the lack of documentation and old codebase nobody seems to really touch anymore, much less document, was the thing that made this all take so long time.

My lizard fursona making an grumpy face.

Not to forget the completely misleading names in the API. "PM_MenuPanelWidth" is not the width of the panel, but actually "Border width (applied on all sides) for a QMenu."

The total work was 9000 lines of code. Yes. And all of it is required. Lot's of boilerplate, as QStyle seems to love boilerplate. Pretty much all of it is artisanal, handwritten slop by yours truly.

I had to painstakingly go through all the elements we're drawing and sizes we're calculating, then turning it into an Element that we can easily modify without modifying the whole style.

If you have managed to make a working QStyle theme completely from scratch, going through every little detail, I salute you. This is some of the toughest stuff I've ever worked on.

So in summary: I had to backwards engineer a lot of stuff to figure out what order we even draw some things, or what size affects what in the actual application. Then make it work with Union core and CSS.

My lizard fursona making an scream face.

DOCUMENT YOUR API PLEASE I BEG YOU

Next steps

Next up is testing and bugfixing.

There's already a lot of bugs being found here: https://invent.kde.org/plasma/union/-/work_items/205 And more will be found. There will be weird edgecases where application expects everything to work like in Fusion style, as it's the default Qt style, but Union does not handle that situation yet well.

So here's what I need from you, dear reader: See what breaks. Document it. Make a bugreport. Let's find these weird things and figure them out, so that the QtWidgets side can finally be themed without so much pain.

Of course, there's also the design side: Like I mentioned earlier, the Breeze CSS we have now is very QtQuick oriented, so QtWidgets applications can look and feel odd.

Something to keep in mind though is that QtQuick and QtWidgets applications will likely never look the exact same, due to the way how they work and are drawn. But we can try to make the QtWidgets style work reliably first and then try to make it look as close to QtQuick side as possible.

My todo list is pretty much following:

So, more work. A lot of work.

But at least we can now properly start that work, which is what this first release is about. Getting the tedium out of the way, so the interesting parts can begin.

And boy how much tedium that was. I would never do it again, but honestly.. It was fun at times. Super interesting to figure out. Like a very tough puzzle game. I'm happy with what I've achieved here, even if it's not perfect yet. And I hope all this work is useful for you too, dear users. I really want to see the crazy things you all will come up with.

Thanks for reading!

ps. Again sorry if this reads all over the place, I just needed to get it out of my system. I don't like writing drafts much, so I just write a braindump and go.

28 Aug 2026 6:34pm GMT

27 Aug 2026

feedPlanet KDE | English

Tickets in Transitous

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.

LTG Link route from Vilnius to Kaunas displaying a Tickets button

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

Itinerary screenshot showing bookable connections from Vilnius to Riga

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 :)

27 Aug 2026 9:35pm GMT

Din ordkvot denna månad är slut

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?

27 Aug 2026 8:55am GMT

@ FOSSY 2026

Last week, I went to FOSSY 2026 to participate in Camp KDE!

27 Aug 2026 5:00am GMT

Dolphin 26.08 and KIO, part two: what got faster and smaller

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 files into an empty directory. 1000 x 256 B: 421 ms in 6.25, 189 ms in 6.29, 34 ms for cp. 5000 x 256 B: 2279, 942, 176. 5000 x 4 KB: 2536, 1024, 188. 500 x 1 MB: 538, 327, 230.

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.

Deleting a tree. 1000 x 256 B: 100.0 ms in 6.25, 81.0 ms in 6.29, 13.6 ms for rm -rf. 5000 x 256 B: 509.3 ms, 406.8 ms and 69.4 ms.

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.

First listing of a folder. 5000 files: 136 ms in 6.25, 124 ms in 6.29. 50000 files: 4026 ms and 3443 ms.

Memory held when a folder is shown. 5000 files: 10.2 MB in 6.25, 8.8 MB in 6.29. 50000 files: 58.7 MB and 50.5 MB.

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.

Memory still held after walking twelve folders and leaving them. 12 x 5000 files: 63.5 MB in 6.25, 22.7 MB in 6.29, 2.8x less. 12 x 20000 files: 238.7 MB and 77.5 MB, 3.1x less.

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.

6.30 against 6.29, the longer runs. Listing 50000 files: 1232.9 ms down to 531.5 ms, -57.0%. Copying 5000 x 256 B: 909.3 ms down to 883.8 ms, -2.8%. Deleting a 20000-file tree: 319.9 ms down to 290.9 ms, -9.1%.

6.30 against 6.29, the quicker runs. Listing 5000 files: 36.0 ms down to 33.8 ms, -5.8%. Deleting a 5000-file tree: 80.9 ms down to 72.6 ms, -10.3%.

Allocations for one listing. 5000 files: 151,809 down to 116,393, -23.3%. 50000 files: 1,292,614 down to 983,567, -23.9%.

Peak memory listing 50000 files. Peak heap: 42.45 MB down to 41.68 MB, -1.8%. Peak resident: 81.05 MB down to 78.45 MB, -3.2%.

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:

Deleting 15000 files as one folder, by how deep the tree is. 10 deep: 103.4 ms in 6.29, 84.6 ms in 6.30, 65.3 ms for rm -rf. 100 deep: 136.2, 78.1 and 60.2 ms. 300 deep: 227.2, 77.4 and 62.8 ms. 800 deep: 418.7, 78.7 and 64.0 ms.

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.

27 Aug 2026 12:00am GMT

26 Aug 2026

feedPlanet KDE | English

Re-Introducing KQuickImageEditor: New Features and Design Philosophy

KQuickImageEditor is an image editing library for Qt Quick applications. It was created by fellow KDE developer Carl Schwan. It can crop/mirror/resize/rotate images, it has undo/redo history, and it comes with QML components that make it easy to set up a basic image editor. NeoChat and Photos (aka Koko) have used it since 2020 and 2021.

Screenshot of KQuickImageEditor in NeoChat
Screenshot of KQuickImageEditor's original UI and capabilities in NeoChat

In version 0.6, I added a new image editing system from Spectacle. On top of the existing features, the new system can draw shapes, write text, blur and pixelate. It will also be able to do a wide range of color adjustments soon (likely 0.7). Spectacle and Koko have been using the new image editing system since 2025. It was Spectacle's to begin with, so you could say Spectacle has been using it since 2023. NeoChat and others might use the new system once the number of GUI components have expanded. The old image editing system will remain available for the foreseeable future so that apps using it will not break.

Screenshot of KQuickImageEditor in Spectacle
Screenshot of KQuickImageEditor's annotation capabilities in Spectacle. There isn't just one UI anymore.

My design philosophy for the new system is based on the idea that APIs should be minimal, but highly flexible by reusing existing components. It's supposed to be like how you can buy a LEGO set and make many different things with the same pieces. For example, the upcoming color adjustment API takes a QMatrix4x4 to apply linear adjustments to RGB channels with the top 3 rows and non-linear/perspective adjustments with the 4th row. It's just like using a QMatrix4x4 or mat4 (GLSL) for 3D graphics, except your dimensions are red, green and blue. I could have made the API just for brightness and contrast effects (to be used by Koko), but the choice to use a QMatrix4x4 means you can do a lot of things just with Qt's existing APIs. From there, I can still add APIs to create 4×4 matrices for specific effects, but apps don't need to wait for KQuickImageEditor to have an API for the color adjustment they need. They can make their own 4×4 matrices by applying general mathematical concepts.

The core components of the new system are AnnotationDocument and AnnotationViewport. AnnotationDocument has all of the APIs for manipulating QImage objects and undo/redo history. AnnotationViewport is a custom QQuickItem subclass that can render images, update in response to changes from AnnotationDocument and provides QPainterPath/SVG path data for outlining annotations when using the selection tool. There are also a few QML components for features that most viewport implementations can be expected to implement the same way, such as outlines for annotations that are selected or hovered over. The only truly necessary part is AnnotationDocument. Although KQuickImageEditor is for Qt Quick apps, you could connect AnnotationDocument to a custom viewport made with Qt Widgets.

At the moment, there aren't many GUI components in the API because apps may have different needs and I don't want to force the use of a particular UI. I might add standard action components for each tool type in the future to make setting up toolbars, floating toolbars or toolboxes easier, but there are still a lot of things to decide on before adding more visual GUI components to the API. There is a documentation website, but the documentation needs quite a lot of work, so reading the header files and looking at how Koko and Spectacle have used the system are currently the best ways to understand it.

The API of the new annotation system is considered unstable. As an example, AnnotationDocument and AnnotationViewport have names that no longer match the scope of what they are for, so they might change before stabilizing the API. However, I don't break apps on a whim. If the API or ABI has to have a breaking change, it will be communicated and there will be a path to prevent KDE apps on the Gear and Plasma release schedules from breaking in between their releases.

Just so it's clear, even the new image editing system is not supposed to compete with advanced image editing systems like what Krita and GIMP have. The exact scope is not firmly defined, but it's pretty likely that certain features like layers or a wide variety of brushes will not be implemented.

I intend to make more posts about the new image editing system and its history within Spectacle in the future.

26 Aug 2026 7:06pm GMT

Week 10 + Week 11: Subsetting for freetext annotations is merged

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,

What's remaining:

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

Thank you,
Ojas

26 Aug 2026 9:39am GMT

Dolphin 26.08, and KIO perf improvements

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.

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:

commits 207, of which 97 code changes
lines 3822 added, 772 removed, net +3050
contributors 22
first time in Dolphin 13 of those 22
returning 9

The busiest by a wide margin:

Contributor commits added removed
Sebastian Englbrecht 31 1145 87
Méven Car 29 706 236
Pan Zhang 6 424 58
Felix Ernst 5 250 165
Ramil Nurmanov 2 428 54
Alessio Bonfiglio 2 406 22
Kai Uwe Broulik 2 58 4
Akseli Lahtinen 2 49 42
Antti Savolainen 2 37 12
Filip Fila 2 13 5
Oleksandr Bondar 2 11 6
Sergey Katunin 2 11 5

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:

Bug What Who Commit
492298 Menubar visibility applied after the UI has loaded Oleksandr Bondar c3ef613f
506884 Inline rename preserved when the item scrolls out of view Pan Zhang 5e35194b
508465 Item widgets use style primitives instead of custom painting Akseli Lahtinen 61b6e173
509150 Wrong item count in the Size column for folders of 200+ entries Pan Zhang 914cd901
510469 Animated-height widgets no longer scroll the viewport Pan Zhang cde91dd7
514401 Re-triggering an inline rename made robust Méven Car 7ca6daea
515236 No spurious history entry when leaving search results Pan Zhang 35b309aa
518285 Non-Breeze styles may style the non-toolbar navigation bar Filip Fila 76f6eb07
523348 Delete action shown in selection mode in the trash Méven Car d392e6b5

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.

26 Aug 2026 12:00am GMT

25 Aug 2026

feedPlanet KDE | English

What’s Happening In KDE Remote Desktop – Improved Unattended Mode and More

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:

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.

A graph taken midway through optimising

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!

25 Aug 2026 6:29am GMT

Redesigning Lokalize's Translation Memory Tab - GSoC Week 9

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.

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.

25 Aug 2026 12:00am GMT

24 Aug 2026

feedPlanet KDE | English

Sovereign Tech Fellowship for Freedesktop Tasks

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! 🙂

24 Aug 2026 9:00pm GMT