Isn't accessibility outside of the scope of Wayland, whose purpose is to composite application buffers, and deliver input events?
Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.
What does this matter for blind people who want to use Linux?
All that matters to them is that it's super complicated and nobody wants to work with the tech to make screen readers work on Wayland.
To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux.
Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.
The standard was Extended Window Manager Hints [0].
Above X11, implemented by GTK and everyone else. Right.
However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new.
You can't even get the title of a window, under Wayland. That's private to that process tree.
Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases.
Parts of AT-SPI are impossible to implement under Wayland.
> Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.
In RHEL I would never touch system python at all, and would install what every version I needed in a venv and configure any software I installed to use what ever version I needed. I learned the hard way to never mess with system python.
Its just the first two results from top of Google.
Maybe the tool was improved in version 3.0, I'm running an older 2.x version. I will check it next time.
The versions were difficult in:
- font size applying
- random loss / reset settings
- there were some issues with the preview when editting
- font preview before selection
etc.
Both of those are from over a year ago? For future, I wouldn't think that's "top" of any discussion.
The strange font sizes and setting reset was mostly fixed as part of the 2020 massive refactor [0]. There are still some minor inconsistencies between the two font editor panels, but they're being worked on.
Thankfully, you shouldn't have any random setting changes since about 2018 build.
The virus-infested computers caused by scam versions of Neopets, are not dissimilar to Windows today.
Live internet popups you didn't ask for, live tracking of everything you do, new buttons suddenly appearing in every toolbar. All of it slowing down your machine.
Stardew Valley. Runs on everything, not just "viable" OSs, made by a single person, and easily competes with an entire genre of gaming to pay the author.
The upper bound of building a business on top of Stardew Valley appears to be https://www.patreon.com/pathoschild which makes under $400 per month after Patreon's cut. That's not enough to work as a single person full time let alone hiring a team.
A $400/mo Patreon does not exactly outweigh somewhere between 18-35 million sales on a single one of the platforms it supports. I would not call that the "upper bound".
That 18-35 million goes to the game's developer and probably not even a single penny goes to those building a business off of designing content on top of the game. That figure is irrelevant.
Taking Fortnite as an example the relevant figure would be that creators on Fortnite can make over $10 million per year. Bringing up that Epic made a few billion dollars is irrelevant to what this conversation is about, which is games where it is financially viable to build content for them.
> which is games where it is financially viable to build content for them.
If that was your interpretation, then it would have been better to have mentioned it anywhere upthread. What we have, so far, is people talking about the gaming industry, and you calling it a monopoly. Nowhere before do we have a mention of third-party developers.
I got tripped up because the parent comment used the term "Fortnite store" when I think they meant "Epic Games Store", so I didn't mention the monopolization that I was talking about was in game monetization upon an existing game.
Wow. I guess Steam must be bankrupt and surviving off just four games. And I guess Epic and Steam just don't compete. And itch and GoG are just irrelevant with no market impact.
Sorry for the sarcasm, but gaming is not "choose between these two" level of monopilisation. And indies just won game of the year awards! Things are just not monopolised.
It also involves around three or four "I know this could be dangerous" click-throughs. That is harder to get an audience of everyday, than settling for paying someone you are probably already paying.
The average person will not click through a security warning. And if they do, they don't know what they're expected to do on that settings page. They are trained _not_ to bypass security.
I meant it should be possible to take a specialized virtual machine that is equivalent to decompressing some compressed bitstream & figure out how to write programs for it that are small but generate large outputs, not that it should be possible to do static analysis & figure out whether the given small program will generate a large output although that is also an interesting problem to solve & would also be an interesting AI benchmark.
No extra software required - uses the standard APIs.
reply