Hi all This sounds like a step in the right direction. Just to confirm my understanding, the GDM screen you refer to is the main log in screen? If that is right, then read on!
Apologies for a basic question here, but how can you define a user's particular configuration until that user has logged in? Instead of a per user config file, why not a generic one combined with three different ways of activation on a multi user system - menu, hot key activation say using the standard Orca key bindings of 'Insert' + a n other key, and a logo / button - the first being able to define particular AT programs to be launched on the GDM, whilst the latter two starts a specific group of AT programs. Whilst on a single user system, surely the correct way would be to utilise the existing desktop configs to launch the necessary AT programs automajically without the need for initial interaction? And, apologies if this has already been implemented, but a way to conform the GDM theme and colour scheme to a predefined one - inverse colour for instance with large fonts. Ian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Cameron Sent: 07 February 2008 19:48 To: Francesco Fumanti Cc: Ray Strode; [EMAIL PROTECTED]; [email protected] Subject: Re: [gdm-list] Bringing back a11y Francesco: > Your question is about the transfer of the AT starting mechanism from > the gdm 2.20 to the new branch. > > I would like to use the opportunity to look at the problem from > another point of view: Thanks for bringing this up. I definitely agree that we should think about this, and design a better solution for users who need to launch AT programs. Let's take a step back and review the requirements: - We need the ability to launch AT programs via gestures (key-combinations, mouse button presses, and dwell activities). This is because some users, such as people who are blind or who can only use a switch-button, need some mechanism to launch AT programs in order to interact with the GUI at all. - Commands that get launched need to be configurable since users may need to launch AT programs with special options or use an AT program that might not be integrated into GDM by default. - All functionality in the GUI needs to be keyboard navigable - We need some mechanism to switch to an a11y theme. To support multi-user systems, it would be ideal to allow users to be able to switch to the a11y themes via a hotkey or dwell gesture. Note that the GNOME desktop session has similar problems. There is no way to launch AT programs on-demand in your GNOME session. A person with a11y needs would require that someone configure their system to autolaunch the tools that they need via GConf settings. It would be ideal if there were a common solution to solve this problem for both GDM and the GNOME desktop session. Now that GDM 2.21 is using metacity, perhaps the best long-term solution would be to simply improve metacity so users can define hotkey, button-press and dwell gestures to launch AT programs (or other programs) on-demand. Then this functionality could just be used in both GDM and for the user desktop session. > My first question: Why not make the presence of Assistive Technology > visible in the greeter for example by providing an Accessibility > menu that contains menuitems for the different ATs offered at login > time. I think such a feature would be very helpful. It would help users who are able to navigate the UI to launch AT programs that they need. Ideally, such a solution should be configurable. Users may need to launch AT programs with different arguments or may need to launch AT programs that are not integrated into GDM. So, if a menu or pop-up dialog is shown, users should be able to add new programs to the list of choices via configuration. This is not strictly a requirement if users can also launch AT programs via hotkey and dwell gestures, but it would definitely improve usability for users who are able to navigate the UI without first needing to launch an AT program. >> The listener can then use gdk_screen_get_toplevel_windows to get a >> list of windows running in the session, iterate over them, use the >> GDK_WINDOW_XWINDOW () macro on the resulting gdk windows to get their >> corresponding XIDs and use XGetProperty to find the window with the >> _NET_WM_NAME set to "Login Window" or WM_WINDOW_ROLE set to >> "greeter-login-window". > > And if instead of using the system of window border crossing, > some software capable of recognising mouse gestures independently from > the window that is on the screen? (For example similar to some gesture > recognition offered by addons in browsers?) I agree. The existing dwellmouselistener only supports recognizing events based on window border crossings. While this meets the requirements of a dwell gesture, there are probably better types of dwell gestures that could be supported. There probably should be a usability study to determine what gestures are required and most usable for launching various types of AT programs. Whatever types of dwell gestures we decide to support should likewise be configurable so that users can specify what programs should be launched when gestures are received. > Moreover, I would like to use this opportunity to ask whether in addition > to adding the AT starting methods that were available in GNOME 2.20, also > some other, visible methods could be added? I think this is a very good idea. It probably requires a bit of work to make the mechanism properly configurable, but I am sure that if someone wanted to do the work to add a menu, or pop-up dialog, or whatever that it would make sense to include this in GDM. It might also be handy if this GUI highlighted what key/moustbutton/dwell gestures can be used to launch various AT programs. > For people that are not able to click, I would suggest a method provided by > the greeter (for example a dwellable area/icon) to enable mousetweaks, the new > software that was accepted in GNOME 2.22 and that provides systemwide dwelling. > You can see it running here in GDM 2.20 started by a > libdwellmouselistener > gesture: > https://help.ubuntu.com/community/Accessibility/OnboardAndMousetweaksAtGDM > (The onscreen keyboard is another software not related to mousetweaks.) I think it makes the mose sense to make things configurable. If users want to use onscreen, they should be able to configure GDM to use it. By saying this, I am not suggesting that we don't include onscreen support in the default configuration, but we should not limit the user to only be able to use the tools which are integrated into GDM's default configuration. > Another point that might also deserve some attention is the passing of > the activated ATs to the following gnome session and similar on logout. > I think that the following bug addressed the issue: > http://bugzilla.gnome.org/show_bug.cgi?id=411501 This is a good idea, but there are some difficulties that make this a challange: + The needs of navigating the login screen is fairly trivial, compared with the needs of navigating your GNOME session. So you might want to launch AT programs differently at login time to reflect this. + Also, on multi-user systems the AT programs may be shared by multiple users with different needs. For example, it might make the most sense to launch GOK in "dwell" mode rather than "click" mode at login time, since this is more usable for a wider audience. However, some users might really want "click" mode in their actual GNOME session. So, it probably does not make sense to pass the actual command that GDM uses to the GNOME session. In the above bug report, it was decided that the best way to deal with this could be to pass a label such as "text-to-speech" or "on-screen-keyboard" to the session. This way the user could configure what "text-to-speech" means differently in the GNOME session versus at login time. > As I don't have a good overview of the different Assistive Technologies, > I am also sending a copy of this message to the gnome-accessibility-list in > the hope that people with more knowledge will add their contribution. > (I think that the best is to send all answers to the gdm list where the > discussion started.) As I suggested, I think the best long-term solution would be to find a way to support keybindings and dwell gestures to launch AT programs that works both in the GNOME session and at login time. However, in the meanwhile, it might make the most sense to continue supporting something similar to keymouselistener and dwellmouselistener. These are fairly trivial to port to the new GDM 2.21 and would be immediately useful. Any other design would likely take some release cycles to design and complete. Brian _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
