Plasma on KDE Blogs

Streamline Plasma with Activities to be more focused and productive

Tracey Clark — Sat, 17 Jan 2026 00:00:00 +0000

Have you seen Activities in your system settings and wondered what they're used for? Have you read about them them in a blog post and wanted to know more? Have you been interested in giving them a try, but weren't sure where to start? This is where I was once upon a time, so I'd like to share how I've set up Activities to streamline my workflows. Maybe this can help others who also want to experiment. The experience hasn't always been smooth. Due to various bugs, there was one point where I threw up my hands and migrated everything back to virtual desktops in anger. Eventually, the bugs were fixed, and other improvements were made. I gave them another try and I'm glad I did. Many thanks to the contributors who fixed those bugs and who maintain this awesome feature! Today, Activities are now an integral part of my Plasma setup.

Activities? But I already have Virtual Desktops!

When I first discovered this "Activities" thing, I had no idea what it was, really. I was already using Virtual Desktops, what did Activities do that they couldn't? It wasn't until I found a few blog posts explaining the fundamentals that I got it. Activities are meant for different workflows a.k.a. contexts (not just tasks within one). At the most basic level:

Virtual Desktops, a.k.a. Workspaces, separate different tasks within a context / workflow / project. For instance, when doing KDE work, I might have the bug tracker and docs opened in a browser on Workspace1, and then on Workspace2 have a terminal and code editor. These are things related to the context of "KDE work".

Activities are meant for a higher level of separation based on a particular workflow or project. Some examples would be Work, Finances, Gaming, Development or Streaming. They can be added, changed and deleted in Settings -> Activities or in the Activities Manager (Meta+Q by default).

Benefits for organization and speeding up getting into a workflow

Each Activity can have a set of applications, widgets and linked files. You can tailor these to a workflow / context / project. You can quickly switch between them with keyboard shortcuts or the Activities Manager.

For me, they make it much easier to launch the tools I need, and maintain focus on the task at hand. My brain is context-driven, so this helps me keep track of where things are and avoid getting lost in a sea of stuff. My brain is also sometimes easily distracted. Having only the shortcuts and applications I need front of me helps me maintain focus.

So what can I actually do with Activities that I can't already do with Virtual Desktops?

Most folks already know that with Virtual Desktops, you can place different windows on specific or all desktops (Wayland has more flexibility than X11 here). Of course, this can be used to separate workflows, and there are plenty of people using them this way. That's the beauty of Plasma, you can make it fit your individual needs. Here are some things Activities allows for that Virtual Desktops do not.

Starting with the System Settings - Activities page, you can choose to enable or disable, for each:

Track file and app usage (disable for privacy, on a Financial Activity, for example)
Automatically turn the screen off (disable when gaming, presenting, streaming, etc.)
Automatically shut down or sleep the system (disable when gaming, presenting, streaming etc.)

Then, for these features, you can choose one Activity, multiple, or all.

Place different application windows (ex: your code editor on a Programming Activity) by launching it in that activity.
Pin an application to the task manager or in Favorites in the app menu (ex: your accounting software on a Financial Activity)
Desktop icons can be associated per Activity (Go to Settings -> Wallpaper -> Location and select "Files linked to current activity". This can be set per activity!)
Open an app in an activity (ex: opening your accounting software only on a Financial Activity, or a media player in all) with window rules

Additionally, for each Activity, you can have different wallpapers and widgets per Activity. This allows me to see, at a glance, which Activity is active and easily launch things.

Use cases

Here are some ways you can use Activities, and how I've found them helpful.

Separate your work stuff from your personal stuff Since I work from home, this helps me shift from my "at work" mindset to "at home". I much prefer this to relying on the old 45 minute commute ;)
Keep focus on the current task and context
I can avoid being distracted by stuff not related to what I'm doing at the moment by keeping things separated. While working on KDE bug triage, for instance, I won't be distracted by stuff that's not related. As much. Squirrel.
Keep sensitive information from being accidentally displayed until you want it to be One day, at a coffee shop, I realized that I didn't want people around me to necessarily see shortcuts like "Budget". I created a Financial Activity to keep sensitive information related to financial stuff hidden unless specifically switching to it.
A sparse Activity for presentations / recording / streaming
It could have nothing shown outside of the specific needs for that context. This not only avoids showing things to strangers you would prefer not to, it keeps your environment looking tailored.

How I organize my stuff by context

I have five Activities. All except the first one are configured to only show files related to the activity on the desktop.

Things common to all via pinned task manager icons:

Kate session chooser
Note widgets

Favorites and Quick Launch widgets per Activity:

Personal - All the stuff that isn't specific to anything else (general browsing, emails, etc).
No specific shortcuts, just a Weather widget on the desktop for my home city.
KDE - Where I focus on bug related work, MR testing, and such.
Favorites include a KDE Obsidian vault, Firefox KDE profile and a Discord client.
Solus - Volunteer work for packaging and distro coordination.
Favorites: Solus Obsidian vault and Vivaldi (it works better with Jitsi Meet than Firefox).
Financial - Budgeting, accounting, etc.
Favorites: an Obsidian vault and KMyMoney. There's a QuickLaunch widget containing links to a few folders, documents and spreadsheets.
Conference - Conference tasks and notes. Favorites: (you guessed it) a Travel Obsidian Vault. Weather widget set to the city I'll be in.
If speaking, I might have shortcuts to relevant documents and presentations.

Ramping up a workflow using the KDE Activity

To briefly illustrate efficiently getting into a workflow, I'll describe using my KDE Activity. It's based on my multi-screen setup at home. When I'm traveling and only have a single laptop display, applications are spread out across different Virtual Desktops as well.

Thunderbird email and Nheko chat have automatically started at login (through Session Saving). Using kwin window rules, they run on all Activities.
I open a music app via a Favorite (pinned on all Activities) and start playing music, which helps me focus. It has window rules to display on all Activities, so I can control it from wherever.
Then I launch applications from Favorites that are only on this Activity:
- A Discord client for work chat
- An Obsidian Notes vault for KDE (kwin rules also set position and size)
- Firefox with my KDE profile. It has specific bookmarks, as well as tabs for a time tracker, the KDE bug tracker, Invent, specific bugs and merge requests I need to test etc.

And now I'm ready to start working.

Going further - Combining Virtual Desktops and Activities

As I mentioned above, sometimes I also use Virtual Desktops to segregate different tasks per context. For instance, in my KDE Activity, I might have VDs for: Communication - email, chat Development - terminal, code editor Documentation - browser, notes app

Wrapping up

These are some ways you can customize Activities. Hopefully, you can see how they might streamline your own desktop and help your workflows be more efficient.

Technical notes - making shortcuts for specific Firefox profiles and Obsidian vaults

Firefox

Open Firefox with firefox -p to gain access to the profile picker. Use one of the profile names in your shortcut. In the menu editor, for example, after copying and pasting the default entry, change the Arguments:

%u -p profile_name

Obsidian

To create a shortcut to an Obsidian Notes vault, I copied the default .desktop file to ~/.local/share/applications/ and changed it to load the vault by name:

Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=obsidian.sh --file-forwarding md.obsidian.Obsidian @@u %u @@ 'obsidian://open?vault=vaultname'

Then, I customized the icon through the Menu Editor.

To find the location of the default .desktop file on your system:

Find Obsidian Notes in the application menu
Right click, and click Edit Application
Right click the entry in the Menu Editor and click "Open Containing Folder"

Going all-in on a Wayland future

The Plasma Team — Wed, 26 Nov 2025 00:01:00 +0000

Well folks, it’s the beginning of a new era: after nearly three decades of KDE desktop environments running on X11, the future KDE Plasma 6.8 release will be Wayland-exclusive! Support for X11 applications will be fully entrusted to Xwayland, and the Plasma X11 session will no longer be included.

For most users, this will have no immediate impact. The vast majority of our users are already using the Wayland session, it’s the default on most distributions, and some of them have already dropped — or are planning to drop — the Plasma X11 session independently of what we decide.

In the longer term, this change opens up new opportunities for features, optimizations, and speed of development.

Because we’re certain that many people will have questions about this change, the Plasma team has prepared the following FAQ:

Plasma 6.8 means the X11 session will be supported by KDE until…?

The Plasma X11 session will be supported by KDE into early 2027.

We cannot provide a specific date, as we’re exploring the possibility of shipping some extra bug-fix releases for Plasma 6.7. The exact timing of the last one will only be known when we get closer to its actual release, which we expect will be sometime in early 2027.

What if I still really need X11?

This is a perfect use case for long term support (LTS) distributions shipping older versions of Plasma. For example, AlmaLinux 9 includes the Plasma X11 session and will be supported until sometime in 2032.

Will X11 applications still work?

Outside of rare special cases, yes, they will still work using the Xwayland compatibility layer. It does a great job of providing compatibility for most X11 applications, and we provide several additional compatibility features on top, namely improved support for fractional scaling and (opt-in) backwards compatibility with X11 global shortcuts and input emulation.

In certain cases, 3rd-party applications doing specialized tasks like taking screenshots or screencasting need to be adjusted to work as expected on Wayland. Most have already done so, and the remaining ones are making progress all the time.

Does X11 forwarding still work?

Yes, Xwayland supports it. Waypipe exists for similar functionality in Wayland native applications as well.

Can I still run KDE applications on X11 in another desktop environment?

Yes. There are currently no plans to drop X11 support in KDE applications outside of Plasma.

This change only concerns Plasma’s X11 login session, which is what’s going away.

What about gaming?

Games run better than ever on the Wayland session! Adaptive sync, optional tearing, and high-refresh-rate multi-monitor setups are all supported out of the box. HDR gaming works with some additional setup, too!

What about NVIDIA GPUs?

While Wayland support in the proprietary NVIDIA driver was quite rocky a few years ago, it has matured tremendously. Graphics cards still supported by the manufacturer work just fine nowadays, and for very old NVIDIA GPUs, the open source Nouveau driver can be used instead.

What about accessibility?

Accessibility is a very broad topic, so it’s hard to make any definite statements, but we’re generally on par with the X11 session. All the basics already work as expected, including screen readers, sticky & bounce keys, zooming in, and so on.

Some things are better, like touchpad gestures for adjusting the zoom level, and applying systemwide color filters to correct for colorblindness. And even more improvements are expected by the time Plasma 6.8 rolls around.

However, accessibility features provided by third-party applications may be worse in some aspects. Please open a bug report if you have any special requirements that we don’t cover yet! This is an active topic we’re very interested in improving.

What about automation?

Many tools can be used for automation in the Wayland session; for example wl-copy/wl-paste, ydotool, kdotool, kscreen-doctor, and the plasma-apply-* tools. Generally Plasma is extensible enough that you can add what’s still missing yourself, for example through KWin scripts or plugins.

What about the Significant Known Issues?

While we can’t promise all problems will be completely gone (some depend on application support), we’re actively working on addressing the last stragglers on that Wiki page.

Some of them are really close to being fixed; for example, the issues around output mirroring will be gone in Plasma 6.6. Session restore and remembering window positions are also being actively worked on.

What about Plasma on the BSDs?

FreeBSD is already shipping a working Wayland session, so there should be no upstream problems on that front. If there are any remaining issues we can help with upstream, please reach out to us!

What about the kwin_wayland and kwin_x11 split?

In Plasma 6.4, we split KWin into separate X11 and Wayland versions. This allowed KWin to go all-in on Wayland earlier, without being held up so much with legacy support for X11. For users with remaining edge-case requirements for X11, we put in the extra effort to keep X11 support for the rest of the desktop since then.

While the split helped a lot, KWin is only one piece of the puzzle. The Plasma desktop as a whole has many places where development is held back by the need to support the lowest common denominator of the two window systems.

The bottom line

This is happening because we believe that eventually dropping the Plasma X11 session will allow us to move faster to improve stability and functionality for the majority of our users — who are already using Wayland.

If we want to keep producing the best free desktop out there, we have to be nimble enough to adapt to a rapidly changing environment with many opportunities, without the need to drag forward legacy support that holds back a great deal of work.

The Wayland transition has been long, and at times painful. But we’re very close to the finish line. Passing it will unlock a lot of positive changes over the next few years that we think folks are going to appreciate!

Revisiting X11 vs Wayland With Multiple Displays

Tracey Clark — Mon, 02 Jun 2025 00:00:00 +0000

The things I do for QA...

A few years ago, I was among those who found Wayland too painful to use every day. Over time, I gave Wayland a try now and then. It finally got usable enough for me to switch to as my default a couple of years ago.

Recently, during the soft freeze before the Plasma 6.4 Beta was released, I used mainly X11 on both my laptops - for science! And by science, I mean regression testing. I was curious what the experience was like compared to what I've become accustomed to with Wayland.

In short, Wayland supports multiple displays and color so much better. It was painful using X11 again.

My setup for daily work

I was using two laptops and two external monitors. Both were running Plasma built from git-master.

Main: Dell XPS laptop, plugged into a dock. This is connected to 2 ultrawide monitors - one via Displayport, the other via HDMI.
Secondary: Lenovo Flex laptop, usually just using its built-in screen. Sometimes I swap the right hand monitor over to it, for testing display shenanigans.

Initial impression - so limited

I fired up the XPS, did updates, and booted into an X11 session. Next, to Display Configuration to re-enable the right hand monitor (disabled the night before). Immediately, I was struck by how bare the settings window looks compared to Wayland. Here are screenshots of the settings for same HDR monitor on 6.3.5.

Wayland:

X11:

Second thoughts and hello, Dr Konqi

Time to enable the display. For reference, this takes moments in Wayland. It was just a wee bit longer and more fraught with X11.

After enabling the monitor and clicking Apply, all 3 screens went dark. After about 20s the laptop display came on. After about another minute, the right hand display finally got output before all 3 displays were dark again. I unplugged the laptop from the dock. It came up to the login screen. After logging in I saw the good Dr Konqi telling me there was a crash in plasmashell. We were off to a great start.

Like a good tester, I sent the crash report off. With some trepidation, I plugged the docking cable back in, as similar struggles from years past came back to haunt me. All three displays were black, although I could move the cursor around in them. It took a good couple of minutes for plasmashell to display everything, along with window decorations and panel contents. It was faster later, but wow, was this a noticeably worse experience than Wayland.

Other observations, or third thoughts

Wayland advantages

Fractional scaling - the ability to have a screen at, say, 110% zoom. See that lovely screenshot, above.
When paired with how easy it is to change font face and style, this is great for accessibility. Being able to read the text on any display at whatever resolution can't be overstated. When I have to use Windows, where you can't adjust text separately from resolution, I have sadness. I also have eyestrain trying to read tiny text in dialogs.
Scaling per display - so my laptop's high resolution display can be at 150% and my external displays at 100% to make things readable on all of them. Another plus for accessibility.
HDR and color profile (ICC) support. This is important for getting the mos out of my monitor with games and more. Also... preeeetty.
Snappier overall performance (on my systems).
The ability to send a window to multiple desktops, or just one. In X11, you can ....THNG

Wayland pain points

These are the things I ran into personally. There's also the list of Plasma/Wayland Known Significant Issues.

The most annoying problem for me is with LibreOffice, since I use Calc almost daily. There's a bug (on their tracker) where, with multiple monitors with different scale factors, UI elements are too big.
Lack of a robust, easy to use text expander with a GUI - that actually works out of the box. Autokey has been on my installs for many years, used for work and personal stuff. While it launches, and I have access to my phrases, there's no actual text expansion. There's an open issue for Wayland support (that pre-dates the Pandemic) but it hasn't gotten much traction. I've been keeping an eye out for years for a decent replacement, and have tried a few things but not found what I'm looking for, yet.
Copy and paste to and from VMs I use VMs a lot for testing things on different Linux distros. My workaround for this is to have text files saved in a directory that's shared from host to guest.
It took time and a few forks to get KVM software that was reliably developed and worked with Wayland.¹ I had been using barrier on X11. A few software forks and experiments later, I've settled on deskflow.

X11 Advantages

Remembering window positions across reboots.
Working text expansion.

X11 pain points

Drawing the screen is slower after logging in or restarting plasmashell, for example, with the same hardware and open applications.
Floating panels and adaptive opacity are known to cause performance issues with X11 with an NVIDIA GPU.
Lack of scaling per-monitor.
Text on my XPS's screen is too small to be readable if the external monitors are at a comfortable scale. I had to move any window I needed to read text on (most of them) to the external monitors.
The HDMI monitor was set to the wrong resolution and refresh rate if I connected it to the second laptop. I had to manually correct it.
After enabling HDR on that monitor with the Flex in Wayland, and switching to an X11 session, the monitor enabled HDR but the colors were over-saturated.
After working with a few windows, fonts in Firefox became badly hinted. This made characters look weirdly colored instead of white / black, and made reading things difficult.

Final thoughts

Once upon a time, Wayland was too painful for me to use as a daily driver. It didn't support some of my utilities and it wasn't stable enough with my multi-monitor setup.

These days, Wayland is so much more usable and stable with multiple displays that it makes using X11 painful by comparison. While there are still those few issues I mentioned, I feel Wayland's advantages outweigh them.

The KVM software journey... The first one I used was Synergy, which was amazing to me. Being able to use the same keyboard and mouse on both a Linux laptop and Windows desktop at the same time was magic. Unfortunately, Synergy took their UI in directions I didn't like. An open source fork named barrier emerged, which aimed to restore the simplicity I was looking for, so I switched to it. This served me for a long time, but development stopped in 2021. With the advent of Wayland, barrier was forked to input-leap which implemented Wayland support. Sadly, development seems to have languished. There is yet another project, deskflow, which is also free and open source. It's sponsored by the Synergy folks. We end where we began. ↩︎

kcursorgen and SVG cursors

Jin Liu — Sun, 12 Jan 2025 08:00:00 +0000

In the latest Plasma 6.3 Beta, you will find a new executable named kcursorgen in /usr/bin. It can convert an SVG cursor theme to the XCursor format, in any sizes you like. Although this tool is intended for internal use in future Plasma versions, there are a few tricks you can play now with it and an SVG cursor theme.

(Unfortunately, the only theme with the support that I know, besides Breeze, is Catppuccin. I have this little script that might help you convert more cursor themes.)

Requirements

The qt6-svg library.
The xcursorgen command, usually found in xorg-xcursorgen package.

Trick 1: Cursors at any size you like

You should be able to set any cursor size with SVG cursors, right? Well, not at the moment, because:

Only those apps using the Wayland cursor shape protocol would be using SVG cursors. Other apps still use the XCursor format, with a limited list of sizes.
Plasma's cursor setting UI hasn't been updated to allow arbitrary sizes.

But we can do it manually with kcursorgen. Take Breeze for example:

Step 1: Make a copy of the theme

First, copy the cursor theme to your home directory. And let's change the directory name, so the original one is not overriden:

mkdir -p ~/.local/share/icons
cp -r /usr/share/icons/breeze_cursors ~/.local/share/icons/breeze_cursors.my

Then open ~/.local/share/icons/breeze_cursors.my/index.theme in the editor. Change the name in Name[_insert your locale_]= so you can tell it from the original in the cursor settings.

Step 2: Regenerate the XCursor files

For example, if we want a size 36 cursor, and the display scale is 250%:

cd ~/.local/share/icons/breeze_cursors.my
rm -r cursors/
kcursorgen --svg-theme-to-xcursor --svg-dir=cursors_scalable --xcursor-dir=cursors --sizes=36 --scales=1,2.5,3

Some Wayland apps don't support fractional scaling, so they will round the scale up. So we need to include both 2.5 and 3 in the scale list.

The above command generates XCursor at size 36, 90 and 108. Note that the max size of the original Breeze theme is 72, so this is something not possible with the original theme.

(kcursorgen also adds paddings when necessary, to satisfy alignment requirements of some apps / toolkits. E.g., GTK3 requires cursor image sizes to be multiple of 3 when the display scale is 3. So please use --sizes=36 --scales=1,2.5,3, not --sizes=36,90,108 --scales=1, because only the former would consider alignments.)

Then you can go to systemsettings - cursor themes, select your new theme, and choose size 36 in the dropdown.

(Yes, you can have HUGE cursors without shaking. Size 240.)

Trick 2: Workaround for the huge cursor problem in GTK4

As explained before, Breeze theme triggers a bug in GTK4 when global scaling is used, resulting in huge cursors. It's because Breeze's "nominal size" (24) is different from the image size (32).

We can work around this problem by changing the nominal size to 32.

Step 1 is same as above. Then we modify the metadata:

cd ~/.local/share/icons/breeze_cursors.my
find cursors_scalable/ -name 'metadata.json' -exec sed -i 's/"nominal_size": 24/"nominal_size": 32/g' '{}' \;
rm -r cursors/
kcursorgen --svg-theme-to-xcursor --svg-dir=cursors_scalable --xcursor-dir=cursors --sizes=32 --scales=1,1.5,2,2.5,3

Then you can go to systemsettings - cursor themes, select your new theme, and choose size 32 in the dropdown. Cursors in GTK4 apps should be fixed now.

Extra idea: (For distro maintainers) reduce cursor theme package size to 1/10

It might be possible to only package the index.theme file and cursors_scalable directory for the Breeze cursor theme (and other SVG cursors themes), then in an postinstall script, use kcursorgen to generate the cursors directory on the user's machine.

This would greatly reduce the package size. And also you can generate more sizes without worrying about blown package size.

But the fact that kcursorgen is in the breeze package might make some dependency problems. I have an standalone Python script that does the same. (But it requires Python and PySide6.)

Limit Application Memory Usage with systemd

Jin Liu — Fri, 18 Oct 2024 10:00:00 +0000

I saw this question on KDE forum about how to limit memory usage of a specific application in KDE, using systemd specifically. I did some research on that.

Resource control in systemd

man systemd.resource-control lists plenty of options that we can set to a cgroup. E.g., to limit the memory usage of a service, we can add:

MemoryAccounting=yes
MemoryHigh=2G

under the [Service] section of its .service file.

The difference between this and ulimit is that ulimit is per process, while systemd resource control is per cgroup. I.e., the MemoryHigh is accounted to the sum of both the service process, and all sub-processes it spawns, and even detached processes, i.e., daemons.

(That's actually the main point of cgroup: a process tree that a process can't escape via double-forking / daemonizing.)

Apps as systemd services

KDE Plasma launches apps as systemd services. (See this doc and this blog for more details.)

We can find the name of the systemd service of an app like this:

$ systemd-cgls|grep konsole
│ │ │ ├─app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service
│ │ │ │ ├─35275 /usr/bin/konsole
│ │ │ │ └─35471 grep --color=auto konsole

But the problem is:

The part of the name after @ is a random string, changes every time the app is launched.
The service is generated dynamically:

$ systemctl --user cat app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service

# /run/user/1000/systemd/transient/app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Service]
Type=simple
...

So if we want to limit the memory usage of Konsole, there's no persistent .service file on disk that we can edit.

Luckily, systemd allows us to create drop-in files to partially modify a service. Also, systemd considers app-org.kde.konsole@0d82cb37fcd64fe4a8b7cf925d86842f.service to be instances of a template named app-org.kde.konsole@.service. (This is how things like getty@tty3.service work.) So we can create a drop-in file named ~/.config/systemd/user/app-org.kde.konsole@.service.d/override.conf with the content:

[Service]
MemoryAccounting=yes
MemoryHigh=2G

and it will apply to all instances of app-org.kde.konsole@.service, even if there's no service file with that name.

(The file doesn't have to be named "override.conf". Any name with .conf works.)

Then we need to reload the systemd user manager: systemctl --user daemon-reload.

Now we can launch Konsole, and check if the memory limit works:

$ systemctl --user show 'app-org.kde.konsole@*.service'|grep MemoryHigh=
EffectiveMemoryHigh=2147483648
MemoryHigh=2147483648
StartupMemoryHigh=infinity

Note: as explained above, the limit applies to the sum of Konsole and all processes it spawns. E.g., if we run kwrite in Konsole, the memory usage of kwrite will be accounted to the limit of Konsole, and the limit we set to KWrite won't apply.

Set defaults for all apps

We can put defaults in ~/.config/systemd/user/app-.service.d/override.conf, and it will match all services whose name starts with app-.

Alternatively, if we run systemd-cgls, we can see that all apps are under a node named app.slice. So we can also put defaults in ~/.config/systemd/user/app.slice.d/override.conf, and all apps will inherit the settings. However, this is different from the previous method, as user services are also under app.slice by default, so they will also inherit the settings.

Cursor Size Problems In Wayland, Explained

Jin Liu — Wed, 09 Oct 2024 09:36:02 +0000

I've been fixing cursor problems on and off in the last few months. Here's a recap of what I've done, explanation of some cursor size problems you might encounter, and how new developments like Wayland cursor shape protocol and SVG cursors might improve the situation.

(I'm by no means an expert on cursors, X11 or Wayland, so please correct me if I'm wrong.)

Why don't we have cursors in the same size anymore?

My involvement with cursors started back in the end of 2023, when KDE Plasma 6.0 was about to be released. A major change in 6.0 was enabling Wayland by default. And if you enabled global scaling in Wayland, especially with a fractional scale like 2.5x, cursor sizes would be a mess across various apps (the upper row: Breeze cursors in Plasma 6.0 Beta 1, Wayland, 2.5x global scale, the lower row: Same cursors in Plasma 6.0):

So I dug into the code of my favorite terminal emulator, Kitty, which at the time drew the cursor in a slightly smaller size than it should be (similar to vscode in the above image). I gained some understanding of the problem, and eventually fixed it. Let me explain.

How to draw cursors in the same size in different apps?

In X11, there used to be a standard set of cursors, but nowadays most apps use the XCursor lib to load a (user-specified) cursor theme and draw the cursor themselves. So in order to have cursors in the same theme and size across apps, we need to make sure that:

Apps get the same cursor theme and size from the system.
Apps draw the cursor in the same way.

The transition to Wayland created difficulties in both points:

1. Get the same cursor theme and size from the system

It used to be simple in X11: we have Xcursor.size and Xcursor.theme in xrdb, also XCURSOR_SIZE and XCURSOR_THEME in environment variables. Setting them to the same value would make sure that all apps get the same cursor theme and size.

But Wayland apps don't use xrdb, and they interpret XCURSOR_SIZE differently: in X11, the size is in physical pixels, but in Wayland it's in logical pixels. E.g., if you have a cursor size 24 and global scale 2x, then in X11, XCURSOR_SIZE should be 48, but in Wayland it should be 24.

The Wayland way is necessary. Imagine you have two monitors with different DPI, e.g. they are both 24" but monitor A is 1920x1080, while monitor B is 3840x2160. You set scale=1 for A and scale=2 for B, so UI elements would be the same size on both monitors. Then you would also want the cursor to be of the same size on both monitors, which requires it to have 2x more physical pixels on B than on A, but it would be the same logical pixels.

So Plasma 6.0 no longer sets the two environment variables, because XCURSOR_SIZE can't be simultaneously correct for both X11 and Wayland apps. But without them and xrdb, Wayland apps no longer have a standard way to get the cursor theme and size. Instead, different frameworks / toolkits have their own ways. In Plasma, KDE / Qt apps get them from the Qt platform integration plugin provided by Plasma, GTK4 apps from ~/.config/gtk-4.0/settings.ini (also set by Plasma), Flatpak GTK apps from the GTK-specific configs in XDG Settings Portal.

The last one is particularly weird, as you need to install xdg-desktop-portal-gtk in order fix Flatpak apps in Plasma, which surprised many. It might seem like a hack, but it's not. Plasma officially recommends installing xdg-desktop-portal-gtk, and this was suggested by GNOME developers.

But what for 3rd-party Wayland apps besides GTK and Qt? The best hope is to read settings in either the GTK or the Qt way, piggy-backing the two major toolkits, assuming that the DE would at least take care of the two.

(IMHO either Wayland or the XDG Settings Portal should provide a standard way for apps to get the cursor theme and size.)

That was part of the problem in Kitty. It used to read settings from the GTK portal, but only under a GNOME session. I changed it to always try to read from the portal, even if under Plasma. But that's not the end of the story...

2. Draw the cursor in the same way

It's practically a non-issue in X11, as the user usually sets a size that the cursor theme provides, and the app just draws the cursor images as-is. But if you do set a cursor size not available in the theme (you can't do that in the cursor theme settings UI, but you can manually set XCURSOR_SIZE), you'll open a can of worms: various toolkits / apps deal with it differently:

Some just use the closest size available (Electron and Kitty at the time), so it can be a bit smaller.
Some use the XCursor default size 24, so it's a lot smaller.
Some scale the cursor to the desired size, and the scaling algorithm might be different, resulting in pixelated or blurry cursors; Also they might scale from either the default size or the closest size available, resulting in very blurry (GTK) or slightly blurry (Qt) cursors.

The situation becomes worse with Wayland, as the user now specifies the size in logical pixels, then apps need to multiply it by the global scale to get the size in physical pixels, and try to load a cursor in that size. (If the app load the cursor in the logical size, then either the app or the compositor needs to scale it, resulting in a blurry / pixelated cursor.) With fractional scaling, it's even more likely that the required physical size is not available in the theme (which typically has only 2~5 sizes), and you see the result in the picture above.

One way to fix it (and why I didn't do)

It can be fixed by moving the "when we can't load cursors in the size we need, load a different size and scale it" logic from apps / toolkits to the XCursor lib. When the app requests cursors in a size, instead of returning the closest size available, the lib could scale the image to the requested size. So apps would always get the cursor in the size they ask for, and their own different scaling algorithms won't get a chance to run.

Either the default behavior can be changed, or it can be hidden behind a new option. But I didn't do that, because I felt at the time that it would be difficult to either convince XCursor lib maintainers to make a (potentially breaking) change to the default behavior, or to go around convincing all apps / toolkits to use a new option.

My fix (or shall we say workaround)

Then it came to me that although I can't fix all these toolkits / apps, they seem to all work the same way if the required physical size is available in the theme - then they just draw the cursor as-is. So I added a lot of sizes to the Breeze theme. It only has size 24, 36 and 48 at the time, but I added physical sizes corresponding to a logical size 24 and all global scales that Plasma allows, from 0.5x to 3x, So it's 12, 18, 24 ... all the way to 72.

It was easy. The source code of the Breeze theme is SVG (so are most other themes). Then a build script renders it into images using Inkscape, and packages them to XCursor format. The script has a list of the sizes it renders in, so I added a lot more.

And it worked! If you choose Breeze and size 24, then (as in the bottom row in the picture above) various apps draw the cursor in the same size at any global scale available in Plasma.

But this method has its limitations:

We can't do that to 3rd-party themes, as we don't have their source SVG.
It only works if you choose the default size 24. If you choose a different size, e.g. 36, and a global scale 3x, then the physical size 36x3=108 is not available in the theme, and you see the mess again. But we can't add sizes infinitely, as explained in Vlad's blog, the XCursor format stores cursor images uncompressed, so the binary size grows very fast when adding larger sizes.

Both limitations can be lifted with SVG cursors. But before getting to that, let's talk about the "right" way to fix the cursor size problem:

The "right" fix: Wayland cursor shape protocol

The simple and reliable way to get consistent cursors across apps is to not let apps draw the cursor at all. Instead, they only specify the name of the cursor shape, and the compositor draws the cursor for them. This is how Wayland cursor shape protocol works. Apps no longer need to care about the cursor theme and size (well, they might still need the size, if they want to draw custom cursors in the same size as standard shapes), and since the compositor is the only program drawing the cursor, it's guaranteed to be consistent for all apps using the protocol.

(It's quite interesting that we seem to went a full circle back to the original server-defined cursor font way in X11.)

Support for this protocol leaves a lot to improve, though. Not all compositors support it. On the client side, both Qt and Electron have the support, but GTK doesn't.

There are merge requests for GTK and Mutter, but GNOME devs request some modifications in the Wayland protocol before merging them, and the request seems to be stuck for some months. I hope the recent Wayland "things" could move it out of this seemingly deadlock.

Anyway, with this protocol, only the compositor has to be modified to support a new way to draw cursors. This makes it much easier to change how cursors work. So we come to:

SVG cursors

Immediately after the fix in Breeze, I proposed this idea of shipping the source SVG files of the Breeze cursor theme to the end user, and re-generate the XCursor files whenever the user changes the cursor size or global scale. This way, the theme will always be able to provide the exact size requested by apps. (Similar to the "modify XCursor lib" idea, but in a different way.) It would remove the limitation 2 above (and also limitation 1 if 3rd-party themes ship their source SVGs too).

With SVG cursors support in KWin and Breeze, I plan to implement this idea. It would also allow the user to set arbitrary cursor size, instead of limited to a predefined list.

Problems you might still encounter today

Huge cursors in GTK4 apps

It's a new problem in GTK 4.16. If you use the Breeze cursor theme and a large global scale like 2x or 3x, you get huge cursors:

It has not limited to Plasma. Using Breeze in GNOME would result in the same problem. To explain it, let me first introduce the concept of "nominal size" and "image size" in XCursor.

Here is GNOME's default cursor theme, Adwaita:

"Nominal size" is the "cursor size" we are talking about above. It makes the list of sizes you choose from in the cursor theme settings UI. It's also the size you set in XCURSOR_SIZE. "Image size" is the actual size of the cursor image. "Hot spot" is the point in the image where the cursor is pointing at.

Things are a bit different in the Plasma default cursor theme, Breeze:

Unlike Adwaita, the image size is larger than the nominal size. That, combined with a global scale, triggers the bug in GTK4. Explanation of the bug.

XCursor allows the image size to be different from the nominal size. I don't know why it was designed this way, but my guess is so you can crop the empty part of the image. This both reduces file size, and reduces flicking when the cursor changes (with software cursors under X11). But the image size can also be larger than the nominal size, and Breeze (and a lot of other themes) uses this feature.

You can see in the above images that the "arrow" of nominal size 24 in Breeze is actually similar in size to the same nominal size in Adwaita. But the "badge" in Breeze is further apart, so it can't fit into a 24x24 image. That's why Breeze is built this way. In a sense, "nominal size" is similar to how "font size" works, where it resembles the "main part" of a character in the font, but some characters can have "extra parts" that go through the ceiling or floor.

This problem is already fixed in the main branch of GTK 4, but it's not backported to 4.16 yet, probably because the fix uses a Wayland feature that Mutter doesn't support yet. So at the moment, your only option is to use a different cursor theme whose "nominal size" and "image size" are equal.

Smaller cursors in GTK3 apps (most notably, Firefox)

The cursor code in GTK3 is different from GTK4, with its own limitations. You might find the cursor to be smaller than in other apps, and if you run the app in a terminal, you might see warnings like:

cursor image size (64x64) not an integer multiple of scale (3)

GTK3 doesn't support fractional scales in cursors. So if you have cursor size 24 and global scale 2.5x or 3x, it will use a scale 3x and try to load a cursor with a nominal size 24x3=72. And it requires the image size to be an integer multiple of the scale. So if your theme doesn't have a size 72, or it does but the image size is not multiple of 3, GTK3 fallbacks to a smaller unscaled cursor.

End words

OK, this is a long post. Hope I can bring you more cursor goodies in Plasma 6.3 and beyond.

A few thoughts on Plasma/Wayland, KWinFT

Eike Hein — Mon, 19 Oct 2020 00:00:00 +0000

There's a lot of intense, opinionated debate on the current state of Plasma's Wayland session these days. This seems to be fueled by mainly two events, Fedora's announcement to flip to Wayland by default for version 34 of their KDE variant, and a a recent fork of KWin and a few other components of Plasma, KWinFT.

On the first, I think it's a great move. Concerns of a repeat of the "shipped before it's ready" situation of early KDE 4 releases aside (for now; more on this in a moment), it certainly feels like it makes sense for Fedora in particular - it's a bold, technology-focused early adopter move, something I think the Fedora user audience generally appreciates the distro for. Plus other Fedora variants default to Wayland already, so there's an appreciable desire to make the various offerings more consistent.

Distros should understand the user audiences they're trying to cater to, and if a distro believes there's a market for a particular flavor of desktop, it's certainly fine to challenge upstreams to provide the needed software. I think as far as Plasma on Wayland is concerned, the challenge is thoughtfully timed - it's coming after the KDE community voted to declare good Wayland support a community-wide goal, after all. I think there's every reason to believe this decision will lead to good things if the two (and overlapping) communities collaborate to make a good showing. Nice.

It's 2020, for crying out loud! Why is this taking so long?

A lot of us have some things in common. For example, if you're reading this, chances are you are the sort of person who is not indifferent to technological progress, even easily excited by it. Many of us also are also drawn to competition.

So people really care about how far down the road to Wayland adoption every of the competing projects is, and theories abound on what the comparison says about them. This is set against a backdrop of Wayland also still maturing as an upstream technology, driven forward by the same competing projects working together.

One particular claim that's been popping into the conversation lately is that Plasma not having the Wayland conversion safely in it's rear-view mirror yet is evidence of a project that's somehow fundamentally flawed, and unable to focus on what matters and make good long-term plans and roadmaps. If you didn't encounter this in one of the heated debates on social media yet it probably sounds a bit breathless to you, or maybe not really worth acknowledging - but it's actually my main reason to write this blog post, because it's an interesting excuse to talk about recent Plasma history!

Plasma 5.0 was the second large-scale rewrite of KDE's desktop environment offering in a row, meaning both 4.0 and 5.0 had debuted with a lot of new and young lines of code inside them. Both rewrites were motivated by lifting the desktop shell to a newer set of its base technologies - for example major versions of Qt, OpenGL-based UI rendering and so on. Younger code tends to have higher defect rates. At the time, the standard criticisms in online discussions about Plasma went something like this:

"It looks great, but it's really buggy" "I like a lot of the features, but it's missing those last 5% to fit my needs fully" "It's resource-heavy and doesn't perform smoothly enough on my machine"

And a less concrete one, but nearly as often repeated:

"It's really coming together now, but I'm already worried about the next major version being another rewrite and making it shaky"

The Plasma project paid attention, and made a number of very strategic decisions to set its focus on a set of goals:

Improve quality across the board by prioritizing bugs and bringing defect rates down
Go the distance with features, drive them to completion and make them easier and more consistent to use
Lower the resource needs and scale down to much lower-powered hardware, including ARM SBCs
If we do additional rewrites of fundamental code (and we ended up replacing major pieces in 5.x point releases, e.g. the entire taskbar, menu and notification systems - each of those quietly addressed dozens of bugs, but went mostly noticed for a few new features), there needs to be a noticeably positive impact on the above metrics

This remains the spirit of the Plasma project today, with many activities spanning multiple quarters of a year of work at the service of those goals. Recent examples include the Breeze visual refresh undertaken by the Visual Design Group, the revamp of session init with optional use of systemd, and the new cgroups-loving way of running apps.

For Plasma on Wayland, this meant: While we strongly believing in the tech, we would take our time to get it right, and not declare the offering ready before it isn't up to par. It also wasn't always the highest-priority development activity going on, with many other steps being simultaneously taken to reach our goals. Reasonable people can (and do) have diverging opinions on the relative prioritization of work, of course, but the path we walked was most definitely a consciously strategic one - one that has lead to the gradual disappearance of those earlier quotes from user feedback we receive, speaking to its execution. Work continues!

KwinFT

One source of these concerns is the KWinFT project, a recent fork of the compositor service in a Plasma system along with a few choice pieces of support code (e.g. the screen config subsystem).

KWinFT is a project by Roman Gilg, a contributor to KWin and KDE in general. Roman will not be shocked by reading this, as we had this discussion a couple of months before he announced the project, as well as recently, but I don't think the fork was necessary, or is a very good idea overall. I think his technical ideas for KWin are interesting, and think there were better options to deliver their value to users and have a bigger impact in the end, e.g. by making more aggressive use of feature/staging branches to prove out subsystem rewrites before merging them up. This is a suggestion I made at the time, too, and I haven't seen anything to change my mind since. We certainly keep talking.

This is a very personal opinion and speaks to my own style to open source involvement more than anything, which is shaped by the vibe of the KDE community and the KDE mentors and role models I received my education from. I believe in prioritizing user value, and in leadership by aligning diverse talents towards common goals, by being inviting, communicative and persuasive. I really don't believe these options were fully exhausted in this matter, and while I understand that starting a new project can make it easier to try out e.g. some different organizational ideas (and my impression of the fork is that it's really more about those than any actual tech disagreements) without having to do the work of getting others on board, I don't think this ultimately succeeds in bringing improvements to the max number of people who might benefit from them.

On the tech side, though, it's important to keep the focus of the conversation on Plasma on Wayland as a whole. KWin is an important component of that system, but owing to its multi-process architecture, it's only one of a fairly large and varied set of codebases that need to complete their porting efforts. Many use cases additionally require coordinated activity across several components (for example: the taskbar, System Settings, ...), and it's also still not too difficult to identify needed upstream improvements in Wayland to get over the finish line, some of which the Plasma team is currently driving forward.

And no, this isn't stacking features on shaky foundations - most of this work is technically orthogonal (easy to see for the ones that aren't in the same codebase or even project!), and in any case, the more pleasant Plasma's Wayland session becomes to consume, the higher the set of potential contributors exposed to the remaining tasks. Those attention dynamics of open source are fairly reliable :-). In any case, this is perhaps actually my main beef with the technical criticisms coming from the debates surrounding KWinFT - they are myopically focused on KWin and derive from this grander projections, ignoring the full picture of the system and a lot of other heavy-hitting technical activity all throughout it (including some of the projects linked throughout this post). The resulting signal-to-noise ratio is not very engaging overall. KWin != Plasma is an important constraint to add to them.

Engineering Plasma: Extensions and stability — Present and future

Eike Hein — Thu, 02 Aug 2018 00:00:00 +0000

This week, we have received a number of inquiries into how Plasma extensions, particularly those found on the KDE Store, relate to the stability and safety of a Plasma system. With an engineering focus, this blog hopes to provide answers.

Crash Resilience By Process Isolation

Present-day process architecture: Compositor and shell UI are isolated from each other

In Plasma, the shell UI and the compositor are isolated into seperate processes (plasmashell and kwin, respectively). The two exchange information regulated by IPC mechanisms such as the windowing system (Wayland or X11) and DBus, using standard protocols where suitable and custom-created ones where needed.

In a Wayland session, it's kwin that plays host to your application clients and puts them on screen (on X11, both KWin and app are clients to the X Server, providing a further isolation - KWin can crash and restart without impacting apps). Shell UI extension live in the seperate plasmashell process.

In the event that a shell extension crashes the shell, this allows it to be restarted without impacting KWin and therefore without impacting your applications. They continue to run undeterred while the shell takes steps to right itself.

Beyond crash resilience, putting limits on untrusted code run in the compositor process also has a security dimension. Particularly on Wayland, where one of the design goals is not to allow untrusted code to introspect the windowing system globally.

Meanwhile, to make KWin ready to taking over for the X Server in a Wayland session, we significantly upgraded our engineering story - requiring and dramatically raising unit test coverage for KWin and related library code, for one.

Process Isolation: Next Steps

The architecture discussed above shields applications and the compositor from shell UI extensions, but it doesn't shield the shell. We want to fix that next.

Next: Isolate shell UI and extensions, too — individual or batch processes for extensions

The always-stunning David Edmundson has been spearheading several engineering efforts to make the shell itself have a multi-process architecture. Some of this has already quietly been shipping in the Plasma 5.12 LTS release: KRunner plugins, which provide search results in our menus/launchers, can now opt into running out-of-process. We've used this to isolate some of the crash chart-topping plugins, preventing them from taking down the shell when performing a search query.

Likewise, for shell UI extensions, he has been working on top off the library stack we initially built for the Wayland transition to allow them to be run out of process and then get composited into the shell UI. In addition to making the shell far more resilient to extension crashes, this would also create additional security domains for untrusted extension code - we can build on this to sandbox and drop privileges for them.

All of this is broadly similar to application architecture improvements pioneered by multi-process web browsers in past years, albeit built squarely to leverage the shared free desktop stack (particularly Wayland and DBus). Unlike what took place in Firefox' project Electrolysis, however, we don't see a need to break extension compatibility in our case. For Plasma's extension API scope, we've always taken a conservative demand-based approach instead of allowing extensions free access to all data and code by default. This is paying dividends now, allowing us new shell architecture options while preserving the known, stable API contract it has with its extensions.

David is set to show off the R&D proof of concept we have working now in his talk at this year's Akademy conference, which I can't wait to attend. Be sure to also keep your eyes peeled on his blog, where he will dive deeper into the details of this project after the conference excitement.

In Summary

Plasma today is architected to prevent shell UI extensions from being able to crash your session and interfere with your apps. We are working to expand on this and prevent extensions from interfering with the shell.

In Context

One of the broad goals of Plasma 5 has been raising quality. This is a user-driven process. Converting feedback we got during the first generation of Plasma into software, we worked hard to bring Plasma users tangible improvements to speed, resource usage and UI polish (this is by no means over, either). We also already implemented a LTS release process to improve our support story.

Dove-tailing with the KDE community's Goals, climbing higher on the ladder of safety and security is one of our immediate next ones. Increasing process isolation in Plasma and achieving state of the art crash resilience and sandboxing, a likely first on the desktop, is a concrete engineering expression of this aim.

Sounds interesting? If you want to be part of a team and a community that keeps pushing the desktop (and not just the desktop) forward in the days to come, join us in one of our channels.

Of course: