GNOME.org
 

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


Francesco:


Brian Cameron wrote:

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.
Indeed; this can become so complex that I wonder whether we should not in any case leave the ultimate control to the user about whether to carry over the assistive tools!? At least as a last resort for the user in case the carry over mechanism screws up things that we missed (which can be very probable). 

I think it does make sense for GDM to carry over a11y settings on the
user's first-time login.  However, to do this, we need a reliable method
to know when the user is logging in for the first time.  Since user's
can share the same $HOME directory across multiple machines, this can
be complicated.

What happens, for example, if the user shares the same $HOME directory
across two machines which have different AT tools installed, or two
machines that are running different distros.  Perhaps these sorts of
environments are too complicated to support well, but hopefully whatever
solution we implement does not break things badly in such environments.
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.
The gesture solution supposes the user to be initiated about it. If we succeed to provide a solution that works also for non-initiated users, that would be very. 

I suspect a solution like a MouseTweaks applet being always available
would meet the needs of most users.  If there are use cases that are not
met well by MouseTweaks, then we should identify those and think about
what solutions are needed to provide support for those users.


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.
Good point that the user might miss the checkbox. What about a popup dialog that opens when the user has clicked the "Login Button"? 

That might work better.  However, we need to find the right balance
between providing needed functionality and making the a11y screen too
cumbersome to navigate.
- Of course, the dialog would only pop up if the user activates an assistive tool.
- The dialog could be user specific as GDM already knows the login name of the user.
- The dialog would have a "Don't show this dialog again" option, which should make sense as it can be user specific. Whether the "Don't show again" setting should last forever or only as long as the user does not change anything in the accessibility dialog of GDM is another point to solve. To avoid problems, the latter might be better. 

Yes, if the dialog were only shown if the user launched an AT program in
the login screen, this would probably be not too cumbersome.  If the
dialog has a checkbox that says "Don't show again", then this would also
be good.

GDM should probably also check to see if the user has already configured
that the AT program launched in the login screen be started in their user session. No reason to show the dialog if the user has already 
configured this.


Does GDM not provide hooks for such a dialog?


It probably would not be too hard to add code to GDM to support this
sort of feature.  GDM does provide the PostLogin and PreSession hooks.
The PostLogin script happens after authentication and the PreSession
hook happens before the user session starts.  You can launch GUI's like
zenity from these scripts, and this might meet your need.  Programs
launched from these scripts cause the login process to block until the
GUI exits, which is probably the behavior you want.

However, you need to be careful about doing this from an a11y
perspective. You would need to test to see if any GUI's launched in this manner work well with any AT programs that the user may have 
launched in the GDM login GUI.

For example, it would be a problem if GUI's launched in this manner get
started after the AT programs are shut down.  If the user needed orca to
navigate the login GUI then they would also need it to work with any
GUI's launched from these scripts  You would need to test to see if
using these hooks to launch GUI's work properly.

If not, then there may be the need to add additional hooks to GDM, or to
fix whatever bugs might be causing this to not work properly.


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.
Some intelligence in the carry over mechanism is necessary even if GDM asks the user whether to carry over the assistive tools: imagine a user that tells GDM to carry over the assistive tools and they conflict with another assistive tool that the user has configured to automatically start at the beginning of the GNOME session.
Are we sure that it is possible to make the carry over mechanism foolproof, even in the simpler approach where it is the user that decides about whether to carry over the assistive tools from GDM to the GNOME session? 

I suspect it is not possible to make things foolproof.  However, it is
probably possible to make things work well for users who use the desktop
in typical ways.  Even if the solution is not perfect it should be okay.
We should be careful that any solution is not destructive or make things
work much more badly for any corner-case users.

Brian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]