Re: [gdm-list] Bringing back a11y

Hello Ray,

Your question is about the transfer of the AT starting mechanism from
the gdm 2.20 to the new branch.

I would like to use the opportunity to look at the problem from
another point of view:

For example, the people that used the libdwellmouselistener

The comments that I am writing are from a user's point of view.
I am considering mainly mobility impaired users,  because I don't know
much about ATs for other impaired users.

A copy of this will go to the gnome-accessibility-list, in the hope
that people with more knowledge will add their contribution.

My first question: Why not make the presence of Assistive Technology
visible in the greeter for example by providing an Accessibility
menu that contains menuitems for the different ATs offered at login
time. This would at least

Remains to make sure that the people that needs the ATs have the means
to access the Accessibility menu items they need:

- For people that used

passing the active ATs to the gnome session at login and back at logout

At 11:29 AM -0500 2/6/08, Ray Strode wrote:
Hi guys,

So one important regression we need to workout in trunk is making it
fully accessible.

Jon toggled the switch yesterday to make AccessX sticky keys and slow
keys available via the normal shift key mechanisms (hold shift key
down for a long time and get slow keys, tap it several times and get
sticky keys).

One thing we need to move foward though is some solution for what
GtkModulesList did in gdm-2-20.  That key is a list of gtk modules to
run when the greeter is started.

For reference it was set to:


the first two should be handled by gnome-settings-daemon, so they
shouldn't be an issue.  The last two, the dwell mouse listener and the
key mouse listener are sort of special, though.

They are GDM specific gtk modules that watch for key events or mouse
gestures on the greeter window.  When the modules recognize a gesture
or key combo they then launch an AT associated with that gesture or
key combo.

There isn't really any advantage to making these listeners gtk
modules, so it may make sense to rewrite them to just be normal
programs that run at greeter session startup.

If we put desktop files that point to these programs in


then they will get run from within the greeter session.

For the key listener we should watch for events on the root window,
but one complication comes with the gesture listener?  How do we find
which window to watch for gestures on?

I think the answer is to add

"role", "greeter-login-window"


"title", "Login Window"

to the list of construct time properties in gdm_greeter_login_window_new

The listener can then use gdk_screen_get_toplevel_windows to get a
list of windows running in the session, iterate over them, use the
GDK_WINDOW_XWINDOW () macro on the resulting gdk windows to get their
corresponding XIDs and use  XGetProperty to find the window with the
_NET_WM_NAME set to "Login Window" or WM_WINDOW_ROLE set to

And if instead of using the system of window border crossing,
some software capable of recognising mouse gestures independently from
the window that is on the screen? (For example similar to some gesture
recognition offered by addons in browsers?)

Moreover, I would like to use this opportunity to ask whether in addition
to adding the AT starting methods that were available in GNOME 2.20, also
some other, visible methods could be added?

For example, an Accessibility menu could be added to the greeter (or maybe
with a more general name to also draw the attention of tabletpc users) that
would contain the different assistive tools and configurations?

This would represent a new way to start at least some of the ATs for users that
can enter keystrokes or that can use the pointer and click. And this would
especially be interesting for new users. (Not to mention evangelizing: a look
at the greeter and a person immediately sees that it offers ATs; but this is
another topic...)

For people that are not able to click, I would suggest a method provided by
the greeter (for example a dwellable area/icon) to enable mousetweaks, the new
software that was accepted in GNOME 2.22 and that provides systemwide dwelling.
You can see it running here in GDM 2.20	started by a libdwellmouselistener
(The onscreen keyboard is another software not related to mousetweaks.)

Another point that might also deserve some attention is the passing of
the activated ATs to the following gnome session and similar on logout.
I think that the following bug addressed the issue:

As I don't have a good overview of the different Assistive Technologies,
I am also sending a copy of this message to the gnome-accessibility-list in
the hope that people with more knowledge will add their contribution.
(I think that the best is to send all answers to the gdm list where the
discussion started.)

Best regards.


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