accessibleapps
Orca speech and Braille support added for Linux.
This adds Orca support. It falls back gracefully to speech-dispatcher if there is a problem, e.g. the Orca version isn't new enough, or something is up with dbus.
Hey, I'm curious about the implementation approach here - I noticed this uses subprocess calls to gdbus rather than a Python D-Bus binding like dbus-python or pydbus. Was there a specific reason for going with the subprocess approach? Just wondering about the tradeoffs considered (dependencies, compatibility, etc.).
Also, I noticed in the silence() method that the path becomes self.main_path + "/Speech" - is that accessing a submodule in Orca's D-Bus interface? Just curious about how that part of the API is structured.
The code looks clean and well-documented - just interested in understanding the design choices!
Mostly I didn't want ot have to add more dependencies for dbus. There are python dbus libraries, but you never know which distro will have what package, and how out of date the package might be. Also, this support in Orca is new, and I figured this method is least likely to change in updates to Orca. I could be wrong about that of course. :)
Orca's dbus API is organized hierarchically with different functional areas, speech and Braille, as separate object paths under the main service. This allows for more granular control. In this case, we can specifically target speech interruption through the Speech module's ExecuteCommand method with the InterruptSpeech command, rather than affecting other outputs.
I came back to check on the status of this, and saw my previous reply. I had 2 conversations going on at once, and it looks like although the first paragraph was correct, I answered the wrong question in the second one. I didn't check my current screen as thoroughly as I should have.
It's a dbus thing where paths have a top level generic path and subpaths for more specialized access. In this case the subpath gives more fine grained speech access.
Sorry for the mix up earlier. :)