GDM already provides Custom Commands so you can add your own commands to the menu.  However, there is already a bug #443873 that GDM needs a bit of work to allow GUI programs to be launched via these custom commands.  But if someone did this work, then you could do what you want.

Also, GDM already provides gesture listeners so that programs can be launched if you hit special hotkeys.  You can already launch GOK and orca with the keys already in the file.  Why not use this mechanism?  Refer to the accessibility section of the GDM manual at http://www.gnome.org/projects/gdm/docs.html

Thanks Brian for the hint about the Custom Commands. To what menu will they be added? I am afraid that the Custom Commands are added to the Actions menu of the plain login screen, but this menu is not available in Ubuntu (at least for what I can see). 

To answer your last question: The point was to make it more userfriendly and especially make the user know about the Assistive Technology by only looking at the login screen. 

Custom Commands do get added to the Actions menu.  This should be available in gdmlogin all the time, and in gdmgreeter if the theme has an Options/Actions button.  Users can also hit F10 in gdmgreeter to see the menu.

If you want the program to be run all the time, try setting BackgroundProgram, it's intended to allow you to run an additional GUI program along with the greeter.

If someone wanted to make a simple on-screen keyboard directly integrated with GDM and able to turn it on/off via a configuration option, I'd accept a patch to allow this.  It would be handy if GDM had it's own on-screen keyboard directly integrated into GDM so that users didn't have to use GOK.

Thanks again for your reply. As I am not able to make the Actions menu appear, I wonder whether the version of gdm available in Ubuntu has been compiled with the RBAC support. Is there a way to check the compilation options used? 

Concerning the integrated onscreen keyboard to gdm: Ubuntu ships with 2 onscreen keyboards: gok and onboard (formerly called sok). onboard is written in python and I wonder whether it could be a candidate for integration. Maybe some developer could be interested. Here is onboard's page on launchpad: 
https://launchpad.net/onboard

What version of GDM are you using.  You can run "gdmflexiserver --command=VERSION" to find out.

Are you saying you can't see the Actions menu appear at all when you hit F10, or you can't see commands you've defined as custom commands in the configuration?

RBAC support is Sun only, and shouldn't be available on other platforms.  You can set the RBACSystemCommandKeys to NULL if you want to make sure it isn't bein gused.

You should also make sure that SystemCommadnsInMenu has HALT;REBOOT;SUSPEND;CUSTOM_CMD as its value.

Yes, I don't see the Actions menu at all. But there is a Disconnect menu (it would be better to call it item, because it does not open a menu, but closes the window with the connection to gdm). Could it be due to the fact that I am connecting remotely to gdm (by using NX from nomachine.com)? 

If it is not due to the remote connection, I am going to attach a few screenshots to this thread. 

By the way, I am using GDM 2.19.5. 

Ah, right.  Thanks for clarifying.  At the moment Custom Commands are considered to be "System Commands".  System Commands are typically things like Shutdown, Suspend, Reboot, and Configure GDM.  In other words, things you don't want to have available to remote users.  The light on-screen-keyboard you are talking about would be appropriate for XDMCP sessions, so with the current code Custom Commands doesn't do what you want.

Options therefore include:

- Enhance custom commands to allow you to add commands that are always 
  available and not affected by the SystemMenu configuration option.
- Have you tried using a gesture listener?  Try editing 
  /etc/X11/gdm/modules/AccessKeyMouseEvents and add a key gesture for 
  launching your program.  Perhaps include a --geometry argument to control
  where it appears on the screen.  Then when users hit a special key, it
  will launch the program for them.
- If you want it to always run for all users, then try setting the
  BackgroundProgram configuration option.  This probalby also should include
  a --geometry argument.

If you want to integrate the light on-screen-keyboard in a better way, lets discuss how you would like this to work and how you imagine it would be configured in the GDM configuration file to turn on this feature.

The base idea is the following: add an item to the login screen 
- so that the user sees that the onscreen keyboard, dwelling, or more generally assistive technology is available
- that the user can use to start the assistive technology that he needs. 
Of course, this is for the assistive technology in relation to mobility, while visual impairement needs probably another approach (with voice?). 

The GDM configuration file would offer a key=value pair to turn(hide) on/off the item providing the assistive technology, but it should be available by default. 


Providing a clickable menu to start the onboard would be a first step hopefuly not requiring much work to make it available.

 

By the way, there is a GoSC for ubuntu called mousetweaks under development to bring systemwide dwell clicking (among others) to ubuntu. This might also be a candidate to enhance the accessibility of gdm. But mousetweaks needs atspi; could this be a problem?



There is a specification called access-gdm on launchpad for Ubuntu. It was tatgeted for feisty and marked "good progress": 
https://blueprints.launchpad.net/ubuntu/+spec/access-gdm
I am trying to figure out, what happened to it. Do you know anything about it? 

When you say GDM should offer a boolean to turn/hide the item providing the assistive technology, how does GDM know what programs offer assistive technology?  Is there just one program or separate ones for text-to-speech, magnification, dictation, on-screen-keyboard, etc.?  How is this all controlled by one boolean?

Also, how does GDM present the choices to the user?  Exactly how do you propose that the user see that the assistive technology is available?  With a button or with a menu item?  Explain to me how a blind user would be able to use it.  If it is a menu item or a button, then it would be impossible for a blind user to find it to turn on AT unless AT is already running, right?  A chicken-and-egg problem.

This is why the current approach uses gestures which are keystrokes or mouse movement gestures to start AT programs.  This way a blind user can start AT programs.

You suggest just one on/off boolean to specify if AT presentation is on or off, but you don't really explain how the presentation works or how GDM knows what AT programs are available or how this works for blind users.  Please explain.  I'd appreciate an example of how you expect the configuration file would look like to enable a given AT program.

Or are you suggesting that if the boolean is "on" that this means the AT program associated with the boolean is always running and ready for use?

If so, then are you sure that BackgroundProgram can't be used to meet this need?  If it does meet the need, why do we need new configuration options?

---

Regarding the Ubuntu plans, I hadn't heard about that work before.  Though it doesn't really seem that the page you point me towards discusses much about specific tasks other than a vague "make it work", and have "onboard" integration.  

Some a11y items in the works that probably need help completing include:

   http://bugzilla.gnome.org/show_bug.cgi?id=411501
   http://bugzilla.gnome.org/show_bug.cgi?id=406760

And there are plenty of a11y bugs listed in the GDM bugzilla list that could use help.

Hello Brian; first of all, sorry for the late reply. My previous post was vague on purpose to let room for the actual implementation. 

I am not talking about visual impairment; but only about mobility impairement. And my main objective for the moment is to make the presence of the Assistive Technologies more visible (at least part of it). 

Your suggestion about the custom commands in the Actions menu are a good starting point. Could for example a custom command be used by default in gnome to start the onscreen keyboard. Or is it the policy to let the custom commands empty for the distributions to use? 

The author of onboard (previously called sok) just added parameters to it, to control size and placement of the onscreen keyboard; I call onboard by gestures on my remote connection to the gdm login screen and it seems to work well. Consequently, I suppose that it will also work when called by a custom command. (I also shortly tried gok; it appears, reacts on the mouseinput but no letter appears in the username field; maybe it depends on the parameters with which gok is called.)


Example for AccessDwellMouseEvents:
LLLL I 10000    /usr/bin/onboard --layout /path/to/layout --size 400x150 -x 10 -y 10
(the layout parameter is not necessary when onboard is used locally) 

You can find onboard here: 
https://launchpad.net/onboard

I'm glad to hear that you were able to get things working well with the gesture listeners.  Custom commands to add the option to the Actions menu would require a bit of work.  We'd need to first fix enhancement request #443873, though that shouldn't be too much work.  And we'd probably also want to enhance GDM so that certain defined things can show up in the Actions Menu even if SystemMenu is turned off (or perhaps add a new menu entry item for custom things like this).

I'm also all ears about other ideas on how to enhance GDM to enable better integration for features like this.  Perhaps by enhancing GDM so that programs like this can be on by default rather than needing to complete a gesture to start the program?

Regarding the GOK bugs, I've already filed a bug against GOK against this last Februrary and it doesn't seem to be getting much attention.  Refer to bug #412533.  I think GOK isn't smart enough to know to insert text into the window when the window manager setup is like it is when GDM is running.  If you wanted to look into helping to fix the GOK bugs with GDM, that would be great.  Note that GOK does work better using gdmlogin than gdmgreeter as the GUI program.

*** Bug 467657 has been marked as a duplicate of this bug. ***

Created attachment 94064 [details]
onboard at gdmlogin launched by dwelling

In response to the first paragraph of your preceding answer: I would opt for a new menu detached from the SystemMenu and that would allow the user to launch any kind of application that the user added to that menu. (bug#443873)



What I would also like to see is a spot somewhere on the gdm loginscreen that would launch a command by simply hovering with the mouse over it. This spot could be a button, or rectangle with the words "hover here", or a top menu item; I don't have the knowledge to get concrete because it should be an item that should be available by default in gdmlogin and gdmgreeter. My idea would be to use it to toggle the activation status of a systemwide dwelling function. 

(Am I right: the dwelling feature offered by gdm currently is not a general purpose dwelling, but only a dwelling that checks whether the pointer crosses the edges of the gdmlogin window?) 

Gerd Kohlberger is developing an utility called MouseTweaks under GSoC for Ubuntu to bring (among others) systemwide dwelling to Ubuntu. I just asked him whether he could add cli parsing to it in order to be able to launch it from the cli with dwelling activated. 

Currently, MouseTweaks has the following build-depends: 
debhelper (>= 5), autotools-dev, libgconf2-dev, libgtk2.0-dev, libglade2-dev, libpanel-applet2-dev, libatspi-dev, libdbus-glib-1-dev
Moreover, it presents a window with 4 buttons to the user so that he can specifiy whether the next created click is a single click, double click, drag click or right click. Could it run in gdm, or is there any problem, for example with its dependencies? Gerd also would be interested to know whether it would work in gdm. 

To simplify the compatibility issue: I wonder whether the single click is enough at the login screen!? In this case MouseTweaks could be used without the window to choose click type. 



Once the problem about applications with a gui has been fixed: (This is not a studied listing, but only some ideas) 

- For users using the keyboard: A menu item to open the "Keyboard Accessibility Preferences" window, so that the user can enable the keyboard features that he needs. (Each menuitem should have an underlined letter; this gives the user information about what key to type on the keyboard to open/choose that menu.) 

- For users using only a pointer as input and with the ability to click: a menuitem to open an onscreen keyboard 

- For users using only a pointer as input, but without the ability to click: a visible way to activate dwelling (for example my idea about the <b>visible</b> item to hover over) Once dwelling activated, they have probably have the same abilities as users with an onscreen keyboard able to click.

- For users with only switch input: I don't know; do the switches emulate a mouse? An approach based on gok? 

- For users with visual impairement: This would probably need some specific reflection unrelated to the reflections of mobility impairement as relying on visual clues is not appropriate... 




If AT is mature enough, I don't see why these items (menu, spot) should not be part of the default gdm installation. This does not mean for example that the onscreen keyboard should always be open; but there should be a menu to start it. 

 

Yes, the dwelling feature checks window cross events, and not other kinds of dwell events.  If someone wanted to enhance this module to support other kinds of dwell events, that would be great.  For example, moving the roller ball on your mouse up and down or something.

I would think MouseTweaks should work fine running from GDM.  You wouldn't be linking the MouseTweaks code directly into GDM would you?  If not, then the dependencies don't affect GDM.  If you choose to run programs from GDM, you should make an effort to assure yourselves that these dependencies do not introduce any obvious (or nonobvious) exploits that a malicious user could take 
advantage of.  If you needed to launch MouseTweaks when the GUI is running, then you could add some code to gdmlogin and gdmgreeter to launch the program, but I'd recommend adding a configure check to see if MouseTweaks is on the system and only launching it if it is present.

All of this sounds very do-able.  What I think you want to do is:

1) Create a new menu in gdmlogin if custom commands are defined and have a
   configuration setting which specifies they should be there.
2) In gdmgreeter it has the F10 menu, you probably want to add these commands
   to this menu as well.
3) In gdmgreeter, add an element to the button type in the XML that enables 
   button press on hover.  This can probably be implemented by connecting mouse 
   event listeners and trigger the button press when the mouse hovers over and 
   focus changes.  As I said above, this button type probably needs a new 
   element in the XML for this as well, to specify the custom command to run 
   when the button is pressed.

So I think there needs to be 1 new configuration option in gdm.conf.in to 
control whether the custom commands should appear in this new way.  Then there 
needs to be 2 new elements added to the button XML tag so that these special 
behaviors can be defined there.  This would involve changing code in 
gui/gdmlogin.c, gui/greeter/greeter_parser.c, and the code in the greeter which 
handles the F10 menu.

Well, if we want to add default custom commands, that's okay, but if they depend on other programs (like onscreen), then the configure script should verify that the program is there and only create the custom command if onboard is on the system already.  Or GDM should check at runtime and not display the buttons/menuitems if the specified command is not available.

Also, such programs like onscreen should have gestures defined for libkeymouselistener and libdewllmouselistener.  This way blind users who can't see buttons and menu items can launch programs like orca.  Gesture listeners are
the only way to launch programs for such users, unless you configure GDM to always startup the AT program (then you get in the problem on multi-display about what to do if different users require different programs running, so gestures allow people to choose which AT programs they want running).

If you add some default gestures for starting onscreen, I'll add them to the
default AccessKeyMouseEvents and AccessDwellMouseEvents configuration file 
upstream.  Or better yet, perhaps you could tell configure whether you wanted to use GOK or onscreen, and configure would ensure the right command gets put into the configuration file.  This way the same gestures for on-screen-keyboards work regardless of which one you want to use?  

Just my thoughts.

> - For users using the keyboard: A menu item to open the "Keyboard 
> Accessibility Preferences" window, so that the user can enable the keyboard 
> features that he needs. (Each menuitem should have an underlined letter; this 
> gives the user information about what key to type on the keyboard to 
> open/choose that menu.) 

Such choices should not be present if the underlying command isn't available on
the system.

> - For users using only a pointer as input and with the ability to click: a
> menuitem to open an onscreen keyboard 

We probably need a new menu in gdmlogin, and add a new menuitem to the 
gdmgreeter F10 menu.

> - For users using only a pointer as input, but without the ability to click: a
> visible way to activate dwelling (for example my idea about the <b>visible</b>
> item to hover over) Once dwelling activated, they have probably have the same
> abilities as users with an onscreen keyboard able to click.

Would be possible to do this by adding an element to the button to change the
buttons behavior to work this way.  Then this would be controlled for specific
buttons in the theme.

> - For users with only switch input: I don't know; do the switches emulate a
> mouse? An approach based on gok? 

I think GOK in dwell mode is the best switch solution I know of, unless 
onscreen also supports the ability to type via a button click.  GOK manages
this by cycling through the rows, and when you click it selects the row,
then cycles through the columns, and when you click you select the key.  wouldn't think it would be hard to add this sort of functionality to onscreen.
As long as you can launch it in either mode (mouse or button) via command line
arguments, then you can create two buttons.  And you'ld probably need to use
the existing keymouselistener to cause GOK or onscreen to get launched 
initially since you wouldn't be able to hover your mouse over the "hover over
me" button.

> - For users with visual impairement: This would probably need some specific
> reflection unrelated to the reflections of mobility impairement as relying on
> visual clues is not appropriate... 

GDM does not have high or low contrast themes.  Some distros might, and it sure would be nice if they shared them with everyone else.  :)  Also I think many icons used in GDM do not have high/low contrast ones.  See bug #137367 and #380575

Enhancement request #411501 is a really cool idea to make a11y better in GDM 
and has a patch that isn't really done.

Also bug #363003 should get some more attention.

This should probably be closed because GDM 2.22 has a window allowing users to start accessibility tools and GDM 2.20 is not accepting enhancements.

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.