They did that via an out-of-band D-Bus protocol, rather than going full Wayland. I'm all for keeping D-Bus around for backwards-compatibility (lots of things use AT-SPI2, and I certainly don't want a repeat of the CORBA -> D-Bus migration), but Wayland's AT support should be first-class, not relegated to proprietary GNOME extensions.
Per Matt Campbell's article https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the..., this decision has something to with security:
> Assistive technologies or other accessibility clients currently connect to the compositor through a D-Bus protocol, defined in the Mutter repository linked above. By exposing this interface via D-Bus rather than Wayland, we make it easy to withhold this communication channel from sandboxed applications, which shouldn’t have this level of access.
It's surprising to me that security would prompt the push to D-Bus. Wayland's design with the compsitor as the message bus center was built to center security in the architecture, to make the compositor the arbiter of data flows. I'm struggling to picture what the issue was here with sandboxed applications.
I see far more similar about compositors than different. They have freedom of implementation & do different things, but they offer to apps a very common set of protocols, and some of the newer edgier protocols have more varied adoption. But I see standards & growth & development forward as 'what Wayland is', not "incompatibility" (that's why Wayland proper is purely 100% protocols & not a bespoke impl) and "totally different" (???).
Finding formal concensus to make special stable has been hard. But there is a pleasantly large amount of overlap and interop, even if compositors end up implementing more than one flavor of say gamma control.
> Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible.
When starting a composite yeah, you figure out who has input and send it there. You render the surface the apps give you. Dataflow is inherently quite unidirectional for a long time when beginning a desktop compositor.
But that doesn't feel true at all today. Most compositors support advanced screen sharing, virtual pointers, and other fairly advanced data-flow protocols, almost all built security in mind, requiring more advanced routing & permissioning, as is very visible with the screen share flows of most apps.
> Using something with existing security but the possibility of cross-communication like DBUS is just easier here.
Agreed, but you yourself in your very negative comment on Wayland in this topic seem quite opposed to second systems in broad basis (and pretty radically down on Wayland in general). I'd like to see the display system protocols able to better tackle talking about and managing what's on the screen, rather than building a second parallel system for saying and working with what's on the screen.
I also think there's a decently strong basis already there in the current protocols. There's a security context to start. https://wayland.app/protocols/security-context-v1 We see more advanced flows like XDG Foreign for apps to expose surfaces and mix them onto our own apps.
At-spi d-bus was already right there & done, and it felt easy to keep using it. It was mostly convenience I feel like, and the justification of security feels like a blunt hammer to deny exploration. https://gitlab.gnome.org/GNOME/at-spi2-core/
> The Wayland protocol is an asynchronous object oriented protocol. All requests are method invocations on some object.
Anything D-Bus can do, Wayland can do. (Except systemd integration, but that says more about systemd than about Wayland.)
- Adding hotkeys
- Replacing all my utilities that involve screenshot + OCR
- Making sure Orca works to some extent (low expectations here, but I need some of it to work)
- Reversing the gamma ramp
- Screen magnification
I have mapped out some approaches to most of these, but I full anticipate one or more to be show-stoppers or items I have to attempt to implement from scratch. I'm looking at 100 hours of work, minimum, to make this switch, and am basically just left out in the cold to figure all these workflows out under more hostile circumstances. It's also a chicken and egg, since I need to bootstrap into the new environment without any of my old tools working.
It's great that GNOME is taking some of this seriously, but they're forcing a very difficult transition, and it's frustrating that they think accessibility is in a usable state, or that we're low prioritiy enough to not matter. I'vbe heard the word "edge case" used a lot, it really stinks to be in a category where your entire computer use and professional career are considered an edge case.
It sounds like this actually is supposed to work? At least on GNOME?
Never change a running system.
The fact that only Gnome kind-off supports basic accessibility on wayland already shows what a giant failure wayland is.
(And yes, I'd rather do that than go all in on Wayland)
This is actually surprisingly easy, too. My first experiments ran a wayland app in cage ( https://github.com/cage-kiosk/cage ), but in order to better handle multiple windows I switched to sway with a lightly tweaked config, and other than some input weirdness (I think it struggles with modifiers held while switching focus) it works pretty well.
E.g. you now use the wayland calls instead of x11 calls
Wayland is a dead horse. Made edible by sufficient fermentation and mobile towards the finish line by declaring the rot spreading over the line to be a victory. That Gnome just now gains parts of the functionality it had in X11, years later, while still being actually behind X11, while being an incompatible mess that leaves behind all other desktop environments to the detriment of the Linux ecosystem as a whole isn't actually a victory. Its the victory of the slightly-less-ruined after a devastating war.
You can't fix a protocol that simply isn't designed for how modern graphics hardware works. Both macOS and Windows have upgraded their display stacks over the decades, but it was seamless because unlike Linux, nearly all applications dynamically link the system library which they can upgrade. Linux is late to the party here because everyone wants to make their own toolkit.
X was designed for multiple remote terminals receiving drawing commands over a network, not locally hardware accelerated graphical interfaces and functions that rely on close coordination between the hardware and display server (e.g. hardware planes, vrr, hdr).
Fixing X would require a new protocol to the point that it isn't X anymore, aka Wayland. There are arguments that not having a reference display server has led to problems though.
The advantage is that anything can use the desktop stuff (cli tools) just by talking to dbus instead of having to be a wayland client despite having no windows.
DMA buffers, color management and pixel formats, scaling and DPI, image and video capture, tons of keyboard and mouse related things, all initially forgotten, now incompatible extras that are inconsistently implemented, frequently broken and forever in beta/staging/unsupported hell...
I bet you could benefit from quite a bit of the Wayland compositor work on modernising the lower levels, and end up with something much simpler than current Xorg without ditching much compatibility.
Or am I misunderstanding what you want to do?
This applies perfectly well as a criticism of X11, you know.
In Vim, the digraph is ^K-M.
None of the following are smoking guns, but together... well, either it's GPT or it's https://xkcd.com/810/ .
* Bullet point lists
* emdash
* extensive use of bold
* sentence fragments
* "Here's the good news:"
* juxtaposition over emdash: "This transition is happening — but we’re not being ignored anymore."
* Bullet points that simply MUST have a conclusion " The entire workflow? Gone." , " not just for me, but for every user who deserves to choose how they compute.", "And they shouldn’t have to." , "But we have to start over."
* "I hope it’s done right — not half-baked, not bolted on."
* "We lost an ecosystem."
* "That has to change. / And it starts with every compositor agreeing on what “accessible” actually means. "
etc....
Maybe it's
A) A human who is a very skilled writer with a particular style
B) GPT4.x
but my best guess is
C) Both: Human did the rough draft, then had GPT4 edit it into shape.
Now articles structured this way make me sad. I am not sure if it is acquired distaste, just tiring, or recent articles are indeed worse; either way I am not very happy about them.
Maybe they don't know but some of us love them and have keyboards which have an em-dash/en-dash key or use an OS where they are easy to type.
After looking into it, I think what happened is that a few submissions were flagged by users, for the cromulent reason that the articles weren't very substantive.
https://news.ycombinator.com/item?id=44332956
Edit: There also seems to be an aura of flamedrama around it. I didn't look closely, so I may be wrong, but if that's true, it's another reason why HN users would (cromulently) flag it.
I get that X11 has security issues, but NVIDIA drivers and Wayland still seem to have no support now and no support planned for the future, so Wayland is a non-negotiable non-option for many (most?) Linux desktop users, including myself.
That said, with the custodian of X11 refusing to merge 1000+ patches including various bug fixes and security fixes, I'm excited for the prospect of XLibre - this is exactly what Open Source, as an idea, was invented to facilitate - user choice.
YC moderators are hiding the articles from the front page.
x11libre got 2 active discussions here according to
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
and both got removed from the front page
- https://news.ycombinator.com/item?id=44302650 -- 2 days ago | 80 points | 197 comments -- Long live Xorg, I mean Xlibre
- https://news.ycombinator.com/item?id=44199502 -- 14 days ago | 116 points | 180 comments -- The X.Org Server just got forked (announcing XLibre)
The topic isn't banned. More substantive articles would stand a better chance of not getting flagged, though.
Having seen some of your comments on one of those threads, there's a decent chance your comments contributed to getting those posts flagged.
In this case, I'd have flagged them too if I saw them. The "long live" post is an aggressive tirade that reflects poorly on the author and led to a poor-quality discussion. The second is a link to a git commit history, which is weird in its own right and provides no explanation, and the context provided in the comments shows that a generally dislikable figure with extreme political views is now leading a fork of X11 that has yet to prove itself viable. So I'd probably have flagged that one too as pointless drama until proven otherwise.
Another dev blindly applied his MRs assuming he had tested stuff before submitting the request and they had to go back and revert a bunch of stuff.
Broke nvidia compatibility, broke xrandr extension, and a bunch of other stuff.
The people like OA are spreading misinformation because the developer stated everyone was welcome to contribute and would oppose excessive politics. Keep in mind red hat is currently getting sued 3x over for blatantly racist policies which they used to ban other contributors and forced on their managers, they are evil people.
a fork of X allegedly maintained by an arsehole
> Are they taking Linux desktop accessibility more seriously?
no
> Together we'll make X great again!
This explains the project in a nutshell.
