Continued absurd Linux problems:
If I run in Wayland,
and run Chrome,
my custom .XCompose file is ignored.
Chrome on X11 does not have this problem,
Wayland apps other than Chrome do not have a problem,
if I use default XCompose sequences instead of custom XCompose there is no problem.
It's just this one combination of things.
Checking the Chromium bug tracker I find variations of this bug repeatedly filed, then closed, as far back as 2015 and as recently as 2021, closed as "fixed".
So I'm sitting here trying to figure out how to tell if a particular app is running in Wayland or XWayland.
This is the answer I get off Stack Overflow. I'm thinking… No. No, that's too silly. It can't be the best way.
I keep researching. It's the best way.
You run xeyes.
Wayland has security that keeps windows from knowing about mouse events in other windows. XWayland doesn't.
Xeyes will track your cursor whenever you're over an XWayland window, then stop if you pass over anything else.
@ChartreuseK @mcc I found the thread: https://tech.lgbt/@xogium/110507457689374019
There's a lot of wayland that feels like "X did it badly so let's not do what X did at all". One thing they haven't touched however is a permissions system that allows applications to have privileged access when required.
A lot of current a11y tools depend on being able to have raw UI access across things and they just don't work well.
I wrote this thread if you're interested: https://social.tchncs.de/@jookia/110508352777844481
@[email protected] @[email protected] The short answer is that it's not going: Applications can't manage the clipboard (wlroots lets any application manage it, bypassing all security though!) Applications can't set global hotkeys (sorry OBS users!) Applications can't inject keypresses (sorry password manager auto-type!) Applications can't detect if they're focused (sorry gamers that want pausing on focus change!) Applications can't click things on the screen (sorry automation scripts and screen readers!)
mcc
Morgan Gangwere
Chartreuse
Jookia