RE: Carrying over ATs from GDM to GNOME session (brainstorm)

["Ian Pascoe" <ianpascoe btinternet com>]

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: Brian Cameron Sun COM [mailto:Brian Cameron Sun COM]
Sent: 03 November 2009 21:07
To: ianpascoe btinternet com
Cc: gnome-accessibility-list gnome org
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: gnome-accessibility-list-bounces gnome org
> [mailto:gnome-accessibility-list-bounces gnome org]On Behalf Of Brian
> Cameron
> Sent: 03 November 2009 17:00
> To: Willie Walker
> Cc: Jon McCann; gnome-accessibility-list gnome org
> 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
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list