KWin Scripting from 5.x to 6.x -- Compatible?

Development
32

@nclarius @zzag

It seemed a shame to throw away the version of the KWin script I did with the abstractions, so I figured out what the problem was and made it work.

This attribute of a window object in KDE 5:

window.x11DesktopIds

Needed to be replaced with this:

window.desktops

This appears to do the same thing, providing the list of virtual desktops where the app window appears. With this and the other abstractions, the KWin script works the same way in KDE 5 and 6, in my testing, without any changes or templating operations needed. But I would appreciate a confirmation that this is the correct replacement for that specific element.

Other than that, this is all I had to do:

const isKDE6 = typeof workspace.windowList === 'function';

let activeWindow;
let windowList;
let connectWindowActivated;
let setActiveWindow;
let isAppOnCurrentDesktop;

// Set up aliases to abstract away the API differences between KDE 5 and KDE 6
if (isKDE6) {
    activeWindow                = () => workspace.activeWindow;
    windowList                  = () => workspace.windowList();
    connectWindowActivated      = (handler) => workspace.windowActivated.connect(handler);
    setActiveWindow             = (window) => { workspace.activeWindow = window; };
    isAppOnCurrentDesktop       = isAppOnCurrentDesktopKDE6
} else {
    activeWindow                = () => workspace.activeClient;
    windowList                  = () => workspace.clientList();
    connectWindowActivated      = (handler) => workspace.clientActivated.connect(handler);
    setActiveWindow             = (window) => { workspace.activeClient = window; };
    isAppOnCurrentDesktop       = isAppOnCurrentDesktopKDE5
}

I present this only as a proof-of-concept that could be worth a look for a lot of simpler KWin scripts, but may not be worth the effort on KWin scripts where the differences are more significant. Although, technically, API abstractions like this are quite common in programming, and could probably be done even with elements that now return different data types or structures. If the differences can be normalized without too much trouble. All the code cares about are the end results, right?

The journal command to monitor KWin script debugging output worked with no difficulty on Neon Unstable (KDE 6) but I haven’t had any luck seeing that output in Fedora 39 KDE spin (KDE 5) even after putting the Qt logging environment variable in ~/.bash_profile. So I really don’t know what’s going on there. It was Wayland in both cases.

I will note here that I ran into trouble with a project unrelated to this KWin script, on some Arch-based and RHEL-type distros (like AlmaLinux), with a syntax like this:

journalctl --user -u my-user-unit

or…

journalctl --user --unit=my-user-unit

I had to replace that with a combined option syntax like this:

journalctl --user-unit=my-user-unit

… to get any output for user services on those distros. (This is not related to the problem with the debugging output on Fedora 39.)

Anyway, I was able to make a version-agnostic KWin script and an installer script that pays attention to the KDE version environment variable and uses the corresponding 5/6 utilities to do the install/uninstall. Seems to work fine.

4 Likes