Re: Flexible multiple AT app configuration

[Henrik Nilsen Omma <henrik ubuntu com>]

Bill Haneman wrote:
> > > Do you think we really need "add" and "remove" buttons here?      
> > The idea was that the user would be able to add their own 
> > applications, perhaps installed directly from a 3rd party. This may 
> > even be proprietary things. From an Ubuntu perspective I don't 
> > actually care much about this as we will package the things we 
> > consider most useful.
> >   
>   I wonder though, isn't the standard add/remove applications dialog 
> sufficient, since it has an Accessibility category already?
I see, we are talking about different things here. When I made the Add 
and Remove buttons I was NOT thinking about adding and removing 
applications from the system itself, just from the list. The main 
purpose was to allow the user to add custom apps to the autostart list.

But I can see how that will cause confusion, not just in discussions but 
for the user too! Adding custom applications can be looked at later. An 
application that is intended for accessibility should really have that 
noted in it's desktop file.

> I think the info will be in the desktop spec file, so the AT config 
> dialog should probably be searching the installed desktop files on 
> startup, to find the available apps in the AT category.

OK, I've looked at the spec and some real-world .desktop files now. It 
seems to do what we need, though we may need to add some extra fields 
such as the command to use for the applications config panel and whether 
it needs AT-SPI.

Following the recommended format that would be:

X-GNOME-Accessibility-UsesATSPI=true

or something like that.

> I guess in some cases it could matter a little bit which app starts 
> first, but 99% of the time it probably does not.  In any case it would 
> only matter during the startup phase itself, it should not make a 
> difference during the rest of the user's session.

OK, so that's a good opportunity to remove two non-essential buttons.

> Yes, 'Universal Access' I think.  It's up to you guys to decide on 
> Ubuntu policy, but I still prefer keeping the apps discoverable from 
> the menus (it's one of my few usability gripes about ubuntu ;-) )

Yeah, I don't have very strong feelings about it myself, but I know 
others on the team feel very strongly about keeping the menu minimal. I 
think the distro team has generally been very good about including AT by 
default, so I'm quite happy to give way on this one.

> Having spent some time thinking about this I am wary of attempting it 
> now.  We definitely need to keep the gconf key as the "master switch" 
> for compatibility reasons, and automagically mucking with settings 
> that the end user might have set is tricky business.  You end up 
> writing ugly warning dialogs that tell the user you are about to 
> change a setting, etc. etc.
> > If we make this the standard utility for deciding what starts 
> > automatically, can we then modify AT-SPI (or whatever is responsible 
> > for starting it) to check the XML file/gconf at startup? 
> No, the session manager (which launches the at-spi-registryd) should 
> just check the gconf key.  I think it would be cleaner to have the AT 
> dialog set and unset the key as before, anyhow.  Currently, apps 
> either check the gconf key directly (gnome_program_init apps, for 
> instance), or rely on $GTK_MODULES, which env variable is set by the 
> session manager when the AT support gconf key is 'true'.
>
> Perhaps the best behavior would be:
>
> 1) if/when a user adds a startup AT which requires AT-SPI, set the AT 
> support gconf key if unset;
> 2) when a user removes all startup ATs which require AT-SPI, post a 
> dialog offering to unset AT support.

I guess that's the least bad of the non-fully-automatic options. I see 
two use cases where this goes wrong though:

1. The user has some custom application that needs AT-SPI that we don't 
know about. He was playing with Orca but decided not to have it 
autostart anymore. When deselecting it he is asked to confirm that 
AT-SPI should also be off by default. The next day (reboot) he tries 
that custom app and discovers that it needs AT-SPI to work properly. 
What is then the right way to turn it on, turn Orca autostart on then 
back off and select 'don't disable' at the prompt? Not elegant.

2. The user uses Orca occasionally but wants to start it manually, not 
at boot. Turning off autostart also suggests turning off AT-SPI, which 
the user doesn't quite know what is, which means Orca has to start it 
next time, and reboot. Not a disaster, but not great.

I'm not sure what the answer is, but there should probably be a way of 
turning AT-SPI on separately. If one of the apps that needs it is set to 
autostart the AT-SPI checkbox could be on and unchangeable. So we are 
back to the Advanced setting button :)


I've made a new mock-up based on these discussions:
http://people.ubuntu.com/~henrik/images/flexi-at-conf-2.png

I've removed the Add and Remove buttons and the autostart checkbox is 
now used without a separate button. The change order buttons have been 
removed also. In this example Orca, Onboard and LSR are installed and 
Orca starts on boot. Dasher (and other items further down) are not 
installed and can not be autostarted.

Henrik