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.
@ChartreuseK @indrora I feel like on commercial desktop OSes it's treated as important to have reader accessibility be implemented at the API level so you can wire through all the way from the application semantic content that isn't well captured by the GUI widget graph
Is that approach even compatible with Wayland's "window manager does it" approach?
@mcc @ChartreuseK No, it isn't. KDE, GNOME, Sway, whatever i3 does, GTK, QT, and whatever bespoke software use, will all be different because Fuck You.
unless the FreeDesktop project steps in and sets down a hammer like they did with desktop notifications and several others, we're going to have a whole mess on our hands.
I'm having whiplash flashbacks to Transmission v GNOME: https://trac.transmissionbt.com/ticket/3685
@mcc @ChartreuseK @indrora AIUI, the accessibility API you get on a linux GUI, at-spi2, offers a tree with applications at the top level, window below that, and then a tree of containers and nodes that can have roles like "has text in it", "the text can be selected, here's the selection", you have support for formatted text as well, scrolling, images, you can simulate inputs or interact with nodes in a more idealised form ("activate" instead of "clicked with mouse button"), all that stuff.
the built-in stuff you get if you just build your program from, say, QT, can be all-right, but if you make custom widgets, and don't test how an at-spi2 client (accerciser lets you inspect and test all this) causes events to happen and just implement stuff based on for example key events, things may just not work in boring or fascinating ways
all that said, i don't think wayland puts a barrier in this very particular piece of a11y. but the vast majority of tools don't use at-spi2 to do their work i'm pretty sure
mcc
Morgan Gangwere
Chartreuse
Timo the timo