How I built native Wayland window tracking across Hyprland, GNOME and KDE in C++23

Plexescor (Abhijot Singh) — Sat, 16 May 2026 11:24:22 +0000

If you've ever tried to get the currently focused window on Wayland, you know it's a mess. There's no unified API. Every compositor does it differently. X11 had _NET_ACTIVE_WINDOW and everyone just used that. Wayland deliberately doesn't have an equivalent for security reasons, which means every tracker, every productivity tool, every anything that needs to know what you're looking at has to implement a different solution per compositor.

I ran into this while building HPR, an activity tracker that watches your active window every 50ms and logs time per app. Here's how I solved it for the three most common Wayland compositors.

Hyprland

Easiest of the three. Hyprland exposes an IPC socket and a CLI tool called hyprctl. One command gives you the active window as JSON:

hyprctl activewindow -j | jq -r '.class'

That's it. No extension, no setup, no workarounds. Just works on first launch. The .class field gives you the application class which is consistent and clean. I call this every 50ms from a background thread and it holds up fine.

GNOME

GNOME on Wayland is the painful one. There's no official API for getting the active window from outside the compositor. The only working solution I found is a shell extension called window-calls-extended which exposes a DBus interface you can query:

gdbus call --session --dest org.gnome.Shell \
  --object-path /org/gnome/Shell/Extensions/WindowsExt \
  --method org.gnome.Shell.Extensions.WindowsExt.FocusClass

This returns the window class wrapped in some dirty output you have to parse. HPR checks on startup whether the extension is active. If it isn't, it tells the user exactly what to do instead of silently returning garbage. Because GNOME can't hot-reload shell extensions you log out and back in once after installing. Every launch after that is automatic.

One thing worth knowing: GNOME shell extensions are sandboxed differently across GNOME versions and some distributions patch the shell in ways that break extension APIs. If you're supporting GNOME you need to test across versions.

KDE Plasma

KDE was the one I expected to be easy and wasn't. KDE exposes KWin scripting via qdbus6 which lets you inject JavaScript into the compositor and read the output. The active window class comes from workspace.activeWindow.resourceClass.

The problem is KWin doesn't give you a clean return value. The script runs, prints output to the system journal with a js: prefix, and you have to scrape it back out:

echo 'print(workspace.activeWindow.resourceClass);' > /tmp/kwin_active.js
S=$(qdbus6 org.kde.KWin /Scripting org.kde.kwin.Scripting.loadScript /tmp/kwin_active.js kwin_tmp_$$)
T=$(date '+%Y-%m-%d %H:%M:%S')
qdbus6 org.kde.KWin /Scripting/Script$S org.kde.kwin.Script.run > /dev/null 2>&1
sleep 0.1
journalctl --since "$T" -o cat | grep '^js:' | tail -n 1 | sed 's/^js: //'

Yes this is a hack. It forks a shell, injects JS, scrapes the journal, and cleans up after itself every 50ms. Somehow it lands at around 1% CPU. I tested every other approach I could find. None of them worked reliably across KDE configurations. This one does.

One side effect: during the JS injection, KWin's own runtime briefly appears as the active window. If you don't filter it out, strings like js::kwin_tmp_1234 silently accumulate time in your logs. HPR filters anything containing js:: before it ever touches the data.

The normalization layer

Each backend returns a raw string. Raw strings from OS window APIs are inconsistent and noisy. HPR runs every return value through a shared normalization function before doing anything with it. This filters out compositor artifacts, plasma shell entries, null strings, and KWin JS runtime noise. New backends inherit this filtering automatically.

Platform detection

HPR reads $XDG_CURRENT_DESKTOP and matches substrings. Simple, works for 99% of setups. Non-standard session variables or nested compositors can confuse it but that's an edge case worth documenting rather than engineering around.

The project

HPR is open source, C++23, Slint UI, SQLite3 bundled. If you're on Wayland and want an activity tracker that actually works without a Python runtime or an embedded web server, give it a try.

GitHub: github.com/plexescor/HPR

If you've solved Wayland window detection in a cleaner way especially on KDE, I'd genuinely like to know.