I'm not trying to be rude just genuinely curious, and I also don't use a DE, wayland or accessibility, so I have no horse in the game.
So when you write commands you bind them in different way: app specific[1], feature specific[2][3], OS-specific, hecking __programming language specific__[4] etc, and then talon mixes and matches all of that stuff together.
So let's say I have VSCode focused on a javascript file . Talon knows this, and so I have "panel switch" which is a vscode specific command, and "op strict equal" to insert ` === `, but I also have generic text editing commands (because it's an editor), and multi cursor commands (because vscode has been tagged as multi cursor supporting), and tab commands (because vscode is a tab-based editor), and so on and so on.
If I then switched to the browser I would keep the generic text editing commands, and the tab commands, as it supports both of those things, but I would no longer have multi cursor support (or JS commands), because my browser doesn't support that.
This also means you can by and large use the same talon config (and so the same voice commands) on windows, mac and x11.
So for me switching to windows is actually less of a pain because most of the ways I interact with my computer don't actually change, as talon abstracts that away quite a bit.
[1] https://github.com/talonhub/community/blob/main/apps/vscode/... / https://github.com/talonhub/community/blob/main/apps/vscode/...
[2] https://github.com/talonhub/community/blob/main/core/windows...
[3] where vscode gets its features "bound" https://github.com/talonhub/community/blob/main/apps/vscode/...
[4] https://github.com/talonhub/community/blob/main/lang/javascr...
I have solved this by replacing my keyboard with voice commands almost entirely (I don't actually have a keyboard on my desk, but I can reach for my laptop keyboard if I really really have to), and am slowly working on replacing a trackball with an eye tracker (it's kind of headache-inducing though, so it's likely the trackball will stay for a while)
I'm not a medical professional but that sounds like a disability to me.
The odds are pretty good that computer-related RSI is similar to other computer-related RSI. I see no particular need to specify that I'm not talking about tennis elbow when that is already abundantly evident from the context. Most of my comments could include an accurate disclaimer that I'm not talking about tennis elbow, but it wouldn't improve any of them.
Real diseases often have a progression of permanent damage over time and real treatments have positive and negative interactions with other aspects of patient health, cost, and a wide range of outcomes. Commercials especially push a simplistic view that a person has a problem and undergoes a treatment and their problem is resolved. This is as real as crimes being solved in scope of an hour drama or as real if you prefer as people hacking by pounding on the keyboard really fast.
Most users in Developed countries have access to both doctors and the internet and have whatever level of problems they have in spite of pursuing treatment options and probably wont benefit from "one weird trick" to beat RSI.
When I hear accessibility I tend to think of screen readers - magnification or text to speech - for people with low vision.
Only on the internet would someone discuss a change they've made due to a disability, only to have someone else say challenge them on it and imply that they're bullshitting.
Accessibility is customization, and customization is accessibility. They are one and the same.
User control over interfaces is an accessibility feature. At the heart of accessible control schemes is the notion that if a user isn't able to use a traditional control-scheme they should be able to build or hook into something else or customize something that works for them.
This is a big problem with how the Linux community thinks about accessibility. Accessibility is not a separate concern from user agency and control. Accessibility IS user agency and control over a user's interface. It is the ability to take an interface you can't use or that is frustrating or painful to use and to adapt it to your needs.
Accessibility is fully aligned with Linux/GNU philosophy, but we treat it like a separate issue and like it's a chore to support, rather than being a central pillar of how we ought to be approaching software development in general.
----
Here, GP has RSI which means their customization is linked to a traditional physical disability. But to be clear, even if that wasn't the case and even if this just made their life easier and they didn't have a clear, socially accepted disability classification to point to -- customization is still accessibility. Gatekeeping accessibility or asking people to prove that they're fully "disabled" isn't really helpful, we should still be prioritizing making it possible to build things like this. And we should still be treating it like an accessibility concern regardless of whether there's an easily defined disability to point to.
For example[1] it doesn't know if you're using VSCode that you have focused the inbuilt terminal, and so it should now accept terminal commands (eg "cd <whatever>") until you focus back. It knows about the language that you are using because you have configured your text editor to have the file name in the window name, which it can reliably read. This is also how you have website specific configuration.
[1] last I checked! I think there was some work to try to solve this problem, I'm not sure where they got to though, I kind of went down my own configuration fork for a while
I can’t speak much to windows accessibility, although Mouse Keys got me through several rough times in my life where I fried or broke my mouse in some way or another. I do think windows has improved with time, at least by accidentally triggering the screen reading in W10 more times than I’d care to admit
I run the OS that runs the programs I want to use.
Why wouldn't someone ditch an OS for another to keep using the software they want?
Probably because it was a legitimate question out of curiosity with a couple sub-questions, and "why not" is a dismissal rather than an answer.