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

[Willie Walker <William Walker Sun COM>]

> 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

This regression is indeed bad.  It's fortunate that the bugs are logged, 
however (and thank you!), and the discussion of this thread can continue 
to focus on carrying over ATs from GDM to GNOME session.

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

An issue which the carry over solution would solve is the very awkward 
method by which a11y needs to be enabled for the desktop.  Unlike gdm, 
which will have a11y enabled by default, the user session has a11y 
disabled by default.  So, if you can get an AT running during an 
inaccessible session, you really need to hope that the AT sets the a11y 
gconf flag and offers you with the ability to log out.

The carry over would help ensure that the a11y gconf flag is set for the 
user if it is needed, making the user session accessible.  Imagine also 
that I needed high contrast large print inverse to log in.  It sure 
seems awkward to have to go through the theme selection process all over 
again once I login.  I think the carry over solution would be a much 
more pleasant out of the box experience.

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

If the carry over feature were in place, I believe the most common place 
one would want to use gestures to launch an AT would be at the login 
screen.  Once a user has logged in, they are likely to configure their 
session so the AT automatically starts when they log in.

The cases where I've seen end users wanting to start an AT from a 
keystroke is for cases where they really want to restart the AT.  For 
example, sometimes the a11y infrastructure hangs or an app hangs or orca 
hangs.  The quickest way to unhang the system can be to restart orca 
because orca clears up a bunch of stuff when it initializes.  So, the 
user can create a custom keystroke to launch Orca via the 
System->Preferences->Keyboard_Shortcuts dialog.

However, I might be missing something, which is the case where a 
gnome-session is *always* running, such as in a public kiosk.  It seems 
to me that the System->Preferences->Keyboard_Shortcuts dialog would 
provide at least some way to set up the AT's to launch via keystrokes. 
That would then leave the non-keyboard related gestures (e.g., the mouse 
enter/leave over boundaries gestures).  I'm not 100% sure, but I think 
one of the more useful ones is the dwell gesture provided by 
MouseTweaks.  So, that can be resolved by putting the MouseTweaks applet 
in the panel and hope/assume that the user has some way of moving the 
mouse when they approach one of these public kiosks.

> Dealing with the complexities of making AT programs "carry over"
> while honoring the users personal preferences seems hard to implement
> correctly.

Francesco's solution of offering a checkbox seems like it might work and 
be rather simple.

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

The work in the bug seems kind of interesting in that the carry over 
mechanism is basically an environment variable.  I think a hard part 
would be to then turn this into something that makes sure the a11y 
settings are set appropriately and as one might expect.  Note also that 
if the AT-SPI infrastructure is needed, the gconf key should be set 
before any GUI operations are done so that the appropriate a11y modules 
can be loaded by GTK+.

I'm curious if some sort of script/app run via an autostart *.desktop 
file during the gnome-session initialization phase might be able to 
perform some logic based upon the presence/absence (and value if 
present) of an environment variable.

Will