GNOME Bugzilla – Bug 350263
AT selection migration to Preferred Applications
Last modified: 2007-05-05 11:15:43 UTC
Currently gnome-at-properties lets the end-user enable/disable a hard coded screen reader and magnifier. This should be changed to combo box selection lists. For Screen Reader there are: None, Orca, LSR, Gnopernicus. For Magnifier there are: None, Gnome-Mag, Metacity, XMCM. For On Screen Keyboard there are: None, GOK, SOK. For Other there are: None, Dasher.
Bug 338425 is a subset.
When I wrote this capplet, there weren't a lot of ATs available. GNOME shipped with the two available, and this was an easy way to start them. If we now have a bunch of ATs, I think we need to decide how to handle them. I can think of a couple approaches here. * Treat ATs like window managers. That is, acknowledge that there are others out there but focus our efforts on making the best integrate well. This dialog is well suited to that approach. * Decide that we can't decide here and just have this dialog turn on A11Y in GNOME. Leave it to the user to decide to install an AT, and have AT's automatically start themselves (as a matter of packaging) automatically when installed. Personally, I like the first approach more. It seems like there's not a huge differentiation in the ATs here -- just quality. Unless there is a legitimate need for multiple magnifiers, we should just stick with one in GNOME.
ATs are like text editors. There are many on the system which have different usability features. One size does not fit all, so the preferred AT should be selectable. Will the Gnome board or the Gnome accessibility project evaluate all ATs for each Gnome release to decide which is the best to include? :-) UNIX/Linux is a multi-user system, globally selecting at install time is not a viable option. What would you do in the case of X-terminals or diskless workstations? I like my original suggestion in comment 1 the best, because it lets the end-user to easily decide which ATs they need. GNOME can pick the default, but users should be able to easily select others which are available.
Rather than hardcoding the list, it makes sense for each AT to be able to register itself for a category. The list would be generated from that information. This could be done in two ways -- one, where only installed ATs register themselves and the list is generated from installed ATs. Another possible mechanism is where there is a list on the internet which is pulled, and points to the appropriate installer. Therefore the user can choose based on an up-to-date list and the appropriate software will be installed if it's not already there.
A GNOME specific registration approach could be easily supported using gconf. The control panel looks at its own gconf path (e.g. /desktop/gnome/accessibility/startup). Under this path, there are additional folders representing the kinds of AT's the config panel knows about (e.g. magnifier, screen reader, on-screen keyboard, other). If the AT wants to be listed in the control panel, it simply creates appropriate keys for itself under the proper category. The keys can contain information like the AT's name, description, install location, etc. The panel can build itself dynamically based on this information (e.g. comboboxes, tabs with list boxes, etc.). The defaults would simply be the ATs that ship with GNOME. This design would enable distros to package additional ATs with little extra work as the ATs themselves would be responsible for registering with the control panel. Additional flexibility can be gained by not specifying strict types of ATs. If the control panel does not specify strict types of ATs, but rather builds a UI off of the names of the folders under its gconf path, then new kinds of assistive techs (e.g. cognitive aids) could register themselves without any changes to the control panel code. This extensibility might trade off usability of the panel if not carefully designed, but it may be worth considering.
I like the suggestion in comment 4 the best, because it lets the end-user easily decide which of the available ATs they need. This is important because a specific AT in a category may work better with a particular mix of applications, or the user may just prefer one set of key mappings over the others. There are problems with the 2 approaches suggested in comment 2. Relying on Gnome or a distribution to determine which ATs are "best" ignores the needs of the users and their set of applications. It also ignores the needs of the developers of those ATs. Deciding that we can't decide and relying on the AT installers to configure themselves to start at startup is very Windows-like, but is a step backward given the current capplet. It also ignores the needs of application developers who want to enable their application for multiple ATs. The differences between ATs in the same category may seem insignificant to someone who doesn't rely on them, but they are important to their users. This includes the subtle differences in hardware/driver compatibility, library dependencies, and ergonomics. And over time, these differences will become greater even as the "quality" of all increases.
Perhaps the overall AT selection/setup is something that should be discussed at the Accessibility meeting at the Boston Summit 2006? http://live.gnome.org/Boston2006/AccessibilitySummit
The consensus at the GNOME Accessibility Summit on 10/08/2006 was to move the gnome-at-properties content (but kill the enable accessibility option) to Preferred Applications as an Accessibility tab similar to the Internet tab. For migration, gnome-at-properties could launch Preferred Applications with the Accessibility tab open. The backend might be to register the ATs via gconf or desktop autostart.
Is there somewhere to discuss the implementation of this, as I'd like to see it done for the next major release. More than happy to get involved with the coding.
I will post a proposal on Monday October 23, 2006.
Okay - thanks. I'm slightly apprehensive about the proposal to put things with the 'Preferred Applications' as to me that doesn imply that the applications are started automatically. Would 'Session' be a more appropriate place?
At the Gnome Accessibility Summit in Cambridge this past Oct 9th, we discussed migrating the configuration found in gnome-at-properties to gnome-default-application-properties under a new "accessibility" tab. Part of the migration is to accomidate the choice from a list of available ATs. I propose we retire the gconf keys in /desktop/gnome/accessibility/startup, then create a new set of keys under /desktop/gnome/accessibility/session. /desktop/gnome/accessibility/session/screen-reader/command <string> /desktop/gnome/accessibility/session/screen-reader/start <boolean> /desktop/gnome/accessibility/session/magnifier/command <string> /desktop/gnome/accessibility/session/magnifier/start <boolean> /desktop/gnome/accessibility/session/onscreen-keyboard/command <string> /desktop/gnome/accessibility/session/onscreen-keyboard/start <boolean> /desktop/gnome/accessibility/session/other_ats [string_list] In gnome-control-center/.../gnome-default-applications.xml we add the list of available ATs. A default screenreader, magnifier, and onscreen keyboard ATs are selected, but the start keys are set to false by default. The defaults are implied for the command line wrapper scripts but not for session startup. When a new AT is installed, the user can enable it with the "custom" feature of gnome-default-application-properties. Change gsm_assistive_technologies_start() in gnome-session's gnome-session/gsm-at-startup.c to start the selected and enabled ATs. Aternatively to coding the execution in gnome-session, instead provide a script called gnome-start-ats and add it to the user's ~/.config/autostart/accessibility.desktop file. It is run for every user for each login, but if the gconf "start" keys are false, then nothing happens. other_ats are always started, because they were explicitly added by the user. [Desktop Entry] Name=No name Encoding=UTF-8 Version=1.0 Exec=gnome-start-ats X-GNOME-Autostart-enabled=true In addition, I propose we provide generic invocation scripts for the user to manually start an AT: gnome-at-screenreader, gnome-at-magnifier, and gnome-at-onscreenkeyboard. These will run the AT configured by gnome-default-application-properties. In this case the "start" key is ignored. There should be no wrappers for other_ats because they don't have an explicit category.
Created attachment 75251 [details] demo gconf setup/usage Attached is a demo of the gconf setup and usage.
Sounds good. Do we have a UI for the configuration dialogue in mind yet? That might be a good place to start fleshing out the details, and I have a vested interest as I don't want to see Dasher put into an 'other' category.
Dasher does not have an alternative competitor to create a category. Unless you want a category of just one item. What would the category name be? I was going to follow the UI design of gnome-default-application-properties
Two reminders: 1) We talked about keeping the Assistive Technology Support menu item under the Accessibility menu. The launcher for this menu item would start the Preferred Applications dialog and immediately show the Assistive Technologies panel in that dialog. Keeping the launcher ensures users can still easily locate the configuration panel for their ATs without knowing that it has been moved to the preffered apps dialog. Are you planning on supporting this idea? I image the gnome-> default-application-properties could take a command line switch stating which panel to show by default when it starts. 2) Someone on this report already hinted that being relegated to the "Other" category is less than desirable. We briefly discussed having the dialog dynamically support whatever categories ATs register themselves under in /desktop/gnome/accessibility/session/. For instance, if Dasher says want to be in the on-screen keyboard category, then it just puts itself and the script to run it in that category. I'm not sure how this fits into your current proposal because I don't fully understand how you plan to use the custom field and the default applications XML file. Do you plan to have comboboxes like the other panels in the dialog? Can an AT register itself to be shown in the combobox? For instance, if Orca is the only screen reader that ships with GNOME, would there even be another option by default in the combobox? Would LSR always be in the custom field?
FYI, I'm working on the implementation.
Created attachment 76514 [details] [review] unworking mockup See the glade file for the dialog prototype.
Created attachment 76570 [details] [review] prototype New "accessibility" tab added with "screen reader" and "magnifier" attributes; however, tab is unmanaged and unseen.
FYI, Preferred Applications applet roadmap from Luca Cavalli. http://mail.gnome.org/archives/gnomecc-list/2006-September/msg00011.html
Created attachment 77349 [details] [review] prototype 20061129 Setting preferred application for screen-reader, magnifier, and onscreen-keyboard. See screen shot referenced below. http://www.cactus.org/~gk4/gnome/prefapps.png
Created attachment 77435 [details] [review] prototype 20061130 Cleaned up the icons a little. See the previously referenced URL to the screen shot. Next, to work on the selectable list of "other assitive technologies".
When the new UI is committed and this bug is closed, please could someone attach a screenshot of the new interface to bug 353085 so the documentation gets updated too? Thanks :)
NOTES: Currently, GNOME's Preferred Applications uses the XML file gnome-default-aplications.xml to categorize and catalog all possible applications. Per the accessibility meeting at the GNOME Summit in Boston, I propose adding to the XML file the new categories screen-readers, magnifiers, onscreen-keyboards, and assistive-technologies. When Preferred Applications is run, then it searches for all the listed "executable"s in the XML to determine if they should be shown in the dialog. Once a screen reader like orca is selected, then that information is saved in gconf field /gnome/desktop/applications/at/screen-reader/exec. During login, /usr/share/gnome/autostart/screen-reader.desktop invokes /usr/bin/gnome-screen-reader which reads the gconf field and execs it if the startup field is set. This is repeated for magnifier, onscreen keyboard, and the other non mutually exclusive ATs. The "other" category could be renamed to something more suitable. If the user never selects a particular AT and/or does not choose to autostart during login, then the user can go to the preferences menu and generically invoke "Screen Reader" which will run the default AT. Otherwise, the user could just run screen-reader at the command line. The point is that there is no longer a need to exhaustively list all of the ATs under the preferences menu. Alternatively, regarding the use of .desktop files. I don't understand how to register all the different ATs using .desktop files instead of gconf. I would think there needs to be a set of gnome APIs to read, write, edit, and search .desktop files.
George, indeed we have it :) http://cvs.gnome.org/viewcvs/gnome-desktop/libgnome-desktop/libgnome/gnome-desktop-item.h?view=markup
Created attachment 77752 [details] [review] prototype 20061205 Adding GtkListStore for the list of other/extra ATs. See the above referenced PNG for a screen shot.
Created attachment 77974 [details] [review] prototype 20061208 Per comments about magnification and other, I have reorganized the categories to be "visual" and "mobility". The "visual" category has the screen readers and magnifiers, and "mobility" has dasher. The code is code complete for the gnome-default-applications-properties portion of this patch. I now need to work on the .desktop file for autostart.
Created attachment 78122 [details] [review] prototype 20061211 Code clean up. I still need to work on autostart.
Created attachment 78440 [details] [review] prototype 20061215 This patch introduces dot desktop files and Makefile.am changes. Once I do a little more testing, then I will ask for a formal code review.
The previous patch is code complete. I'm ready for the maintainer to review. I've summarized the enhancement at: http://live.gnome.org/GAP/ScratchPad/PreferredAppliations
Luca, so does this look ok to you?
Created attachment 79194 [details] [review] changelog patch ChangeLog patch for prototype 20061215.
I have expressed my point of view in a more detailed way on the mailing list[1]. To summarize, if we only need to add visual and mobility categories we can add them to preferred applications, otherwise a dedicated applet will probably fit better. When you apply the patch, please align the ending "}" of the icons[] data structure in gnome-da-capplet.c at line 354 to the others. [1] - http://mail.gnome.org/archives/gnomecc-list/2006-December/msg00020.html
Created attachment 79207 [details] [review] release candidate 20070102 Reformatting of icons[] per previous comment.
Created attachment 79211 [details] [review] release candidate 20070102b Added missing default-applications-accessibility.desktop.in Updated ChangeLog
This patch is code complete as described at: http://live.gnome.org/GAP/ScratchPad/PreferredApplications Waiting for a maintainer to mark as accepted-commit_now.
I've just tried the patch, but unfortunately I get a crash at start up: Backtrace was generated from '/opt/gnome2/libexec/control-center' Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1224141120 (LWP 3288)] 0xb742a20e in __waitpid_nocancel () from /lib/tls/libpthread.so.0
+ Trace 99956
The above crash is because the new gconf fields have not been initialized. The current workaround would be to do the following at the command line: SR=/desktop/gnome/applications/at/visual gconftool-2 --type string --set $SR/exec "orca" gconftool-2 --type bool --set $SR/startup false MAG=/desktop/gnome/applications/at/mobility gconftool-2 --type string --set $MAG/exec "dasher" gconftool-2 --type bool --set $MAG/startup false This will be resolved by bug 387219 listed below.
Crashing because of a missing gconf key is a bug. FWIW, the patch also (re)opens a few memory leaks I've been trying to seal (bug 395212).
Setting the gconf key is done in a different gnome module, so I've created bug 387219 which is now committed. What memory leaks have I reintroduced. Point them out and I will fix them ASAP.
(In reply to comment #40) > Setting the gconf key is done in a different gnome module, so I've created bug > 387219 which is now committed. It needs to be fixed here as well. Apps should not crash if the schema is not installed. (I know that the current code often doesn't properly check that either, but that's not a good reason not to bother for new code.) > What memory leaks have I reintroduced. Point them out and I will fix them > ASAP. 1) in {visual,mobility}_gconf_changed_cb you do not unref the GConfValue 2) the same is true of the return values from gconf_client_get_string in show_dialog 3) you do not free the {visual,mobility}_ats lists and their respective items 4) in gnome_da_xml_load_xml you do not free the executable name It would probably help whoever is going to apply this to rebase your changes on the patch in bug 395212 since that introduces a new cleanup function among other stuff. BTW, since the code for visual and mobility callbacks is often exactly the same except for one or two lines (and you check whether the calling widget etc. is the correct one anyway) I think it would make sense to condense the callback functions into one in those cases.
Created attachment 80141 [details] [review] release candidate 20070112 Patch updated per comment 41. This patch now depends on 395212.
Some of the leaks I mentioned are still open, namely 2) + the second half of 3)
Jens, George, I'm sorry, but I haven't had the time to look at the patch in these days, I will do my best to look at it during this weekend, so we will be able to close bug #395212 :)
Created attachment 80334 [details] [review] release candidate 20070115 Jens, thanks.
Created attachment 80335 [details] [review] release candidate 20070115b Cleaned up the ChangeLog entry.
Created attachment 80341 [details] [review] release candidate 20070115c attached wrong patch in comment 42.
I have one concern about this, which is that if we deprecate the AT capplet, then it currently looks like we're going to loose the option to enable or disable AT. What is proposed about this feature?
Thomas, there is a "run at start" checkbox to enable and disable visual and mobility ATs. This new accessibility configuration under Preferred Applications will give the end-user better selection of available assistive technologies. http://live.gnome.org/GAP/ScratchPad/PreferredApplications
George, I think Thomas was asking about the checkbox to enable or disable *accessibility* for the desktop.
Thomas, Selecting the hardcoded "screen reader", "magnifier", and "on-screen keyboard" from gnome-at-properties will be retired; however, "enable assistive technologies" will remain. It is envisioned that other accessibility configuration may migrate to gnome-at-properties. http://mail.gnome.org/archives/gnome-accessibility-devel/2007-January/msg00004.html
The latest patch in comment 47 addresses the mem leak concerns I had.
What is the status for acceptance of this patch? Who will make the commit?
This will need release team approval since feature freeze for 2.18 has already passed. I still have concerns about the unresolved issues about what is left on gnome-at-properties. We still want the checkbox to enable and disable accessibility, but there is no point including a dialog that display just one option.
Since we are in feature freeze, I would leave this for 2.20. As soon as we branch (very soon, we want to start 2.20 development ASAP), I will commit this. So let's work on the issues Thomas just pointed out to have everything ready when the 2.20 branching happens.
This is a multi-patch enhancement, and it is partially checked in so accessibility in the desktop is currently broken. We will need to back out 386411 and 387219 to reinstate gnome-session to launch the hard coded assistive technologies. Regarding comment #54, yes the "enable accessibility" checkbox will currently be the only thing in that dialog; however, at the GNOME Summit in Boston the accessibility team discussed adding other options. This work would be done under a different feature. The Ubuntu accessibility team has also expressed a desire to add to that dialog. I predict that it will not be sparse for long.
I'm asking the gnome-session maintainer to back out of the patch for 386411.
Created attachment 85817 [details] [review] release candidate 20070404 for GNOME 2.19 Patch ported to subversion trunk for GNOME 2.19. Patch ready for review. http://live.gnome.org/GAP/ScratchPad/PreferredApplications
I still think that visual_checkbutton_toggled_cb and mobility_checkbutton_toggled_cb shouldn't be separate functions, but otherwise looks ok, code-wise. Shouldn't the patch include bits from configure.in as well, though (for the new *.in files)? In any case, I can't give the go-ahead. Someone else (Luca? Rodrigo?) needs to make that decision. FWIW, I don't like the revised AT capplet from the wiki page much. We should try to find somewhere else to put that lone checkbox that's still needed.
At the GNOME Summit in Boston, the accessibility team wanted to keep the gnome-at-properties dialog with just the one check button for now. They have other plans for it in the future. This patch is only for the accessibility enhancement to the Preferred Applications. Thanks for the feedback.
Created attachment 85867 [details] [review] release candidate 20070405 for GNOME 2.19 Fixed configure.in per Jens.
Luca, could you please have a look?
Rodrigo, I'm sorry, but I have some problems with my ISP and at home and I'm without internet connection, so I have no chance to look at the patch for now.
Rodrigo and Luca, who will approve and commit the latest submitted patch?
control-center maintainers, this patch did not make the 2.19.2 cut off. Are there any questions that I can answer? I'm anxious to get this in, because it did not make it into 2.17. http://live.gnome.org/TwoPointNineteen
After a quick review and run, I've committed this to SVN trunk. There are though some things that need to be done still: * http://www.gnome.org/~rodrigo/default-apps-a11.png -> it seems we are missing an icon there right? * we need a patch to remove these options from the old a11y apps capplet. Or can we remove it now safely?
> * we need a patch to remove these options from the old a11y apps capplet. Or > can we remove it now safely? I think that change (and more) are handled in all the bugs marked blocked by this bug.
Created attachment 86870 [details] [review] Missing desktop.in.in files It appears that the SVN commit for the previous patch did not include the desktop.in.in files, so here is a patch to add them.
Created attachment 86871 [details] [review] better icon use Patch addendum to improve the icons used for accessibility in Preferred Applications.
Rodrigo, thanks for reviewing and committing the patches. Could you look at patch 386413 to depricate in gnome-at-properties what was moved to here? Thanks again.
Patch from #386413 committed, so I guess this can be closed, right?
Yes, please close.
*** Bug 338425 has been marked as a duplicate of this bug. ***