The latest updates to qmlformat, Qt's own tool for formatting of QML files, bring two practical improvements: configurable line breaking and automatic import sorting. These features enhance code readability and maintainability, making them valuable additions worth highlighting.

Plasma's upcoming first-run experience is coming along nicely.

After a bunch of research and discussions we settled on continuing / fixing up the KISS project (KDE Initial System Setup) for the new First Run Experience (FRE) / Out-Of-Box Experience (OOBE). It was in a sort of half finished state.

Since then has been a bunch of work on it such as:

• Getting it to compile and run
• Whole bunch of fixes, cleanup, and polish to the UI, UX, and code/developer experience
• Implemented the ability to actually create the new user (you could enter a name and password, but it was all basically placeholder GUI previously)
• Added language selection front/back ends
• Added basic build / run instructions to the README
• Added ECM logging
• Cleaned up the debug output which made changes more difficult
• Added basic CI (thanks Nico!)
• Added keyboard layout selection front/back ends

That last one was more difficult than expected.. turns out keyboard layouts can be quite complex!

First came some refactoring of the keyboard layouts KCM from plasma-desktop so we could reuse some of the existing, complex functionality. Then adapting a UI/UX appropriate for the FRE. Investigating things like keyboard models, detecting defaults, mapping language to keyboard layout, etc..

Then taking the results of the user choice and figuring out how to apply that both to the system as a default (systemd-localed dbus call) as well as to the running Plasma session (setting the value manually in the kxkbrc keyboard settings file).

As is often the case with software development, that succinct summary belies the massive amount of work it took to get there! 😅 💪

With that work completed, we have most of what is needed for a minimum viable product!

Next up:

• Granting authentication without a user prompt
  • Plan: special user with sysusers.d and a polkit rule
• Running automatically on first boot & in live sessions
  • Plan: systemd unit seems promising, but more research is needed
• Improve documentation
  • Especially related to building & running without kde-builder
• Think about the name
  • I am not thrilled with the KISS acronym personally 🤷‍♀️

There is also obviously a lot of improvements and polish that can be made, but for now here is a preview of the FRE:

These past few week’s my focus was on exploring input device detection and event handling mechanisms in Linux, with a particular emphasis on game controllers and their potential integration into KWin. I also spent time reading through KWin’s input-related source code to understand how it currently manages devices, and began reviewing documentation for various Linux input subsystems—including evdev, HID, and /dev/input/jsX in order to evaluate which layer would provide the most reliable and straight forward support for integrating controller recognition. The time was mostly spent learning how to use different libraries, tools and creating virtual controller prototype.

Tools, Libraries, and Concepts Used

libevdev

libevdev is a library for handling evdev devices. It provides a higher-level interface over /dev/input/event* and abstracts much of the complexity of input event parsing.

evdev is the generic input event interface. This is the preferred interface for userspace to consume user input, and all clients are encouraged to use it.

-The kernel development community.

libevdev can be used to:

• Detect physical game controllers.
• Read input events (e.g., joystick, buttons).
• Create virtual input device and write/forward events to it from physical game controller.

Useful functions:

• libevdev_new(), libevdev_set_fd(int fd, struct libevdev **dev): for opening physical devices.
• libevdev_next_event(struct libevdev *dev, unsigned int flags, struct input_event *ev): for polling events.
• libevdev_get_id_*(const struct libevdev *dev): to query device meta data.

uinput (User Input Subsystem)

I used the Linux uinput subsystem to create a virtual input device that mirrors a physical controller input. uinput is what allows us to make a virtual controller out of any evdev device by:

• Opening a file discriptor for the input device that will be emulate (i.e. have it input event forwarded).
• Forwarding the inputs from a evdev interface device to /dev/uinput (or /dev/input/uinput).
• uinput then creates a new node to expose the virtual device as a evdev interface device in /dev/input/event*

From here the idea is that KWin or any other system component can treat the virtual controller as if it were an ordinary HID device.

uinput is a kernel module that makes it possible to emulate input devices from userspace. By writing to /dev/uinput (or /dev/input/uinput) device, a process can create a virtual input device with specific capabilities. Once this virtual device is created, the process can send events through it, that will be delivered to userspace and in-kernel consumers.

-The kernel development community.

Useful functions:

• libevdev_uinput_create_from_device(const struct libevdev *dev, int uinput_fd, struct libevdev_uinput **uinput_dev):
  For creating a uinput device based on the given libevdev device.
• libevdev_uinput_get_devnode (struct libevdev_uinput *uinput_dev):
  Return the device node representing this uinput device.
• libevdev_uinput_write_event (const struct libevdev_uinput *uinput_dev, unsigned int type, unsigned int code, int value): Post an event through the uinput device.

Tools used:

• libevdev-uinput.h for management of uinput devices via libevdev.
• /dev/uinput opened with correct permissions.
  • Ensuring the current user is in the input group.
  • Verifying that the uinput kernel module is loaded (using modprobe uinput). Some distros (Ubuntu/Kubuntu) have it built in, not loaded as module, thus modprobe uinput command won't log anything.
  • Opening /dev/uinput with O_WRONLY | O_NONBLOCK flags using open(), and ensuring no EPERM or EACCES errors were returned.
  • Optional: Run program as sudo user.

force feedback detection/support

Using ioctl(fd, EVIOCGBIT(EV_FF, ...)) and tools like fftest, I examined:

• How to query a device’s force feedback (FF) capabilities to figure out which effects are supported (e.g., rumble, sine wave).
• How to upload ff effects to physical game controller and test rumble motors.
  • This was key to understanding haptic capability support on physical devices.

To enable force feedback, you have to:

have your kernel configured with evdev and a driver that supports your device.

make sure evdev module is loaded and /dev/input/event* device files are created.

Testing & Validation

• Used evtest and fftestto test evdev devices and understand their capabilities - sudo evtest /dev/input/eventX.
• Used those same tools to test virtual devices creating using uinput -
  sudo fftest dev/input/eventX. uinput creates a node device in dev/input/eventX for the virtual input.
• Prototype logs validate that a virtual device can be created and events can properly be written to a that virtual device using libevdev.

Takeaways

• Using libevdev and libevdev-uinput we can access physical controllers, create virtual controller and read/write low-level input events.
• Understanding of the permission requirements to open /dev/input/* and /dev/uinput (use udev rules or run as root).
• Tools to test:
  • evtest and fftest (from input-utils)
  • udevadm info --name=/dev/input/eventX --attribute-walk
    • Shows the device hierarchy - how the device is connected to PC and any parent device it connects to.
• Built a minimal proof-of-concept C++ program that routes an evdev devices input 1:1 to a virtual controller (via uinput).
• Not all controllers support all force feedback types; some failed with EINVAL during upload.
• libevdev does not handle FF upload directly — this remains kernel-level and typically involves ioctl().

References and Documentation

• Linux Input Subsystem Documentation (kernel-level overview of evdev, HID, uinput, etc.)
• evdev interface documentation (from the kernel source)
• uinput: User-level input device emulation
• Force Feedback programming on Linux (FF effect types and ioctl usage)
• libevdev (Userspace abstraction for evdev devices)

Tuesday, 24 June 2025. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.4.1.

Plasma 6.4 was released in June 2025 with many feature refinements and new modules to complete the desktop experience.

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

This is a recipe post. For an event I needed to make brownies for 100 people, so this time I decided to write down what I was doing, so that they would be sort-of-consistent. I even weighed things.

Melt (e.g. in the microwave):

• 200g pure chocolate (Jumbo store brand is acceptable in the Netherlands)
• 130g margarine (Blue Band)

Stir in:

• 150g sugar (e.g. brown basterd sugar for extra flavor)
• pinch of salt (this is one I often forget)

Mix in:

• 4 eggs (one by one, and use an electric mixer; run it long, so that the batter becomes glossy)
• 70g cocoa powder
• 60g flour

In the oven at 180℃ for 35 minutes or so. Optionally, add pecans.

This recipe is based on my interpretation of “Jamie Oliver Brownies”, which are all over the net – the original version is kind of picky, and what I do here works repeatedly in my kitchen.

You might have noticed that Plasma keyboard shortcuts have been changing recently with the aim to have everything KWin/Plasma be Meta+Something.

Now, I tend to redefine most of the default shortcuts, so this didn’t affect my workspace directly, but I liked the idea to have different modifiers used depending on the category of /thing/ for which I’m creating a shortcut.

An additional aim I had is to have a common shortcut ‘body’ for equivalent actions in different categories, in order to more easily build muscle memory with my new shortcuts.

Categories that I have are:

1. system (Plasma and such)
2. terminal application (Konsole, Kitty)
3. terminal multiplexer (TMux)
4. specific application (Firefox, Vim, …)

And these are the modifiers I’m trying out:

1. system: Meta+Anything and Alt+Special keys
2. terminal application: Ctrl+Shift+Anything
3. terminal multiplexer: nothing special yet, just the Ctrl+d as the leader
4. specific application:
   • working with tabs: Ctrl+Anything
   • other shortcuts: Alt+Normal keys

So, for example, the ; and ' as the shared shortcut /bodies/ mean the following in different categories:

1. Meta+; and Meta+' – switch to next and previous window (I’m using Krohnkite for tiling, so this is not like Alt+Tab, but moving through the visible tiled windows);
2. Ctrl+Shift+; and Ctrl+Shift+' – would mean switch to next and previous panes in the terminal application (I’m not using this yet, as I don’t tend to use split views in terminal except in TMux);
3. Ctrl+d ; and Ctrl+d ' – move to next and previous panes in TMux;
4. Alt+; and Alt+' – move to next and previous panes in an application (currently only in Vim and Neovim).

So far, the approach seems to work Ok. I’ve quickly got accustomed to the new window/pane navigation shortcuts.

The main problem are the programs that don’t allow changing shortcuts (Firefox for example) or don’t allow creating shortcuts with some key combinations (using Ctrl+; in Vim or Neovim does not work, while it works with Alt).

Because of those limitations, the modifiers are not as clear cut as they ideally would be. Ideally, each category would have its own single modifier, instead of, for example, having a mix of Alt and Ctrl in the /specific application/ category, and using a modifier combination like Ctrl+Shift for the /terminal application/.

I’ve also redefined all my Plasma and KWin shortcuts to be location-on-keyboard-based, but more on that later.

PySide6 is easy to use and powerful but there’s a few pitfalls to look out for. We’ll investigate a performance issue in a large data model, find out that function calls are expensive, and that some of Qt’s C++ APIs had to be adapted to work in a Python environment.

Continue reading Pitfalls in PySide6 at basysKom GmbH.

A very long awaited milestone has been reached: Today the KMyMoney team announces the availability of the latest stable version of its Personal Finance Manager together with its companion library Alkimia..

Since the last stable release almost 3 years ago, the developers made 3440 changes to the main code base and 800+ changes to the Alkimia library.

Here’s an overview of some major functionality changes and improvements made among all the little bug fixes along the way (with more details on a separate page):

Multi account ledger view

KMyMoney now allows to open the ledger of multiple accounts in tabs side by side in the ledger view.

New and improved transaction editors

The transaction editors have completely rewritten. They now open a widget directly in the ledger area and there is no distinction between form based and register based method anymore. The sometimes confusing tabs showing Deposit/Transfer/Withdrawal have been removed and the amount entry now provides two mutually exclusive widgets for debit and credit. These changes also found their way into the split editor.

And for transfers you now simply type/select the account name in the category widget.

Customize tab order for transaction editors

Another feature of the transaction entry is to customize the tab order for data entry. Pressing Ctrl+Alt+T opens the tab order editor and the user can select the order of the widgets that are visited when pressing the TAB key.

Open categories in ledger view

With the new version, it is now possible to open categories in the ledger and enter transactions. This has been a long standing user request.

Customize order of columns in tabular views via drag and drop

The order of the columns of e.g. the ledger, accounts or categories view can now be modified by the user by simply dragging the header column to its new location.

Move accounts in hierarchy via drag and drop

Moving accounts in the hierarchy is now possible using drag and drop.

Load passwords from gpg encrypted password store

Passwords for e.g. the KBanking backend can now be loaded from the standard Unix password store pass with a simple mouse click. Pass uses strong GPG based encryption to store its information. A Qt based GUI frontend for pass is also available.

Improved handling of tags

The support for tags has been overhauled. Especially the reporting section for tags received many improvements.

Link documents to transactions

KMyMoney now provides a feature to link documents stored in the filesystem to transactions. This can be automated to support recurring transactions (e.g. your phone bill) by simple configuration using regular expressions per payee.

Online exchange rate download available for other finance apps

Online currency exchange rate and stock price download has been moved over to the Alkimia library and then re-integrated into KMyMoney. This makes it available for other applications by simply linking to Alkimia.

Updated handbook

The KMyMoney handbook has received many changes to reflect the new functionality.

A big thank you goes out to those who supported us by reporting problems and helping to identify their root cause. In case you have a question about the usage of some new features or even old ones, please post your question on the KDE user forum. If you are sure you found real problem or want to ask for a new feature, please do so on our bugtracker.

Tackling the Migration Agent

For week three, I finished resolving the configuration window issue for the EteSync resource by hiding the default configuration window and programmatically linking the wizard’s “Accepted” and “Rejected” states to the configuration window’s accept() and reject() methods. This ensured that the wizard cleanly replaced the built-in dialog without leaving a “zombie” window behind. I’ve submitted a merge request for these changes so it can be reviewed and integrated upstream.

With that resolved, I moved on to a new and intriguing component: the PIM Migration Agent. This agent is responsible for managing data migrations between different Akonadi versions or formats — a critical part of ensuring smooth transitions when updating KDE PIM components.

And like the other agents and resources, it was time for it to shed its QtWidgets dependency.

Decoupling the UI

Following the established pattern, I began by:

• Creating a dedicated UI plugin for the migration agent’s configuration dialog

• Removing the old configure() method from the agent’s core logic

• Updating the relevant CMakeLists.txt files to support the plugin and cleanly separate UI code from the core agent

However, while this transition was relatively smooth, the plugin-agent communication needed more work to function correctly in this new structure.

Creating a D-Bus Interface for Plugin-Agent Communication

To enable proper communication between the configuration plugin and the migration agent, I created a new D-Bus interface:
org.kde.Akonadi.MigrationAgent

This interface allows the plugin to:

• Receive status or configuration information from the agent

• Send information back if needed (e.g., configuration changes)

To support this, I also:

• Modified the CMakeLists.txt to include the interface and generate the corresponding D-Bus adaptor

• Updated both the migrationagent and migrationstatuswidget files to use the new D-Bus interface for interaction

This ensures the plugin can communicate cleanly with the agent without relying on any hard-coded QtWidgets calls or tightly coupled logic.

The KUiServerJobTracker Problem (Still Pending)

While working on the migration agent, I encountered a significant QtWidget dependency:
KUiServerJobTracker, which handles job progress display by showing dialogs and notifications automatically.

Removing it is straightforward — but it leaves a gap:

How should the migration agent report progress to the user once KUiServerJobTracker is gone?

I’m currently exploring options for replacing it, possibly using a D-Bus-based mechanism where the agent broadcasts progress updates and a separate component (e.g., the plugin or a tray app) displays them. This would decouple the presentation layer from the agent’s logic, but I haven’t yet finalized the design.

What’s Next?

My immediate priority is to test the new plugin and the communication logic to ensure everything works correctly. In parallel, I’ll continue thinking through a robust replacement for KUiServerJobTracker, aiming for a modular, widget-free solution.

This week introduced new architectural challenges, but also laid the groundwork for cleaner, more maintainable agents. I’m excited to keep building on this momentum next week!

X11 is in the news again, so I thought it would make sense to be clear about the Plasma team’s plans for X11 support going forward.

Current status: Plasma’s X11 session continues to be maintained.

Specifically, that means:

• We’ll make sure Plasma continues to compile and deploy on X11.
• Bug reports about the Plasma X11 session being horribly broken (for example, you can’t log in) will be fixed.
• Very bad X11-specific regressions will probably be fixed eventually.
• Less-bad X11-specific bugs will probably not be fixed unless someone pays for it.
• X11-specific features will definitely not be implemented unless someone pays for it.

This is actually not too bad; there are relatively few open and fixable X11-specific bugs (0.76% of all open bug reports as of the time of writing), and when I went looking today, there were only two Bugzilla tickets requesting new X11-specific features that needed closing. Most bugs and features are platform-agnostic, so X11 users will benefit from all of these that get fixed and implemented.

Eventually it’s lights out for X11 though, right? When will that happen?

Yes, the writing is on the wall. X11’s upstream development has dropped off significantly in recent years, and X11 isn’t able to perform up to the standards of what people expect today with respect to HDR, 10 bits-per-color monitors, other fancy monitor features, multi-monitor setups (especially with mixed DPIs or refresh rates), multi-GPU setups, screen tearing, security, crash robustness, input handling, and more.

As for when Plasma will drop support for X11? There’s currently no firm timeline for this, and I certainly don’t expect it to happen in the next year, or even the next two years. But that’s just a guess; it depends on how quickly we implement everything on https://community.kde.org/Plasma/Wayland_Known_Significant_Issues. Our plan is to handle everything on that page such that even the most hardcore X11 user doesn’t notice anything missing when they move to Wayland.

Why are you guys doing this? Why don’t you like X11 anymore?

The Plasma team isn’t emotional about display servers; it’s just obvious that X11 is in the process of outliving its usefulness. Someday Wayland will be in this boat too; such is the eventual fate of all technologies.

In addition to the fact that Wayland is better for modern hardware, maintaining code to interact with two display servers and session types is exactly as unpleasant as it sounds. Our resources are always limited, so we’re looking forward to the day when we can once again focus on programming for a single display server paradigm. It will mean that everything else can improve just a little bit faster.

Regardless of when you pull the trigger, isn’t it premature?

Most major distros have already moved their Plasma sessions to Wayland by default, including Arch, Fedora, KDE neon, Kubuntu, and generally their downstream forks. Several others whose roadmaps I’m familiar with plan to do so in the near future.

At this point in time, our telemetry says that a majority of Plasma users are already using the Wayland session. Currently 73% of Plasma 6 users who have turned on telemetry are using the Wayland session, and a little over 60% of all telemetry-activating users (including Plasma 5 users) are on Wayland.

Interestingly, the percentage of Plasma 6 users on Wayland was 82% a month ago, and now it’s down to 73%. What changed? SteamOS 3.7 was released with Plasma 6 and the X11 session still used by default! Interestingly, since then the Wayland trendline has continued to tick up; a month ago the percentage of Wayland users dropped from 82% to 70%, and now today it’s up to 73%.

So you can see that to a large extent, this is up to distros, not us. It wouldn’t make sense for us to get rid of Plasma’s X11 support while there are still major distros shipping it by default, and likewise, it won’t make sense for us to keep it around long after those distros have moved away from it.

Regardless, Wayland’s numbers are increasing steadily, and I expect upward bumps when the next Debian and Kubuntu LTS releases come out, as both are currently planned to be Wayland by default.

Now, is Plasma’s Wayland session perfect? No. (what is?)

Is it better than the X11 session in literally every way? Also no.

Is it better in most ways that matter to most people? The numbers say yes!

Well I’m not a most people! I’m me, I’m an individual! I’m not a number, I’m a free man!

That’s fine, and you’re the reason why we’re still maintaining the X11 session! We’re going to try very hard not to to get rid of it until you’re happy too.

Ultimately that’s the goal here: make everyone happy! This includes people who have mixed-DPI/refresh rate multi-monitor setups or laptop touchpads, as well as people using AutoKey or graphics tablets with dials on them. Long transitions like this are tough, but ultimately worth it so that we all get something better in the end.