Re: Orca menu placement and setup GUI in Ubuntu

[Henrik Nilsen Omma <henrik ubuntu com>]

Willie Walker wrote:
> It took me a long time to make the mental divide between the
> "Preferences" and "Applications" menus.  I always found it confusing to
> have to hunt for things in one spot and then the other, and then back to
> the other.  So, I think the notion of putting all the a11y stuff under
> one menu structure seems like an interesting idea.  It does mean that
> one will face any pedantic pundits whose goals in life include enforcing
> the rules of "Preferences" vs. "Applications".  :-)
>   

AFAIK, other people like KDE, OSX and to some degree Windows, have it 
somewhere under preferences. If someone is to use one of these tools 
absolutely all the time then it's more natural to consider it a part of 
their desktop than an application, similar to gnome-panel, say. Anyway, 
I don't think that technical point should ever weight in stronger than 
the usability.

> At a higher level, I'm interested in the picture of a11y for the entire
> desktop.  At the Boston 2006 GNOME Summit, we'll be spending an entire
> day focusing on Accessibility, and I think this kind of discussion is
> something that would be good for the Summit:
>   

Yes, that looks very good. I won't be there unfortunately, but hopefully 
there will be some Ubuntu folks around.

> We made the appropriate migration for GNOME 2.16 so that the
> accessibility preferences will launch Orca instead of Gnopernicus.
>   

Right, that change has now trickled down to us as well.

> So...the "traditional" way to launch the screen reader still works.
> However, I think the notion of setting up AT preferences and launching
> them in general needs to be better thought out.
>   

Agreed. I've never liked that traditional way (just the fact that you 
_have_ to log out is bad). In 6.06 we made things slightly worse by 
simply removing the launch menu entries for gnopernicus and gok to 
reduce clutter in the default install and because you could still start 
them in by restarting. Not a great solution, but one of the compromises 
you you need to make on a default minimalistic desktop. It was rather 
last-minute and we intended to revisit it for Edgy.

Things have changed a bit now though because, unlike gnopernicus, Orca 
starts without a GUI element by default, so if we simply move the 'start 
orca' menu entry over to Preferences, we get an application that starts 
up talking (hopefully), but with no information about how to switch it 
off or control it. Btw, I think this is actually a sensible default 
setting because it is what your core users would want, but when 
launching it from a GUI menu it seems to be missing something.

> Insert+Q is what you do to tell Orca to stop.  

Right, but if you start it from the menu you'll never know that. At 
least when you launch it from a terminal you can just close the terminal 
window (or does the daemon keep it alive still?)

> I supposed we (or someone
> in the community :-)) could also add a "--stop" switch to the orca
> launcher to kill orca.  Should be very easy to do.
>   

Sounds like a good place to start.

> We have an HTTP server built into Orca.  

We played a bit with the HTTP server in Wiesbaden. It seems to not work 
very well on Edubuntu (in an LTSP setup), but then that has problems 
with sound as well. I also spoke with Scott who is working on a new init 
system that will take care of things like keeping things alive. Not sure 
if that system will be able to send requests to a running application 
though (but isn't that what things like dbus is for?). -- I've CCed 
Oliver and Scott in case they would care to comment further.

> A shell script could merely
> send an HTTP request to Orca to tell it to show its configuration GUI
> and/or reload the user preferences. This should be easy to do as well.
>   

OK, so the mechanism is there, but I'm still unclear about the 
implementation. We could have 5 menu entries for orca, one for each 
command line option (start with/without GUI, reload prefs, stop orca, 
start magnifier, whatever). But ideally we would want just one that does 
the 'right thing'. Perhaps the answer is to just add some more 
information to the setup that runs the first time you launch orca so 
that the user at least becomes aware of the other modes and commands at 
that time.

> While I kind of cringe at what the true utility of this would be for
> people who cannot read the screen, it seems like it might have some
> utility for people who need to use the magnifier.
>   

Well, this was just one of several possible solutions we could come up 
with. I guess I'm quite GUI-oriented. I think we should step back and 
identify the different use cases here and see if we can find a simple 
solution that will cover them all fairly well (with emphasis on covering 
the needs of core users very well). I can get working on this.

> Our friends at ONCE have started looking into this.  There's some
> refactoring that needs to be done to the Orca guts to enable this
> (they've taken a pass at doing it with Orca 0.2.4), and it's on our list
> of things to get in for Orca V1.0+.
>   

Cool. Some more prominent links to documentation would help as well.

> It's a lot, but it's all good.  :-)  Is Ubuntu willing to roll their
> sleeves up and get dirty with these?  I'd definitely be interested in
> taking a look at patches and answering any questions you may have.   
>   

Not sure we can get into much Orca hacking at this point, but we can 
certainly do some gnome panel stuff. Anyway, I'll start by trying to 
clarify the issues a bit. It may well be that we can do most of it with 
a few shell script and one or two --options in orca.

- Henrik