I have a project that uses a keymapper (written in Python) to enable app-specific sets of shortcut remaps. This was fairly easy in X11, using Xlib to grab the WM_CLASS and WM_NAME attributes of the window, and originally the keymapper would just assume you were using X11. If you weren’t, there was no window info available, so no app-specific remaps would ever activate.
I made a development branch of the keymapper and started adding methods that would get the same active window class and name/title info for a very limited set of Wayland environments, like GNOME, KDE Plasma, and sway (and maybe Hyprland, but nobody has tested that method yet). Unfortunately, in Wayland, these methods are up to the specific implementation of the compositor, from what I understand. Some of the methods are quite complicated, others like sway just use IPC calls, so they aren’t too difficult to get working. But each one is quite different, unlike when every desktop environment just used X11/Xorg.
There was an article on Phoronix about Lubuntu/LXQt moving to a Wayland session soon:
So I’m looking for pointers to information about exactly how the Wayland transition is being done. In KDE Plasma I was forced to use a D-Bus service and KWin script in order to acquire the necessary window info. If the compositor that will be used for LXQt is based on wlroots and has the “foreign toplevel management” protocol implemented, maybe I could have the keymapper working on LXQt relatively easily once I figure out how to get that method working. But if this is yet another custom Wayland compositor situation, I’ll need some help figuring out if it is possible to get the window class and title from Python, to make my project work.
Any information at all about this would be appreciated.
Current development focus is on noble or what will be 24.04, with 24.10 (or oo) still some time ahead.
If you read the source Michael wrote about, it states
This may mean providing an optional Wayland session for 24.04 LTS, just to “get the ball rolling,” but we are unsure exactly what this looks like yet. It will be optional for 24.04 LTS but default for 24.10.
We state “we are unsure exactly what this looks like yet”, as we’ve been focused on other items (viewable now on our dailies) mentioned in the Michael’s source article.
OK, I’m kind of confused by this response, since other projects have taken many months or years to do the Wayland transition, so I assumed there would be some kind of framework already in development and just needing some polish to be ready for this “optional” usage in 24.04. Is the plan to just swap over to some pre-existing compositor? To go from Wayland being optional to default in six months (24.10) seems quite sudden unless someone already has some solid idea of how the transition is going to work.
Also, for me, I have to struggle through many things I don’t understand in order to implement each of these Wayland methods, so the 4th month of the next year feels like it’s coming up pretty fast. If there’s already an optional Wayland session for LXQt in that release, I’d prefer to have my project working on that Wayland session somehow by the time it’s released, so I don’t have to tell users to fall back to the X11 session.
I’m not a Lubuntu developer, my response was mostly to your language such as “soon”.
We have a number of items we plan to do this cycle; with discussions being held at various times & places (and me not being a developer, does not mean I understand all details), with certain items picked as will be done first (the installer changes are visible now for testing for example) and others still planned for this noble development cycle before feature freeze which is 29 February 2024.
Your confusion is probably an assumption a developer responded; one didn’t.
At present our plans are just that: plans as expressed in the “we are unsure exactly what this looks like yet”. It’s possible our current plans will stumble against currently unforeseen hurdles and we’ll need to amend our current intentions/plans; let alone upstream LXQt & Qt6 changes. We’ve a way to go for noble yet, but the current focus for a reliable Wayland session is still 24.10; a development cycle we’ve not yet started. Our primary focus is this current two year development cycle, which ends with the release of Lubuntu 24.04 LTS which will be using LXQt & X.org by default.
To tie this up, although I still haven’t seen an LXQt Wayland session in the wild (even on Lubuntu 24.10), I realized that I didn’t understand the nature of LXQt and the way that it uses other window managers instead of having one specific window manager of its own, unlike the way GNOME or Plasma or Xfce have their own window managers.
There was no need for me to care about which window manager was being used, as long as it was an X11/Xorg session. With Wayland, there will be a number of different window managers/compositors that will be usable with LXQt, so the keymapper I’m working with just needs to be able to identify which type of Wayland compositor it is and use a window context method specific to that type of compositor.
This means the keymapper project should have things covered, now that I have a method that works on a typical wlroots-based compositor. And in theory it can also handle the kwin_wayland compositor if someone chooses to use that with LXQt, since the keymapper already works with Plasma Wayland sessions.
In other words, I don’t think I will need further input on this thread. But we will have to see what happens when I can test an actual LXQt Wayland session. I’m expecting the labwc Wayland compositor to be the default in most cases, since it’s kind of meant as a Wayland replacement for OpenBox, which is usually the default X11/Xorg window manager used with LXQt.
This is the repo that helped me understand the situation with LXQT and Wayland support: