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). > 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. 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)? 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. > 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 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. 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. 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? 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 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
