Skip to content

Tuesday, 25 August 2026

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.

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!

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.

Monday, 24 August 2026

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

Saturday, 22 August 2026

Tellico 4.2.2 is available, with some improvements and bug fixes.

Improvements:

  • Updated to automatically add default file extension (.tc) to save files with no extension.
  • Removed gradient image files for entry templates, in favor of data URLs.
  • Added option to disable ISBN validation in entry editor (Bug 514622).
  • Improved ISBN formatting for all country regions (path from Alex Oio).
  • Updated ISBN validation to apply to multiple values (Bug 521157).
  • Updated UPCItemDb to accept multiple search values.
  • Improved caching of entry images for the icon view.
  • Improved Title search for arXiv and OpenLibrary sources.
  • Improved entry updating from iTunes source.
  • Added drag-and-drop text importing for RIS.
  • Removed defunct DVDFr data source.

Bug Fixes:

  • Fixed crashing bug when exporting HTML for entries with no title (Bug 523140).
  • Fixed bug with updating UI after checking-in entries.
  • Fixed bug with updating UI for updating entries (Bug 522673).

Welcome to a new issue of This Week in Plasma!

This week was heavy on improvements for both the user interface and also performance, helping Plasma 6.8 to shape up quite nicely:

Notable new features

Plasma 6.8

When using the system in a language other than English, you can now search for and find System Settings pages using keywords in English as well as the current language. (Sergey Katunin, systemsettings MR #418)

Search for “mouse” and it finds “souris” (“mouse” in French)

You can now disable entries on System Settings’ Autostart page without having to fully delete them. (Ramil Nurmanov, plasma-workspace MR #6951)

Disable-able autostart entries

Notable UI improvements

Plasma 6.8

You can now select on the lock screen which authentication type you want to use when multiple types are available, and each one gets a nicer UI. This is an experimental change that just landed, and there’s no GUI yet to set up all the authentication types. We’re working on documenting it, for a start! (Harald Sitter, plasma-desktop MR #3689, plasma-workspace MR #6542, and kscreenlocker MR #318)

Selectable authentication methods on the lock screen

You can no longer set the resolution to a value so low that you’ll probably break your system and be unable to recover without the intervention of an expert. (Xaver Hugl, kwin MR #9765)

Improved the alignment of the buttons on the lock screen, which is especially visible in some languages. (Ramil Nurmanov, plasma-dsktop MR #3951)

New New
Old Old

Discover now remembers which reviews you’ve rated as useful or useless and doesn’t let you submit new ratings for them later, because the reviews server doesn’t support this, and it would emit an ugly error code in response to you trying. (Taras Oleksyn, KDE Bugzilla #521866)

Auto-hide panels now hide themselves only 50 milliseconds after the pointer leaves them — reduced from the previous value of 500 milliseconds. This makes them feel much more responsive. (Seb Jo, plasma-workspace MR #6885)

The automatic brightness feature now adjusts in a smarter way to any manual brightness changes you make, so the system does a better job of learning your screen brightness preferences in various lighting conditions over time. (Matt Whitlock, kwin MR #9237)

When an Audio Volume widget is placed on a panel in standalone form, its popup now starts out large enough to accommodate everything in it without scrolling. (Nate Graham, KDE Bugzilla #522654)

New New
Old Old

Improved the way error messages from the audio subsystem are communicated to the user while using the microphone tester feature. (Nate Graham, plasma-pa MR #419)

Implemented highlighting for non-default settings on System Settings’ Remote Desktop page. (Tobias Ozór, krdp MR #232)

Cursor feedback effects now dodge screen edges, so they are always fully visible. (Oliver Beard, KDE Bugzilla #498068)

KWin’s notifications about GPU resets now trigger for all GPUs, not just the primary one. (Xaver Hugl, kwin MR #9768)

Improved the Breeze styling for GTK 4 apps’ menus and window borders. (Rocket Aaron, breeze-gtk MR #104)

Notable bug fixes

Plasma 6.6.7

Fixed multiple issues relating to Discover failing to terminate all of its processes after quitting, which would lead to it being unable to launch properly later. (Aleix Pol Gonzalez, discover MR #1393)

Fixed multiple issues relating to System Settings not switching its sub-category sidebar view when expected during various less-common modes of interaction. (Mradul Pal, systemsettings MR #415)

The Digital Clock widget’s tooltip no longer lets really long text overflow; instead it expands to make room. (Luis Bocanegra, plasma-workspace MR #6950)

The Weather Widget no longer shows info buttons for alerts that do nothing when clicked; now they only appear if they’ll do something. (Nate Graham, KDE Bugzilla #519676)

Plasma 6.7.5

Fixed multiple cases where the “KDE daemon” background process could crash while reading to or writing from the system’s password storage system when network conditions changed in various ways. (Mickaël Thomas, plasma-nm MR #624)

Fixed an issue where Task Manager window thumbnails could sometimes go missing. (Vlad Zahorodnii, plasma-desktop MR #3959)

The Calendar widget no longer oddly changes the date it’s showing when dragged from one screen to another. (Antti Savolainen, KDE Bugzilla #472360)

Plasma 6.8

Screen readers can now read all of the UI elements on the Activities sidebar. (Nate Graham, KDE Bugzilla #519306)

Using the clipboard’s “Keep the selection and clipboard the same” setting no longer breaks the ability to copy multi-cell data between sheets of a spreadsheet in LibreOffice Calc. (Tomáš Hnyk, KDE Bugzilla #505209)

When a remote desktop connection is unexpectedly severed, the System Tray icon notifying you about it now disappears as expected, instead of sticking around until the system is restarted. (Nick Haghiri, krdp MR #234)

Fixed two issues where the Audio Volume widget would show the wrong panel icon under some unusual conditions. (Seth Morris, plasma-pa MR #422)

Frameworks 6.30

The “Do you really want to permanently delete this item?” dialog for items on the desktop no longer percent-encodes special characters in file names, because it looked ugly. (Nate Graham, KDE Bugzilla #522470)

Notable in performance & technical

Plasma 6.8

Discover’s background notifier process now uses much less memory when it checks for updates. (Méven Car, KDE Bugzilla #509180)

Improved Plasma’s startup speed a bit by doing less unnecessary work when loading wallpapers. (Nicolas Fella, plasma-workspace MR #6898)

Further improved the speed and efficiency of KWin’s “take a screenshot” functionality. (Zhora Zmeykin, kwin MR #9756)

Improved the smoothness of screen recordings made on high-refresh-rate screens. (Fililip, KDE Bugzilla #524129)

The microphone tester feature now records audio at the system’s current sample rate rather than forcing a 44.1kHz sample rate, which could have ramifications elsewhere on the system if you’re doing audio production. (Dan Fi, KDE Bugzilla #523693)

Frameworks 6.30

Improved the way SVG images are cached, which slightly increases speed and reduces video memory usage. (Méven Car, ksvg MR #115)

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.

Intro

Helloooooo,
it’s me again, Ansh! , the mentee who has been working on the Join.kde.org
This is the final update within the official timeline of GSoC 2026 for my project: Building Join.KDE.org.

A quick summary:
Over the past 12 weeks, I have worked on creating, designing and implementing the join.kde site into a platform that can answer most of the basic questions a new contributor has. In this post, I’ll mainly focus on the progress from Week 6 to Week 12 along with my final thoughts.

For a short summary, checkout this status report.


Week 6: Contribute/suggest

This week I worked on the ADD section which got renamed to contribute, it includes several sub sections which allows people to contribute based on their interests.

Routed the explore section to KDE.org for you section so people can explore and find their own use for KDE softwares.

Created the suggest section which contains the information on how to report bugs/request for features.


Week 7: Navbar

This week was more about improvements on the navbar, I noticed with all the text the nav-bar looked way too cluttered, and simply overwhelming so with the advice from Anish and how he changed the navbar for the mentorship website, I worked up something similar and made dropdowns for the navbar so it can still have more content when clicked.


Week 8: Work on Projects

For this week I worked on the work on projects section which allows people to find groups of projects in invent based on skillset or the programming languages one knows.

I added all the groups available in KDE invent in this section which little tags of skillset.


Week 9: Incubate projects

Worked on designing Incubate projects section: which basically explains what kind of projects fit in KDE and what are the benifits of it. Linked it through a call-to-action button to the relevant resources to incubate project into KDE.


Week 10: read page/ suggest page improvement

Designed the read page with 3 main blog sites

  • planet
  • contributor blogs
  • mentorship blogs

This week was something new, the cards for the read page were simple but the new design of dropdown in suggest page took some time figuring out. added konqi images to the cards because duh it's konqi (but hey we can change them eventually).


Week 11: Divulge Page

Created the Divulge page which is more for people who want to create content for kde whether it be promo material, tutorials or whether help in promotion itself.

It's kind of a copy of the read page but it can always be changed.


Week 12: Events Page

Created the Events page, which included akademy as the main event and then a section for event's KDE hosts which had some sprints and conf.in and then added the section for the events KDE participates in which will likely be expanded eventually.

Fixed some tiny typos and dead link issues.



My Own Development

I learned a lot from this project, both in coding and beyond. Here are the things I remember right now, though the list could go longer:

  • Now I am very comfortable with Hugo, semantic maps, and YAML files
  • Finally learned how to deal with SVGs (was my first time working with them)
  • My frontend skills improved, I think I can design better pages now
  • I now want to create more stuff that helps people!

Conclusion

Overall, GSoC 2026 has been a great experience for me. Over these 12 weeks I got the chance to work on issues that i faced myself and fix them in a way that helps everyone joining KDE.

Along the way I learned some technical skills, learned how to work across different timezones, to communicate better, and most importantly realized that long discussions are often more necessary than jumping straight into implementation, especially in open source communities.

Big thanks to my mentors Anish and umm Conulting mentor Paul

This wraps up my GSoC journey, but I will be sticking around KDE and plan to explore other projects, especially in the mentorship side of things. See you around in the community.


How to Reach Me

Friday, 21 August 2026

I daily drove KDE Linux for almost a year and I liked it, but I'm also switching back to Fedora KDE. Here's my ramblings about it all.

KDE Linux is the hot new Linux distro from KDE themselves. At the moment it uses Arch Linux as it's base but with heavy modifications and changes. You can read more about it on the site, but to sum up: It's an atomic/"immutable" distro that does not have any kind of package management outside of installing flatpaks. (Do note that they're experimenting on using buildstream instead of Arch Linux.)

As one of the KDE devs I've been daily driving it on my desktop, which I use for both work and leisure (gaming).

The following text can be quite technical as I am viewing this through my developer workflow lense, though I will also touch on regular user things.

Upsides

My lizard fursona making an smile face.

For general purpose computing and KDE dev, things are looking great!

Honestly, it works rather well, considering the alpha status. And for development purposes, the nightly builds of the newest hottest stuff from our git repos is very nice: I don't have to build everything myself every morning.

Though there are some issues with that too: Sometimes the servers are not producing a new image, for reason or another, so I may end up building things myself anyway. Some other times, there is an image that just has some broken change in. Luckily in those situations I can just boot a previous image and use that.

What I really liked though was the systemd-sysext workflow. Sysext is a tool that allows me to layer my changes to the system on top of the previous stuff. So when the system is running /usr/bin/konsole it actually runs my self-built /home/akseli/Projects/kde/usr/bin/konsole. As far as the system is concerned, it's in the same path.

What we currently do in other distros is some environment flag magic to run things from the build-path, instead of /usr/bin/. It also works fine, but can be a bit more brittle, especially when testing something like a login manager.

The workflow is simple:

  • I build my changes to an app, Plasma desktop component, etc. using kde-builder.
  • I refresh the sysext with run0·systemd-sysext·--always-refresh=yes·refresh;
    • sudo works too, i use run0 because it has the popup so I notice it after a long build.
  • The changes are now live on my system!
    • Apps may need to be restarted sometimes of course.
    • If something goes wrong, I can just clean the sysext folder.

It feels more robust and easier to manage.

So on this front, KDE Linux has been really fun to work with. Perfect for testing and development of all the KDE Plasma stuff.

When it comes to applications from flatpaks, they usually work fine, but they can have the typical flatpak issues: Some app needs a permission to a folder that it can't see, so you have to turn off the app, add permissions, turn back on the app, yadda yadda. Apps that use XDG portals properly usually work fine, though there's a bug somewhere in the stack that when the system updates (the atomic image of the OS changes), the portal forgets the folder paths and you have to reopen the file for the path to refresh.

When it comes to gaming stuff, Steam Flatpak has worked really well. I have not noticed any issues compared to the native package. Same with Bottles, all has been just fine and nice. Though sometimes there has been bugs with running games, such as games not locking your cursor properly, but they're often gone with the next update as more people spot these bugs now.

Downsides

My lizard fursona making an sad face.

With anything more complex than what the system is intended for, things get difficult.

As an atomic distribution, it is expected that any dev tools that are not already installed on the machine, such as your favorite terminal tools or text editors, you will have to either to download them from the internet like a Windows user (plop the binary in ~/.local/bin), or use Distrobox/Kapsule/Toolbox... etc.

Container workflow feels cumbersome to me most of the time. For KDE work, since all the tools to build and run applications are already installed on the system, it's rather effortless. But when I want to continue a game project like my Artificial Rage game project, I would have to enter a distrobox, install all the things, then edit and build the application inside that container. And when I switch a project, it's expected I create a new container for that, and so on.

I don't really like that. I prefer my tools to just be available on the host so I can run them without messing with containers: I have bad memory and am terrible with context switching, so I keep forgetting changing or creating containers.

What I did instead was create bunch of dumb scripts called dbi that are a wrapper for installing tools and "exporting" them from the distrobox so I can use them on host without having to enter them. By exporting I mean they use the distrobox-export command that creates a symlink to your ~/.local/bin with the app name, so you can just run them from terminal like always.

It's not ideal, but it works. Sadly this comes with a performance deficit when running programs like eza, which is ls alternative that shows icons. I like my little icons. :) When running eza directly on host, it runs immediately, but when using the distrobox version, it will take 1-2 seconds, which gets surprisingly annoying when going through folders. No idea if that could be improved somehow, but the speedbump is likely from the part where it enters the container.

This reveals the larger downside: Lack of "blessed" package management, especially for commandline applications.

I have tried multiple tools, but all of them had some issues:

  • Brew, while had great user experience, would sometimes overtake the system python installation and break kde-builder
    • I don't know if this has been fixed? I have not dared to try.
  • Coldbrew, which has similarly nice user experience, but the package versions can be hit or miss
  • Nix, which is very overcomplicated for this usecase and the user experience is just annoying
    • It works, but you will have to remember to garbage-collect and whatnot every time you update apps
    • Fixable with a nice wrapper, I think
    • However some claim this is "not the Nix way" so I'm left here wanting something this tool can do but is not meant for?

Which left me with always just using distrobox and accepting the performance and UX penalty.

Another thing I miss is having KMail and KOrganizer just installed on my system, talking with my digital clock applet so when I click on it, I would see my calendar event. It's very small thing, but it's huge quality of life feature for me. The Kontact flatpak can't do that, and it's sadly really broken in general.

Lastly, as I work on the Union style engine, flatpak applications will not see the Union styles yet. This means I will have either to build a separate KDE platform for it myself using the CI, which can be super slow. Especially if I have to build it multiple times to see the changes. I can build some apps myself but more complex ones such as KMail will take a lot of time for me. This is where I miss just installing an app from dnf on Fedora, as it can just use the styles on my computer, as the app is also installed on the host like the Union style is.

Regular use and my use

For regular user, who plays video games and uses a web browser and never really touches terminal, I think KDE Linux will do very fine, especially when it starts having stable releases that do not update every night. At it's current iteration, it's more a developer tool than something I would recommend for regular user, unless you're super enthusiastic or have spare machines.

But me, being the nerd that writes blogposts about Linux and KDE that I am, I like having more control over the system. I don't mind having all my dev tools cluttered on my host system. (However if it touches NPM, it's going into a container. Luckily I rarely have to bother with that.) And in general, atomic distributions can be rather opinionated: If those don't match your view of the distribution, it can be hard to get along as you can't really modify it for your usecase. (Yes I know about ostree.)

So I would say that the more complicated your usecase gets and if you need tools that are not already in the base system, it can get quite cumbersome.

So that's why I'm switching back to Fedora KDE: It gave me all the control I needed. I will likely stil use flatpaks for almost all apps on my machine though, as I do find sandboxing rather useful at times.

I highly encourage anyone who wants to test newest KDE stuff to run KDE Linux on a VM or a secondary machine. I will keep using KDE Linux on my laptop as there I don't have so many different needs, and I want to just install the new shiny stuff from git, not build on it, as building anything on that laptop is super slow.

This whole thing has also made me realise something..

My lizard fursona making an smile face.

All distros have their own strenghts, weaknesses and tradeoffs. It's all about choosing what works for you and your system.

My desktop system will benefit from Fedora KDE, but my laptop will benefit from KDE Linux.

I will keep observing how the story of KDE Linux develops. I may try it again on my desktop later, we will see.

Some of you reading might ask: "But why Fedora KDE?"

It's one of the nicest distros I've used when it comes to KDE stuff. The people working on Fedora KDE are some of the nicest folks I've met with, and they work very closely with KDE upstream. Fedora KDE follows KDE releases really closely so it feels like I'm always on current release, making the development workflow very easy.

Thanks for reading!

ps. Friend sent me this and I cackled like a hyena.

Dumb meme about me liking the popup more than security features

Thursday, 20 August 2026

The last two weeks were spent polishing the mobile-friendly selection mode based on Marco Martin's review feedback, wrapping up the multi-select work that's been the focus since weeks 9 and 10.

Selection Mode Refinements (!46)

The first version of Selection Mode had a few issues. The checkbox was not properly aligned with the entry text, so I changed the delegate to use a RowLayout. This keeps the checkbox directly next to the label and vertically centered.

Marco Martin also suggested that the whole row should be clickable, not just the checkbox. I moved the selection logic into a shared page.toggleSelection() function and used it for both mouse and touch taps. This makes selection work the same way on both devices.

For the toolbar, only "Delete Selected Secrets" and "Exit Selection Mode" should be available during selection mode. I added visible: !page.selectionMode to the other actions so they are completely hidden, including from the overflow menu.

OLE-Dispatch When Doing MFC/Qt Migration

Most people who have ever ported an application from MFC to Qt know that at some point they have to integrate a QWidget into an MFC part of the user interface. Or the other way around, but that's a different story. Normally you would simply use a QWinWidget for that to do exactly what you want. But what happens if your application created the old MFC window as an OLE Control Extension (OCX)? In that case the easiest solution is to intercept the control name and provide it to your own factory providing the correct widget, which can then be embedded in a QWinWidget. Or you could use plugins to stick to the idea of it being DLLs. All roads lead to Rome. But what if your OLE based application uses the OLE-Dispatch way of initializing the controls? Setting properties, invoking methods, and so on?

I had exactly that problem and came up with a solution which glues OLE's IDispatch interface together with Qt's QMetaObject. That means you can access your QWidget's (or any other QObject) properties via the IDispatch interface provided by my QObjectDispatcher class. They only need to be declared via Qt's Q_PROPERTY macro. The same applies to slots and methods marked with Q_INVOKABLE.

Let's see how this is being used:

// This is the widget we're working with:
QWidget* someWidget = ...;

// Lets' create our dispatcher:
// You have to delete it yourself or let COM do it for you via IUnknown::AddRef/Release
QObjectDispatcher* dispatcher = new QObjectDispatcher(someWidget);

// The code until this point is the only part which is new in your application, as
// far as dispatching the calls/properties is involved. From here, it's exactly the same;
// from the OLE MFC application's perspective we often only have an IUnknown:
IUnknown* pUnknown = dispatcher;

// Now get the interface and start playing with it:
CComQIPtr<IDispatch> pDispatch(pUnknown);

// First we have to retrieve the index of the property we change
LPOLESTR name = "windowTitle";
DISPID dispId = -1;
pDispatch->GetIDsOfNames(IID_NULL, &name, 1, LOCALE_SYSTEM_DEFAULT, &dispId);

// Now that we have the index, we change the property
VARIANT varTitle = CComVariant("New window title");
DISPSPARAMS dispParams = { nullptr, nullptr, 0, 0 };
dispParams.rgvarg = &varTitle;
dispParams.cArgs = 1;
pDispatch->Invoke(dispId, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_PROPERTYPUT,
    &dispParams, nullptr, nullptr, nullptr);

As you can see the API of IDispatch is not fun to work with and there's no reason to use this except of making that kind of stuff work in existing MFC/OLE-applications while porting. I strongly advise against using it in new code.

How does that work? Well, the IDispatch interface works in two steps. First, you have to request the ID of the method/property you want to access via GetIDsOfNames. You can request several IDs at the same time. QObjectDispatcher traverses the methods of the handled QObject via the corresponding QMetaObject. It then returns the index of the method. If there’s no method found, it checks for a property. If it’s found, it returns the index of the property plus the number of methods, to be able to recognize the type afterwards. If neither a method nor a property by that name is found, an error is reported.

Let’s have a short look at how GetIDsOfNames roughly works. That example code cannot be used directly but gives you a rough idea of the implementation:

HRESULT QObjectDispatcher::GetIDsOfNames(REFIID riid, LPOLESTR* rgszNames, UINT cnames, LCID, DISPID* rgDispId)
{
    // GetIdsOfNames supports requesting several at the same time
    for (uint i = 0; i < cNames; ++i) {
        // note you cannot use QMetaObject::indexOfMethod directly, 
        // since it expects the fully qualified name
        auto indexOfMethod = []() { /* ... */ };
        const int methodIndex = indexOfMethod(rgszNames[i]);
        if (methodIndex != -1) {
          rgDispId[i] = methodIndex;
          continue;
        }
    }
    // now do the same for the properties...
    // [...]
    return S_OK;
}

In the second step you can call Invoke to either invoke a method or to access a property. For this you need to pass a struct DISPSPARAMS which contains the arguments. rgvarg is an array to several arguments which are stored in reverse order. QObjectDispatcher will now pick the method or property (depending on the id passed and whether you passed DISPATCH_PROPERTYPUT, DISPATCH_PROPERTYGET, or DISPATCH_METHOD) and call it. For this it has to translate the arguments. For method calling, they need to be translated to QMetaMethodArgument or QMetaMethodReturnArgument for the return value. For properties, we have to go through QVariant to be able to read/write the property via Qt’s Meta Object System.

Let’s also have a look at how Invoke works internally. Even here, this code piece is not complete and won’t work directly:

HRESULT QObjectDispatcher::Invoke(DISPID dispIdMember, REFIID riid, LCID, WORD wFlags, DISPPARAMS* pDispParams, VARIANT* pVarResult, EXCEPINFO*, UINT*)
{
    if (wFlags == DISPATCH_METHOD) {
        const QMetaMethod method = metaObject->method(dispIdMember);

        // translate return argument
        auto returnArgument = translateReturnArgument(method, pVarResult);

        // then call the method, translating all the arguments
        invokeMethod(method, m_object, returnArgument, translateArgument(0), ...);

        return S_OK;
    }

    // [...]
}

So, in your application, which expects a CWnd generated by some factory, you do the following:

  • Create a wrapper CWnd which you actually return to the caller. This CWnd will in some way provide access to an IDispatch instance like it was doing before your port
  • Create a QWinWidget residing inside of the CWnd.
  • Put your portedQWidget into the QWinWidget
  • Create a QObjectDispatcher working on your ported QWidget
  • Make your CWndreturn this QObjectDispatcher as IDispatch

Now your application should threat your ported widget as it was never ported. Of course, you have to provide the same properties and methods as the system expects using Qt's Meta Object System (Q_PROPERTY, Q_INVOKABLE).

There are, of course, some limitations:

  • You cannot overload names of methods as OLE doesn't allow that
  • Optional parameters are not supported, as QMetaMethod doesn't reflect that (or I simply haven't figured out, who knows…)
  • You have to provide a type-mapping for the argument types. The example project linked below provides only IUnknown*, int, and QString as these are the most common ones and show how it works
  • The example solution is not thread-safe

Find the complete code as a little example project on KDAB's GitHub repository at: https://github.com/KDABLabs/blogs-qt/tree/main/MFC-Migration-OLE-Dispatch

The post OLE-Dispatch When Doing MFC/Qt Migration appeared first on KDAB.

Animation on Android and new Transform Tool and Color Sampler features? Read on for a look at development news and the Krita-Artists forum's featured artwork from last month.

Development Report

Krita 5.3.3 Released

Krita 5.3.3 was released with various fixes as well as revamped Android supporter donations.

Developments in Krita Plus

Animation rendering on Android is now possible, via MediaEncoder and LibAV. (change by Carsten Hartenfels)

Support for the XCF file format native to GIMP has been removed, as the xcftools library that was used is long outdated and unmaintained. It's recommended to instead use GIMP to load XCF, and use the OpenRaster (.ora) interchange format for exchanging files between programs. (change)

Some font-related crashes at startup have been fixed. (bug; change 1, change 2 by Wolthera van Hövell)

The new menu options on Android for interface scaling and supporter options not appearing if toolbars had previously been customized has been fixed. (change by Carsten Hartenfels)

A crash when redoing joining and then deleting paths with the Edit Shapes tool has been fixed (bug; change by Elena Sagalaeva), as well as deleting subpaths deleting the wrong ones due to shifted indices (bug; change by Luna Lovecraft). Additionally, path segments can now be deselected with Shift-click (change by Luna Lovecraft).

Developments in Krita Next

The Transform Tool's Liquify mode has a new mode. "Restore Shape" undoes previous distortions while keeping the new position of a shape, and optionally keeping the rotation, scale, and stretch. (change by Moritz Staudinger)

Using the Transform Tool to rotate, distort, and move a triangle, then using Restore Shape to remove the distortions while keeping the new rotation, position, and scale.

The Color Sampler can now show a zoomed in preview in order to precisely pick a pixel, when using the circle color preview. This "Zoom Preview (Pixel-Perfect Color Sampler)" option is in preferences under General->Cursor alongside the option to switch between the circle and rectangle preview. (change by Đạt Lê)

Using the zoomed color sampler preview to pick Kiki's eye color from the Krita 5.3/6.0 splash artwork without zooming in on the entire image.

Various HDR metadata can now be saved into .kra files and viewed in Image Properties. This HDR metadata will also be used when rendering animations. (change by Wolthera van Hövell)

Community Report

July 2026 Monthly Art Challenge Results

The winner of the "An Imaginary Friend" challenge is…

Join This Month's Art Challenge!

For August's Kiki-focused theme, last month's winner has chosen "Kiki's Epic Adventure". The optional challenge is to create separate assets for textures or repetitive elements and paste them into the scene. Build up Kiki's story and take us on a dramatic adventure!

This month's featured forum artwork, as voted in the Best of Krita-Artists - June/July 2026:

Participate in next month's nominations and voting to voice your opinion on the Best of Krita-Artists - July/August 2026.

Krita is Free - But You Can Contribute!

Krita is free to use and modify, but it can only exist with the contributions of the community. A small sponsored team alongside volunteer programmers, artists, writers, testers, translators, and more from across the world keep development going.

If this software has value to you, consider donating to the Krita Development Fund. Or Get Involved and put your skills to use making Krita and its community better!

Krita's mascot Kiki putting money in a piggy bank

Additional Changes

Krita Plus (Stable, 5.3.4/6.0.4-prealpha):

  • Text Tool: Fix a crash when using the SVG text editor's editing actions (Undo, Redo, Cut, Copy, Paste). (bug; change by Luna Lovecraft)
  • Wide Gamut Color Selector: Fix color preview popup appearing in the wrong place and not disppearing when the docker is borrowed into the Pop-up Palette or toolbar Docker Box. (bug; change by Luna Lovecraft)
  • Filters: Fix the Color Adjustment filter dialog's curve point controls not working until switching channels. (change by Moritz Staudinger)
  • Assistant Tool: Fix toggling show/hide assistants not taking effect until the canvas is interacted with. (bug; change by Luna Lovecraft)
  • File Formats: Don't show data loss warnings when exporting, since it doesn't affect the original file, and don't warn about inability to save selections, since they are expected to be temporary. (change 1, change 2, by Carsten Hartenfels)
  • General: Add icons for convert, selection modifier, and close actions. (change 1, change 2, change 3, by Arkady Flury)
  • Python Plugins: Comics Manager: Fix a huge memory leak on export, partially re-add exporting vector panels and text, and other small fixes. (bug; change by Wolthera van Hövell)

Krita Next (Unstable, 5.4.0/6.1.0-prealpha):

  • Color Management: Set default display rendering intent to RelativeColorimetric. (change by Dmitry Kazakov)
  • Assistant Tool: Show assistants' custom colors at the bottom of their editors to distinguish them. (change by Carsten Hartenfels)
  • General: Add an option to show or hide icons in menus, or keep the platform default, in preferences under General->Window. (change by Timothée Giet)
  • General: Add icons for 10 brushes and 10 scripts actions, and add an action for Ten Scripts. (change by Arkady Flury)

Nightly Builds

These pre-release versions of Krita are built every day.

Note that there are currently no Qt6 builds for Android.

Get the latest bugfixes in Stable Krita Plus (5.3.4/6.0.4 prealpha): Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5

Or test out the latest Experimental features in Krita Next (5.4.0/6.1.0-prealpha). Feedback and bug reports are appreciated!: Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5