The WM_CLASS
Property is used on X11 to assign rules to certain windows, e.g. “this is a GIMP window, it should appear on workspace number 16.” It consists of two fields, name
and class
.
Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called app_id
.
When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.
Some compositors map name
to app_id
, others map class
to app_id
, and even others directly expose the original name
and class
.
Apparently, there is no consensus.
Okay, now this is a very interesting Rust feature:
https://blog.rust-lang.org/2025/07/03/stabilizing-naked-functions/
This (and inline assembly) makes Rust really interesting for very low-level stuff. 🥳
It took about a year, I think, but I’ve now finished another run of Tomb Raider I, II, and III. And I have, for the first time, played the two bonus packs “Unfinished Business” (for TR I) and “Golden Mask” (for TR II). They’re available as a free download, if you have the original games. (The bonus pack for TR III is not free.)
I just love these games – and the game mechanics. It’s just the right balance between challenging and relaxing.
Someone did a thing:
https://social.treehouse.systems/@ariadne/114763322251054485
I’ve been silently wondering all the time if this was possible, but never investigated: Keep doing X11 but use Wayland as a backend.
This uses XWayland’s “rootful” mode, which basically just gives you a normal Wayland window with all the X11 stuff happening inside of it:
https://www.phoronix.com/news/XWayland-Rootful-Useful
In other words, put such a window in fullscreen and you (more or less) have good old X11 running in a Wayland window.
(For me, personally, this won’t be the way forward. But it’s a very interesting project.)