Re: [orca-list] "Quit screen reader" is now an unbound command
- From: Luke Yelavich <themuso ubuntu com>
- To: orca-list gnome org
- Subject: Re: [orca-list] "Quit screen reader" is now an unbound command
- Date: Thu, 22 Aug 2013 15:16:44 +1000
On Thu, Aug 22, 2013 at 01:51:26PM EST, Jason White wrote:
A further desirable change along these lines, for a future release, would be
to detect that a braille display supported by BRLTTY is in use, and if so, to
invoke Orca. Of course, one would need to be sure that there is a genuine
braille display connected, and I don't know how effectively Brlapi can be
queried for this information.
My thought is that the presence of a connection to the hardware should be
enough of a justification for enabling the required accessibility support,
Orca included.
I like this idea, however a couple of changes would need to be made to allow this to work properly:
* BrlTTY would have to be extended to run in the user session, this means looking for configs in the user's
home directory, not loading drivers that aren't needed, i.e Linux screen driver, setting up the BrlAPI socket
in a user-specific directory, etc.
* BrlTTY would have to be loaded as part of the user session, regardless of whether a display is present or
not, and use libudev to register itself to be notified about new hardware, check the new hardware, and then
act accordingly if a display is connected. An alternative is to write a GNOME settings daemon plugin to do
the udev monitoring side of things, then load BrlTTY when a display is present, and allow it to take over.
The upshot of this is that the GNOME settings daemon plugin could then twiddle the knobs needed to bring up
Orca, complete with Braille functionality.
Udev rules could launch a process that is meant to be run as a particular user, but there are extra bits
involved with doing that properly, such as making sure the process has access to the relevant pieces of
session specific metadata set up by logind/consolekit, hense the presence of code that runs in the user
session, and uses libudev to be notified of new hardware, and then acting accordingly. This is essentially
how pulse finds new sound hardware, although I could be simplifying things a bit. Udev rules are for
system-wide actions only.
Luke
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]