Notices by Matt Campbell (matt@toot.cafe), page 2

@sxpert @drewdevault I presume that if someone really wanted to put in the work, they could create a new stand-alone X server based on the modern KMS/DRM graphics stack, the same one used by Wayland compositors, using Xorg code as a starting point. I think it would be much less work, though, to write a script that starts cage and Xwayland. Then you could invoke that script as if it were a good old X server.

@sxpert If there's so little to be done, then maybe you can do such a good job at it that the distros decide to keep Xorg after all. What I've read, though, is that Xorg doesn't just work, particularly with newer hardware.

@drewdevault

@luis_in_brief @dalias @simon @danilo @maria It would be interesting to see an LLM tuned for instruction-following, particularly iterative instruction following taking prior context into account, that is specifically trained not to emulate a person, e.g. no first-person pronouns.

I'm getting tired of simplistic, indignant characterizations of generative AI like this one: https://social.ericwbailey.website/@eric/111584809768617532 "a spicy autocomplete powered by theft that melts the environment to amplify racism and periodically, arbitrarily lie"

It's a tool like any other; it can be used for good as well as bad. Yes, the copyright issue is real, but we can presumably overcome it by using models whose developers are more scrupulous about their sources of training data, not throwing out the whole thing.

I'll mention again a more balanced take from @danilo that I posted the other day: https://redeem-tomorrow.com/the-average-ai-criticism-has-gotten-lazy-and-thats-dangerous

I also like @simon's writing on generative AI.

I like this post from @danilo which addresses some lazy criticisms of generative AI while also discussing several legitimate criticisms: https://redeem-tomorrow.com/the-average-ai-criticism-has-gotten-lazy-and-thats-dangerous

If the only legitimate use of that setting is for that specific Vietnamese input utility, then I have a proposal for a different solution to that specific problem, which eliminates the setting, since it's too easy to turn off the setting without knowing what one is doing and break other things. But I want to collect more information about possible other uses of that setting before proposing my own solution.

Question for NVDA users: In the keyboard section of settings, there's a checkbox called "Handle keys from other applications". This setting is enabled by default. If it's disabled, it prevents remote access tools from working well with NVDA on the remote target machine. But this isn't clear to someone just looking through the settings. The setting was added due to an issue with a specific Vietnamese input utility. Does anyone have any other reason to turn it off?

Thanks to my foray into GNOME history yesterday, I'm thinking about this NVDA setting in light of a classic article by a GNOME developer on the cost of preferences: https://ometer.com/preferences.html

Came across this article on the decline of usability which, among other things, puts GNOME 3 in the same category as the notorious Windows 8. https://datagubbe.se/usab2/

I know that classic Mac/Windows conventions like menu bars and title bars aren't sacred forever. But this article does make a convincing case that the industry at large, including GNOME, has gone backward. And, at least for me, that's uncomfortable to contemplate.

Yesterday I boosted someone else's announcement of my post on the new GNOME accessibility blog, but apparently some folks couldn't find the link in that toot, so here it is again: https://blogs.gnome.org/a11y/2023/10/27/a-new-accessibility-architecture-for-modern-free-desktops/

Also wanted to add: I'm glad to be getting back to work on accessibility on desktop Linux, after ~20 years away. Hopefully with the experience I've gained in the meantime, my efforts now will be more effective.

@simon An LLM would certainly be more knowledgeable; the only question is whether an LLM-based agent can be coaxed into forwarding the issue to someone who can do something.

Disclaimer: I'm thinking out loud here, not announcing that I have the definitive answer.

On Windows, what we often call the self-voicing approach is made more practical by the fact that the major third-party screen readers offer APIs for sending text strings to the screen reader to be spoken and/or shown on a Braille display, so applications that take this approach don't have to use their own text-to-speech engine. None of the platform-provided screen readers offer something like this though, even on Windows.

Someone looking at GUI accessibility without knowledge of the current solutions would probably conclude that the obvious way to make a GUI accessible is for the GUI toolkit itself to support alternative input and output methods. For example, the GUI toolkit could directly render the text to be spoken or shown on a Braille display. And in fact, for the most part, the games that have been made accessible to blind people have implemented accessibility this way.

I've wondered lately if it would be good to double down on the self-voicing (or more generically, self-outputting?) approach. The current Windows "screen reader APIs" (that's what we call them), including the one I developed myself 10+ years ago, are too simplistic; they don't allow the application to be called back when a speech utterance is complete or when a button is pressed on a Braille display, and they don't allow applications to take over screen reader keyboard commands.

I've often thought that the current mainstream approach to accessibility, i.e. accessibility APIs and external assistive technologies, is an unequal approach to UI. GUI toolkits and applications have full control and responsibility for the visual UI, but for other modalities, the toolkit or application exposes a generic representation of the UI and leaves the details to an external assistive technology.

Lately, though, it has occurred to me that the true "Handmade" response to GUI accessibility might be that the current approach, as implemented by the platform accessibility APIs and current assistive technologies, is misguided, and that something like AccessKit is merely trying to mask the current complexity rather than eliminate it. I'm reminded of another post by Ryan Fleury: https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator particularly the section "An Alternative Approach: Change The Problem’s Nature"

Interesting post about the "Handmade" programming community: https://www.rfleury.com/p/the-marketplace-of-ideals

Unfortunately, the author isn't on the fediverse, or I'd mention him.

I'm ambivalent about the Handmade ideal. On the one hand, their frustration with the state of modern software, expressed somewhat in the previously linked article and at length in the original Handmade Manifesto (https://web.archive.org/web/20160408150158/https://handmade.network/manifesto), resonates with me.