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

[Brian Cameron <Brian Cameron Sun COM>]

Willie:

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

I think these issues are related, though.

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

It makes 100% sense to me for the setting of
/desktop/gnome/interface/accessibility to carry over to the user
session.  If the user launched an AT program in the login program, then
it would make sense for GDM to just go ahead and set this key for the
user session before starting it, for example.

This would be pretty easy to manage.  Things get more tricky when you
want to try and modify the user's configuration so that specific AT
programs launch or themes get specified.  If we want this to happen,
then we need to be careful to never mess up the user's configuration if
they have set their AT preferences to meet their unique needs.

For example, GDM could automatically set the GConf keys associated with
the Preferences->Assistive Technologies "Preferred Applications" window,
So, for example, if the user launches text-to-speech in GDM, then it
might make sense to also set the "Visual" value to "Orca" and check the
Visaul "Run at start" checkbox before starting the session.

But doing this in a way that you are certain to not mess up the user's
personal configuration may be hard.  Perhaps it would be reasonable to
go ahead and set the GConf values for the text-to-speech case only if
the "Run at start" GConf setting is unchecked.  Or to set the user's
theme only if the user is currently using the system default theme.
On first blush, this seems like it could work, but you really need to be
careful when messing around with the user's preferences like this.

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

Right.  Although, providing keybindings and mouse dwell gestures to set
the a11y theme also seems a reasonable solution to avoid this sort of
setup.

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

Well, it could work one of two ways.

1) The user enters a gesture in GDM.  The values carry over to the user
   session.

2) The user enters a gesture in GDM.  Then after login, the user needs
   to enter the same gesture in the user session.

In both cases, these steps should only be necessary once.  Both GDM and
the user session should remember the settings so that they are used on
subsequent logins.

Obviously solution #1 is nicer.  However, solution #2 is not that much
more cumbersome.  Since, in either case, you need to be able to launch
AT programs via a gesture, it just seems to me that it would make most
sense to enhance the desktop to support launching AT programs via
gestures before solving the problem of carrying over the values from
GDM to the user session.

However, this is a volunteer community, and if volunteers are more
excited to solve problem #2, then there is not any real problem with
addressing that problem first.

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

Although the old GDM supported dwell gestures that involved enter/leave
window boundries, this technique probably does not make sense for a more
general solution that also needs to work in the user session.  The old
GDM solution works well for GDM since we know that on startup that
exactly one window is always present.

For a more general solution, a different dwell gesture, like moving the
mouse to a corner of the screen, or wiggling the cursor in a certain
way, probably makes more sense.

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

If MouseTweaks can solve the problem, that would be awesome.

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

I worry this approach would be prone to error.  Users may not realize
they need to set or unset the checkbox - especially if they launched an
AT program via a keybinding rather than the a11y dialog.

It seems better if this could be managed more in an automatic fashion.
This should be possible, though I wonder if additional GConf keys may
be helpful to help keep track of whether GDM should try to modify
the user's configuration or not.

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

I do not think the environment variable approach is a very good one.  I
just shared that past work for reference.  I think it makes more sense
for GDM to set the user's GConf settings so that things work properly
on login.  The trick is doing this in a way that the user's preferences
never get messed up if the user has actually modified them.

Brian