GNOME.org
 

Re: Flexible multiple AT app configuration

Henrik Nilsen Omma wrote:

Bill Haneman wrote:

Hi Henrik:

Thanks for doing the mock-up.  I like this idea.
I would suggest adding the 'description' bar (like the one in add/remove applications) to the AT configuration dialog, so the user could see more info about the applications before selecting them for autostart.
That makes sense. We'll be needing an XML file or something (gconf?) for the data anyway so we could easily add a description (unless you think the .desktop files you mention at the end can hold all the info we need). 
I think the file I am referring to is described/discussed here:
http://www.freedesktop.org/wiki/Standards/desktop-entry-spec
It looks to me as though there's enough metadata available in the format to handle our needs.
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?
That raises the question of what happens when the user installs a new application from the repository, say Dasher. In Ubuntu we do not install Dasher by default because we feel that the need is fairly well covered by the on-screen keyboard. Using that you should be able to install Dasher if you want it.
But Dasher is clearly an AT app and so when the user installs it from synaptic I would want it to appear in this dialog automatically, complete with the relevant meta-data. Where is that stored? In the new XML file already, or will we modify the Dasher package to inject this data when it is installed (and remove upon un-install)?
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.
Perhaps the best option would be to have Dasher appear on the list even when not installed, but greyed out. That way we would make even the non-installed packages more discoverable. The XML file would not need to change dynamically because the utility would just check if an AT was installed and show it greyed out if not. Such non-installed items could of course have an install button on it for easy installation.
Getting back to the question: I'd be happy to go without the Add/Remove buttons for now and see if there is a real-world demand. Perhaps hat and a few other things can go under and Advanced button in the future.
Maybe - but you know how much the usability folks love 'Advanced' buttons ;-)
Or would just "configure" and "start", plus the autostart checkbox, be enough?
After making the mock-up and looking at Add Applications again, I now think that the separate button for autostart should be removed and the checkmark for it should be interactive (as in Add Apps)
I presume the up/down arrows are for controlling the order in which the ATs start?
Right. I'm not sure those are really needed though. Does it really matter which start first? Perhaps the ones selected for autostart and the installed ones should just appear above the not-installed ones?
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.
I don't really like the idea of removing the ATs from the applications menu altogether though; I think they should still be discoverable and invokable from a submenu of the Applications menu, and I think many users will have grown to expect them there.
Because we have a few key pieces of AT installed by default in Ubuntu, on every Live CD and HD install we have opted to remove them from the Applications menu (which we try to keep minimalistic -- if everyone got their favourite feature in there it would be a mess). We have other ways of activating them though, from the Live CD boot prompt, from at-prefs (our hack) and we are looking at options for GDM startup. It's fairly we documented on our website and we've not had complaints of poor discoverability.
But, that's just us. Other distros will take a different approach. I'm also happy for the Gnome default behaviour to be that each installed app has an entry in Applications -> Accessibility (or can we call it 'Universal Access'? :) ). When we install something extra in Ubuntu like Dasher that app does get a menu item and we do then spawn an Applications -> Accesibility menu. Users often expect to find newly installed apps in the menu.
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 ;-) )
I would hope that Gnome and other distros would find it reasonable to also have a start button on the AT config dialog we are discussing even though it is slightly redundant. At the least I would ask that we put it in the source code as an ifdef so that the Ubuntu patch can be very simple.
But I really like this dialog as a way of starting the ATs automatically. Should we retain the "AT support" checkbox, or should AT support be somehow implicit, i.e. if you select orca or LSR at startup should the AT support automagically be turned on as well? (If we decide the answer should be 'yes', then we have the question of when to turn it off...)
From a usability POV I think the answer is clearly 'yes' and we should focus on 'how' until that proves impossible.
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.
Each application would have a needs_atspi flag and a start_on_boot flag. It would be a simple matter of searching for an application where both are true and then start AT-SPI.
I think we already have a 'startup' flag/api in gnome-session, so we should reuse that. I can't recall exactly how it works now, though. 

Bill
I think the 'AT' application type can be set/provided in the .desktop files for the apps, so I'd suggest using the .desktop files to find the installed ATs on a system.
Sounds good, though we may need to store some more info about each in a separate register. 

Henrik
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]