hello there!
For #linux #audiogame players, this is going to be really good news indeed.
Remember the tolk speech dispatcher proxy I made, the one that used the same way of interfacing with speech dispatcher as nvda2speechd, aka another server binary which hosts the websocket endpoint, and based on what was sent from the windows dll to the websocket, it would do the connections to speech dispatcher? that worked, for a while, and probably people who play games relying on tolk using audiogame manager are still using it, so it works to this day.
However, this solution is janky, I always thought it to be that way, but I didn't know of any alternative at the time, so I accepted this to just be the way things are for now.
Every once in a while, I keep revisiting the idea of trying to make this better, so I went to the wine HQ channel on irc.
After a long stream of messages exchanged with @r in that channel, I learned not only that it's possible to do so, in rust of all things, which I didn't think possible at all, but also that wine has two ways of going about this, winelib and unixlib. The details aren't very important, all that's important is that we can, actually, create a windows dll which interfaces with linux components through wine, even if yes, the connection point is kinda painful and arcane because of the way wine makes you specify things.
That discussion resulted not only in me knowing this stuff, but also in them making a better version of the tolk spd proxy, which doesn't use any third party server binary at all, so you don't have to run any external processes. The code is here:
https://github.com/ArcaneNibble/tolk2spd
There are details on how to build this, or run it from the precompiled artifacts present on the releases page in the readme of the repository, although building it yourself is quite involved.
If this ends up included in audiogame manager, considering that it uses a wine prefix per game, we may not have to include the environment variable whatsoever, because audiogame manager controls the prefix, so the file can be moved in the right place inside there.
The original discussion included this as well, but I was initially asking if something like the mechanisms presented above exist because I was wondering, would it be possible to bridge Microsoft's MSAA or UIA to at-spi? the outcome of the experiment with tolk2spd demonstrates this can be done, although the current way in which things have to be specified would make it really hard, as it already made things relatively cryptic for this project, but this is considered accepted complexity since wine has no other way of going about it. What do people think? would bridged accessibility API's help us?