KDE Eco is an ongoing initiative taken by the KDE community to support the development and adoption of sustainable Free & Open Source Software worldwide and I am happy to be able to contribute to this mission as part of Season of KDE 2026.

As part of this initiative, KDE aims to measure the energy consumption of its software and eco-certify applications with the Blue Angel ecolabel. To make this possible, KEcoLab a dedicated lab based in Berlin provides remote access to energy-measurement hardware via a GitLab CI/CD pipeline to measure the energy usage of software following the guide documented in KDE Eco Handbook

To measure energy usage of a software we need to prepare three scripts baseline.sh , idle.sh and sus.sh and push them via MR to this repository, SUS or Standard User Scenario script emulates a standard user in a automated manner without human intervention, more on how to prepare SUS can be found here.

Currently, these scripts rely on xdotool to simulate user interactions. However, xdotool does not work on Wayland. Since the KEcoLab computer have recently migrated to Fedora 43, which uses Wayland by default, the existing scripts no longer work. To solve this problem,

I am working with my mentors Joseph, Aakarsh, and Karanjot to port the existing test scripts from xdotool to ydotool and kdotool, which are compatible with Wayland. As part of this effort, I’ve written a guide explaining how to use ydotool and kdotool more easily.

Setup ydotool and kdotool #

To test the scripts you have written it’s recommended to setup locally.

Note: Some features changes and some are removed with updates so it’s recommended to build them from source mentioned here

ydotool #

1. Clone the repository and navigate into it

 git clone -b feat/setup-script https://invent.kde.org/neogg/ydotool.git
 cd ydotool 

2. Run the setup script

chmod +x setup.sh
./setup.sh install

3. Give ydotoold permission to uinput so it can run without root

sudo touch /etc/udev/rules.d/99-uinput.rules
echo 'KERNEL=="uinput", MODE="0660", GROUP="input"' | sudo tee /etc/udev/rules.d/99-uinput.rules > /dev/null
sudo usermod -aG input "$USER"

sudo udevadm control --reload-rules
sudo udevadm trigger

Note: A reboot (or full logout/login) is required for the input group change to take effect.

4. Reboot your computer and run

systemctl --user start ydotoold

Verify that you can use ydotool by ydotool type "Hello" you will see Hello typed if installation was successful.

kdotool #

1. Clone the repository and navigate into it

 git clone -b feat/setup-script https://invent.kde.org/neogg/kdotool.git
 cd kdotool 

2. Run the setup script

chmod +x setup.sh
./setup.sh install

Verify that you can use kdotool by kdotool -h

How to use ydotool and kdotool to perform various actions #

Press keys #

For pressing keys we use ydotool , the syntax for pressing keys is a little confusing when you look at it :

ydotool key KEY_CODE:ACTION

KEY_CODE

Linux uses a file named input-event-codes.h that defines numeric codes for everything an input device can generate in Linux. Simply speaking for every type of keypress there is a numerical representation. For example, the LEFTCTRL key is represented by 29, and the letter T is represented by 20. How to find the code for the key you want to press , You can read the original .h file by nano /usr/include/linux/input-event-codes.h if you are in a linux system ( i hope you are using one). or inspect the file here

I use grep to find the code for the key i want since the header file is too long grep KEY_LEFTCTRL /usr/include/linux/input-event-codes.h and so on.

ACTION

• 1 : key is pressed
• 0 : key is released

So to press and release Ctrl you can use the following command

ydotool key 29:1 29:0

Press key combinations #

Key combinations is the same as above , you just need to keep all the keys pressed. So to press Ctrl+Alt+T which opens up a terminal you can use the following command

ydotool key 29:1 56:1 20:1 29:0 56:0 20:0

This translates to Ctrl(pressed) Alt(pressed) T(pressed) Ctrl(released) Alt(released) T(released)

This will hopefully open up a terminal.

Click ( left, right, double) #

For performing mouse clicks we can use the click command in ydotool , If you are do not like codes unlike me,I am sorry but again we have codes…

ydotool click OPTIONS BUTTON_CODE

OPTIONS

--repeat=N : can be used to press a button N times
--P : can be used to press and release a button as that's what we mostly do

BUTTON_CODE

This is a hexadecimal value that represents different mouse buttons (left, right, middle, etc.).
Yes, it looks ugly at first, but you can always open up my blog.

ydotool click 0xC0 # left click
ydotool click 0xC1 # right click
ydotool click 0xC2 # middle button click (scroll button)

ydotool click 0x40 # left button down (press)
ydotool click 0x80 # left button up (release)

ydotool click 0x41 # right button down (press)
ydotool click 0x81 # right button up (release)

And some combinations This can be useful to select text, drag and drop etc..

ydotool click 0x40 # left down 
ydotool mousemove 300 0 # drag right 
ydotool mousemove 0 200 # drag down 
ydotool click 0x80 # left up

same as above but more reliable with delays to simulate a real user

ydotool click 0x40
ydotool mousemove -D 20 300 0
ydotool mousemove -D 20 0 200
ydotool click 0x80

Type text #

Typing text is pretty simple using ydotool

ydotool type "string-you-want-to-type"

Focus a specific app #

kdotool search --name "Window Title" windowactivate
kdotool search --class appname windowactivate
kdotool search --classname org.kde.app windowactivate ( for kde apps )

Send mouse and keyboard commands to a specific window #

Focus the window using kdotool than execute commands using ydotool since commands are always executed in the active window.

Get current mouse location #

We can use kdotool for getting the current mouse location which also returns the windowID along with x and y coordinate of current mouse location

kdotool getmouselocation

The output :

x:42 y:96 screen:0 window:{e8aeec46-5c45-42cc-9839-8ad2edcb7f4f}

If you only want to extract the x and y value since thats what’s more important you can do that using regex

# Read mouse location
loc="$(kdotool getmouselocation)"

# Extract x and y
x=$(echo "$loc" | sed -n 's/.*x:\([0-9-]*\).*/\1/p')
y=$(echo "$loc" | sed -n 's/.*y:\([0-9-]*\).*/\1/p')

Move mouse to a specific coordinate #

Note : We can use ydotool to move the mouse but that may not give us any visual feedback if you are using it in a VM, that is you cannot see the actual mouse cursor move when the commands are executed but you can use the kdotool getmouselocation to see how the mouse location gets updated.

There is a command in ydotool

ydotool mousemove --absolute -x x-value -y y-value

but that does not work in Wayland properly.

We have an another command that moves the mouse relative to current mouse location so we can use that.

ydotool mousemove -x x-value -y y-value

1. mousemove -9999 -9999 ( moves the mouse to top left 0,0)
2. mousemove x y ( now we move relative to 0,0 so that’s like absolute mousemove)

Move mouse inside a specific window #

Since we cannot directly send mouse events to a window on Wayland, we rely on window geometry that we can get using kdotool and do relative mouse movement using ydotool.

The steps are:

1. Focus the window
2. Get the window geometry
3. Reset the mouse to (0,0)
4. Move the mouse relatively using the window coordinates

# First, focus the window:
kdotool search --class firefox windowactivate

# Get the window geometry:
kdotool search --class firefox getwindowgeometry
# Example output:
# Window {a24d3d34-85f6-4915-821b-54a71a959f6a}
# Position: 340.23748404968967,68.49159882293117
# Geometry: 768x864


#Reset the mouse position to the top-left corner of the screen:
ydotool mousemove -x -9999 -y -9999

# Move the mouse to the Position you got from above command (top left corner of the window )

# Now move the mouse inside the window (top-left corner of the window):
ydotool mousemove -x 120 -y 80

#At this point, the mouse cursor is inside the target window. so you can now move inside the window , but only once than again repeat the above steps once again ( i will think of a script to automate this)

Move mouse to the center of a window #

Moving to the center of a window uses the same idea, but instead of moving to x and y, we add half the width and height.

From the geometry we extract : x=120 y=80 width=1280 height=800

Calculate the center:

center_x = x + width / 2

center_y = y + height / 2

Reset the mouse again:

ydotool mousemove -x -9999 -y -9999

Move the mouse to the center of the window:

ydotool mousemove -x center_x -y center_y

These completes all the basic actions that are required to automate user actions , We may need to combine many of above to do tasks that simulate real user.

In the last month, I have mostly been working on refactoring the Kdenlive keyframes system to make it more powerful. This is part of a NGI Zero Commons grant via NLnet.

Improving existing parameters handling

A first step in preparation for this work was to improve the usability of some effects. In Kdenlive, we support several effect libraries, like MLT, Frei0r and FFmpeg's avfilters. Not all effects expose their parameters in the same way. For example in MLT, we have a rectangle parameter allowing to define a zone in a video frame. Other effects expose several independent parameters for a rectangle, namely x, y, width and height.

Currently, these effects are displayed with a list of sliders for each value:

With my latest changes, these will be handled like a rectangle, which means it can directly be manipulated in the monitor overlay.

Another improvement is the addition of Point parameters which will allow selecting a point in the monitor.

These changes are planned to be in the 26.04 release.

Boosting keyframes

The next improvement being worked on is support of keyframes per parameter. Currently, once you add a keyframe to an effect, it is applied to all parameters, which is sometimes not wanted. This will also allow animating only one parameter while leaving the others parameters fixed. Below is a screenshot of a basic UI created to test the feature.

Kdenlive needs your support

Our small team has been working for years to build an intuitive open source video editor that does not track you, does not use your data, and respects your privacy. However, to ensure a proper development requires resources, so please consider a donation if you enjoy using Kdenlive - even small amounts can make a big difference.

After taking a 13 year hiatus from KDE development, Harald Sitter's talk on KDE Linux at Akademy 2024 was the perfect storm of nostalgia and inspiration to suck me back in. I've been contributing on and off since then.

This blog post outlines some gaping holes I see in its extensibility model, and how I plan to address them (assuming no objections from other developers).

The Problem

KDE Linux is being built as an immutable OS without a traditional package manager. The strategy leans heavily on Flatpak for GUI applications, which (though, not without its problems) generally works well for its stated goal. But here's the thing: the Linux community has a relatively large population of CLI fanatics—developers who live in the terminal, who need $OBSCURE_TOOL for their workflow, who won't be satisfied with just what comes in a Flatpak.

The OS ships with a curated set of developer tools that we KDE developers decided to include. Want something else? There's a wiki page with suggestions for installation mechanisms we don't officially support—mechanisms that, let's be real, most of us don't even use ourselves.

This sets us up for the same reputation trap that caught KDE Neon:

Just like KDE Neon got pigeonholed with the reputation of being "for testing KDE software," KDE Linux risks getting branded as "for developing KDE software only."

There's also a deeper inconsistency here. One of the stated goals is making the end user's system exactly the same as our development systems. But if the tools we actually use day-to-day are already baked into the base image—and thus not part of the extensibility model we're asking users to adopt—then we're not eating our own dog food. We're shipping an experience we don't fully use ourselves.

The Solution

Look at the wild success of Docker and Kubernetes. Their container-based approach proved that immutable infrastructure actually works at scale. That success paved the way for Flatpak and Snap to become the de facto solution for GUI apps, and now we're seeing immutable base systems everywhere. The lesson is clear: containers aren't just one solution among many—they're the foundation that makes immutable systems viable.

Containers for CLI Tools???

As crazy as it sounds, that's the logical next step. Let's look at the candidates to base our solution on top of:

distrobox/toolbox are trying to solve the right problem—building long-term, persistent development environments—but they're doing it on top of docker/podman, which were designed for ephemeral containers. They're essentially fighting against the grain of their underlying systems. Every time you want to do something that assumes persistence and state, you're working around design decisions made for a different use case. It works, but you can feel the friction.

systemd-nspawn is built for persistence from the ground up, which is exactly what we want. It has a proper init system, it's designed to be long-lived. The challenge here is that we need fine-grained control over the permissions model—specifically, we need to enable things like nested containers (running docker/podman inside the container) and exposing arbitrary hardware devices without a lot of manual configuration. systemd-nspawn makes these scenarios difficult by design, which is great for security but limiting for a flexible development environment.

devcontainers nail the developer experience—they're polished, well-integrated, and they just work. The limitation is that they're designed to be used from an IDE like VS Code, not as a system-wide solution. We need something that integrates with the OS itself, not just with your editor. That said, there's definitely lessons to learn from how well they've executed on the developer workflow.

Our knight in shining armor:

Enter Incus. It checks all the boxes:

• Proper API for building tooling on top of it
• Nested containers work out of the box—want to run docker inside your Incus container? Go for it
• Privileged container mode for when you need full system access and hardware devices
• Built on LXC, which means it's designed for long-lived, system-level containers from day one, not retrofitted from ephemeral infrastructure

Bonus: it supports VMs too, for running less trusted workloads. People on Matrix said they want this option. I don't fully get the use case for a development environment, but the flexibility is there if we need it.

Architecture

Incus exposes a REST API with full OpenAPI specs—great for interoperability, but dealing with REST/OpenAPI in C++ is not something I'm eager to take on.

My first choice would be C#—it's a language I actually enjoy, and it handles this kind of API work beautifully. But I suspect the likelihood of KDE developers accepting C# code into the project is... low.

Languages that already build in kde-builder and CMake will probably have the least friction for acceptance, and of those, Python is the best fit for this job. The type system isn't as mature as I'd like (though at least it exists now with type hints), and the libraries for OpenAPI and D-Bus are... okay-ish. Not amazing, but workable.

Here's the plan:

• Daemon in Python to handle all the Incus API interaction
• CLI, KCM, and Konsole plugin in C++ for the user-facing pieces that integrate with the rest of KDE

This way we keep the REST/OpenAPI complexity in Python where it's manageable, and the KDE integration in C++ where it belongs.

Current Status

Look, the KDE "K" naming thing is awesome. I'm not going to pretend otherwise. My first instinct was "Kontainer"—obvious, descriptive, checks the K box. Unfortunately, it was already taken.

So I went with Kapsule. It's a container. It encapsulates things. The K is there. Works for me.

The implementation is currently in a repo under my user namespace at fernando/kapsule. But I have a ticket open with the sysadmin team to move this into kde-linux/kapsule. Once that's done I'll be able to add it to kde-builder and start integrating it into the KDE Linux packages pipeline.

The daemon and CLI are functional. Since a picture is worth a thousand words, here's a screenshot of the CLI in action:

Here's docker and podman running inside ubuntu and fedora containers, respectively:

And here's chromium running inside the container, screencasting the host's desktop:

Next Steps

Deeper integration

Right now, Kapsule is a CLI that you have to manually invoke, and it lives kind of separately from the rest of the system. That's fine for a proof of concept, but the real value comes from making it invisible to users who just want things to work.

Konsole

Konsole gained container integration in !1171, so I just need to create and add an IContainerDetector for Kapsule. Once that's wired up, I'll add a per-distro configurable option to open terminals in the designated container by default.

When Kapsule is stable enough, that becomes the default behavior. Users won't have to know or care about Kapsule—they just open a terminal and their tools are there. Unless they break their container, which leads nicely to the next point...

KCM

A System Settings module for container management:

• Create, delete, start, stop containers
• Easy reset if you ran something that broke things
• For advanced users: configuration options like which distro to use, resource limits, etc.

Discover

These containers need to be kept up to date. Most will have PackageKit inside them, so we can create a Discover plugin that connects to the container's D-Bus session and shows updates for the container's packages alongside the host's updates. Seamless.

Moving dev tools out of the base image

This is the long-term goal: get Kapsule stable and good enough that we can remove ZSH, git, clang, gcc, docker, podman, distrobox, toolbox, and the rest of the dev tools from the base image entirely. All of those already work in Kapsule.

Once that happens, we're eating our own dog food. The extensibility model we're asking users to adopt is the same one we're using ourselves.

Pimped out container images

We'll maintain our own image repository. There's no real limit to the number of images we can offer, and everyone in the #kde-linux channel can show off their style. Want a minimal Arch-based dev container? A fully-loaded Fedora workstation? A niche distro for embedded development? A Nix-based image (I'm looking at you, Hadi Chokr)? All possible.

Trying it out

Honestly, the best way to try it out is to wait for me to get it integrated into the KDE Linux packages pipeline and into the base image itself. Hopefully that'll be in the next few days.

We have started the release process for the next feature release of Krita today! This release is the culmination of years of hard work. From the same codebase, we're building both Krita 5.3, based on Qt5, and Krita 6.0.0. based on Qt6. Krita 6 is not yet available for Android or ChromeOS because Qt6 is unstable on those platforms.

Highlights

To learn about everything that has changed, check the release notes!

Text Object

The text object has been completely rewritten, as have all the tools to handle text. You can now edit text on the canvas, make text wrap inside vector shapes and put text on a vector path. We support most if not all scripts fully as well.

A variety of technical blog posts were written on the topic: Fonts, Open Type, Font Metrics, various other properties, Text in Shape and Type Setting Mode.

Wayland Color Management Support

A Krita 6-only feature, on Linux, we now support Wayland color management support when Krita runs in native Wayland mode. Note that the only officially supported wayland compositor is KWin. If you use another compositor and find an issue, test with kwin first whether that issue reproducible.

Tools

There is a completely new tool: a knife tool for vector objects, for merging and splitting vector objects. This is extremely handle when creating comic page layouts. Other tools have been extended or have improved performance. For instance, the freehand drawing tool has a pixel-art stabilizer and the liquify transform tool is much faster.

Assistants

Configuring assistants has become easier and there's a new curve-linear perspective assistant.

Filters

There are new filters: propagate colors and color overlay mask. All blending modes have been checked for correctness when working in HDR.

Dockers

The recorder docker now can capture in real time. Dockers can be added to the popup palette.

Brush Engines

Among other improvements, the pattern option has been extended with a soft texturing mode.

File Formats

There is support for a new file format, Radiance RGBE. Additionally, JPEG-XL support has been improved a lot, just in time for Googles volte-face on JPEG-XL support. And... Text objects in PhotoShop files now be loaded as text! You can save text to PSD as well, but only in a limited way.

Python Plugin API

The Python plugin API has been extended with an API for generating brush strokes, new user interface objects and new methods for existing classes. There are also new python plugins.

Krita 5.3 Downloads

Windows

If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

• 64 bits Windows Installer: krita-5.3.0-beta1-setup.exe
• Portable 64 bits Windows: krita-5.3.0-beta1.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

Note: starting with 5.2.11, the minimum supported version of Ubuntu is 22.04.

• 64 bits Linux: krita-5.3.0-beta1-x86_64.AppImage

MacOS

• MacOS disk image: krita-5.3.0-beta1.dmg

Android

We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.

• 64 bits Intel CPU APK
• 64 bits Arm CPU APK
• 32 bits Arm CPU APK

Source code

You can build Krita 5.3 using the Krita 6.0.0.source archives. The difference is which version of Krita you build against.

md5sum

For all downloads, visit https://download.kde.org/unstable/krita/5.3.0-beta1/ and click on "Details" to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

Krita 6.0. Download

NOTE: The main feature of the 6.0 release is that it uses Qt6. This means it is buggier than 5.3, having both the 5.3 bugs and Qt6 related bugs. If you have no need for the Krita 6.0 features, we recommend you use 5.3 for testing.

Windows

If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

• 64 bits Windows Installer: krita-6.0.0-setup.exe
• Portable 64 bits Windows: krita-6.0.0.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

• 64 bits Linux: krita-6.0.0-x86_64.AppImage

MacOS

• MacOS disk image: krita-6.0.0-signed.dmg

Source code

• krita-6.0.0.tar.gz
• krita-6.0.0.tar.xz

md5sum

For all downloads, visit https://download.kde.org/unstable/krita/6.0.0-beta1/. and click on "Details" to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

This year was my first year attending FOSDEM. I was encouraged to submit a talk and it got accepted. My talk was on Design Systems applied to Open Source projects.

In our case, I related the story and learnings from using a design system for the Plasma desktop. I outlined things that are pending or missing in this process.

I did my best to convince the audience to switch to Plasma and it seems a few of them changed their mind by the end of the talk.

This talk is a variation on my previous talk at Akademy 2025. Without further delay, here is the video recording of my talk. Note that the audio is not the best.

A recent toot of mine got the response “friends don’t let friends use GPG” which, I suppose, is true enough. It certainly isn’t the attestation-friendly thing to use, and the opsec failures that are so easy with GPG-encrypted mail make it a hazard there. But for some things it’s all we’ve got, and I do like to sign Calamares releases and incidental FreeBSD things. And I am nominally the maintainer of the security/gnupg port on FreeBSD. So gpg.fail notwithstanding, here’s notes on my 2026 GPG key update.

Previously in 2024 and 2025 I wrote down basically the same things:

• Things expire in about 13 months and I’ll have to remember then again,
• You can find my pubkey published on my personal and business sites,
• FreeBSD signature information is used rarely, but is available in the FreeBSD developers OpenPGP keys list,
• Codeberg will have signed commits in the Calamares repository with these keys.

sec   rsa4096/0x7FEA3DA6169C77D6 2016-06-11 [SC] [expires: 2027-02-03]
      Key fingerprint = 00AC D15E 25A7 9FEE 028B  0EE5 7FEA 3DA6 169C 77D6
uid                   [ultimate] Adriaan de Groot <groot@kde.org>
uid                   [ultimate] Adriaan de Groot <adriaan@bionicmutton.org>
uid                   [ultimate] Adriaan de Groot <adridg@freebsd.org>
uid                   [ultimate] Adriaan de Groot <adriaan@commonscaretakers.com>
ssb   ed25519/0x55734316C0AE465B 2025-03-04 [S] [expires: 2026-08-26]
ssb   cv25519/0x064A54E8D698F287 2025-03-04 [E] [expires: 2026-08-26]
ssb   ed25519/0x14B6CC381BC256D6 2026-02-03 [S] [expires: 2027-02-28]
ssb   cv25519/0xD716006BBA771051 2026-02-03 [E] [expires: 2027-02-28]