Brian Thanks, that's great for the log in. What currently happens on the log out and return to GDM - does the AT, if activated at log in re-enliven, or does it return to the GDM default state?
I presume that if AT is launched by GDM, the ATs are killed before the desktop is launched thereby avoiding possible multiple instances of ATs in the desktop session? Ian -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 03 November 2009 21:07 To: [email protected] Cc: [email protected] Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm) Ian: > Can we please clarify how we believe things work at the moment - just so as > we all know where we're starting from. GDM 2.20 and earlier versions supported a "gesture listener" mechanism so that users could launch AT programs on the fly via keybindings or mouse dwell gestures. This was dropped in GDM 2.21 or later, when the GDM code was rewritten. With the new GDM, users need to navigate the a11y menu to enable AT programs, or modify their GDM configuration to specify that AT programs should always be launched. However, this is a problem for some users with disabilities since there is a chicken and egg problem. Users may not be able to navigate through the a11y dialog without AT programs already running. Blind users, for example, would need orca running to be able to navigate the GUI at all (unless it is very simple to do via keynav without feedback, but unfortunately the new GDM's a11y dialog is not accessible via keynav at all currently). Ideally it should be possible for users with disabilities to enable needed a11y features without needing someone else to help them set up their system. The reason the "gesture listeners" feature was dropped was because it was decided that this feature should not be GDM specific. Now that the new GDM uses the desktop infrastructure (gnome-settings-daemon, metacity, gnome-session, etc.), it would be better if there were a single infrastructure for launching AT programs via hotkey or mouse dwell gesture that worked in both GDM and the user session. So, it seems to make sense for gnome-settings-daemon to manage this for either GDM or the user session. The two bugs I referenced in my previous email are about this. Neither the old or new GDM "carried over" any AT programs to the user session. So, using either the old or new GDM, users need to separately setup their user session with any AT programs needed. Some users feel that it would be useful if the a11y settings did "carry over", but there are issues (like the ones Willie and I highlighted about the fact that users may want different AT preferences for login versus normal user session navigation). That said, I think the ability to launch programs in either GDM or the user session via hotkey/dwell gestures is a more serious problem that needs solving. Brian > -----Original Message----- > From: [email protected] > [mailto:[email protected]]on Behalf Of Brian > Cameron > Sent: 03 November 2009 17:00 > To: Willie Walker > Cc: Jon McCann; [email protected] > Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm) > > > > Willie/Francesco: > >> Yeah! Thanks for starting this, Franceso. It is highly needed feature >> to improve the out-of-the-box experience for GNOME. If this can be >> achieved, and we can convince distros to turn a11y on for gdm by >> default, we can provide an experience that eliminates the need for the >> user to login, enable a11y, logout, and login again. > > Personally, I think that a more serious problem is fixing > gnome-settings-daemon and control-center to allow AT programs to be > easily launched via hotkey and gestures. Refer here: > > https://bugzilla.gnome.org/show_bug.cgi?id=531595 > https://bugzilla.gnome.org/show_bug.cgi?id=531596 > > The ability to "carry-over" AT programs from the login screen to the > user session is not such a needed feature if the user can easily launch > the AT programs once their session starts. But, for this to work, we > need both keybinding and mouse-gesture mechanisms for launching the > needed AT programs. As stated in the bug report, it would make the > most sense if this framework worked in both GDM and the user session. > This way the same mechanism for launching AT programs in GDM works > for the user session as well. > > Typically users only need to do this sort of boot-strapping on > first-login anyway, since users would typically would configure AT > programs to always launch in their user session on login. So, after > first login, I am not sure the need to "carry over" AT settings even > makes sense. Willie also seemed to express concern about this. > > It would be nice to eliminate some of the bootstrapping by having AT > programs "carry over" to the user session. However, many users will > configure the AT programs to meet their own individual needs. For > example, some users may wish to use onscreen instead of GOK, or vice > versa. Dealing with the complexities of making AT programs "carry over" > while honoring the users personal preferences seems hard to implement > correctly. > > Remember that the login screen has a very simple GUI. Typically users > only need to be able to enter their username and password. So, the > default AT program that gets launched for the login screen may be > sufficient to navigate this screen, but may not be really configured > for the user to navigate their full desktop. In other words, there is > no real guarantee that the AT program (or how they are configured to > work at login time) makes sense for the normal user session. This > also complicates things, I think. > > Note that this topic was discussed before, in 2007. A patch for the > old GDM was written that implemented the feature you are describing. > > https://bugzilla.gnome.org/show_bug.cgi?id=411501 > > However, as you can see from the bug comments, the patch was never > really finished, and some of the design issues were never resolved. > It would probably be good to look over that previous work to see > what was done before, and to check if any of the ideas might be > useful in this effort. > > 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 _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
