GNOME Bugzilla – Bug 556946
gdmsetup does not set a11y gconf key
Last modified: 2008-10-25 10:31:13 UTC
Hello, I am running gdm 2.20.8-0ubuntu3 on the Ubuntu 8.10 development version. When I enable Assistive Technology by using gdmsetup (I don't know whether there is another way to enable it), the gconf key /desktop/gnome/interface/accessibility remains set to FALSE instead of getting the value TRUE. Assistive Technology seems however to work correctly as - I it is possible to start assistive tools by mouse gestures - the assistive tool named mousetweaks, that needs atspi to function, works properly at gdm (We had to disable the gconf key check in the code of mousetweaks, otherwise mousetweaks would not start up as the AT gconf key shows FALSE even if AT is running.) Could anybody please look at the problem, as the Assistive Tools that rely on that key to check whether AT is running will not get the correct information? Please, don't hesitate to contact me if you need additional information. Thanks in advance.
This is not a bug. GDM 2.20 has its own separate configuration. You can turn on a11y in GDM and all GDM GUI programs will run with a11y enabled. However, you will need to separately configure your user session to start whatever accessibility is desired. In the next release of GDM, the plan is to address this issue and use a common gnome-settings-daemon to launch a11y programs the same way in GDM and the normal GNOME user session.
> GDM 2.20 has its own separate configuration. You can turn > on a11y in GDM and all GDM GUI programs will run with a11y enabled. There is at least one Assistive Tool that does not start up: namely mousetweaks. In fact, as mousetweaks requires Assistive Technology, it quiries the /desktop/gnome/interface/accessibility to know whether Assistive Technology is running. If that key says false, mousetweaks does not start up and tells the user to enable Assistive Technology. Should mousetweaks check in a different way whether Assistive Technology is running during GDM? What is the purpose of that key if it does not have to be consistent to the running state of Assistive Technology? I begin to wonder whether this should not be a bug against Assistive Technology.
Note that GDM 2.20 and earlier has its own mechanism for starting a11y. You can read about it in the GDM docs. http://www.gnome.org/projects/gdm/docs/2.20/accessibility.html In summary, you add the gesture to the AccessKeyMouseEvents and/or AccessDwellMouseEvents file and specify the command to launch the AT tool desired. If the AT tool like mousetweaks cannot start up in a GDM environment, then this sounds like a bug in mousetweaks. I'd guess that the problem is that on your system the "gdm" user doesn't have a $HOME directory. If you modify /etc/passwd to specify a writable $HOME directory (perhaps /var/lib/gdm) and you hack the "gdm" user's GConf files to turn on the Assistive Technology bit, then you might be able to get it to work this way. However, it would be better if mousetweaks just checked if the user has a writable $HOME directory. If not, it shouldn't require certain GConf settings. Or perhaps it should accept a --login argument (like GOK does) to know to behave differently when running with the login screen. The reason it probably requires the key to be true is because this is how it knows that the at-spi-registryd daemon is running. However, since GDM always starts the daemon when GDM a11y is turned on, it will be running even if the key isn't true. Note that the new rewrite of GDM requires that the "gdm" user has a writable $HOME directory and depends on GConf. So, this is probably only an issue with the older GDM and not the new GDM. I'm not sure it's really worth the effort to "fix" mousetweaks to work with old versions of GDM. If you figure out how to hack mousetweaks to work with the old GDM, it would be good to share the information in this bug report so others who want to do the same could figure it out as well.
@Brian, Thanks for the explanation. I hope that it will help to find a way to hack mousetweaks to avoid this problem, though we have in the meantime found a work around: As I said before, mousetweaks looks for the /desktop/gnome/interface/accessibility gconf key and if it has the value false (which is for example the case after a fresh install of the current Ubuntu version), it shows the dialog that tells to the user to enable Assistive Technology and provides a button to do so. If the user dismisses the dialog with the "Cancel" button, the dialog box reappears the next time the user tries to launch mousetweaks. However, if the user clicks on the "Enable Assistive Technology" button, the dialog does not appear anymore, and mousetweaks starts as it should; even after a restart of the computer. I suppose this means that in Ubuntu Intrepid, gdm already has a writable $HOME directory!? By the way, would it not be possible for mousetweaks to detect whether it is at the login screen by looking for the username? If it is gdm, it is the login screen, otherwise it is a desktop session.
It is not a good idea to detect whether it is at login screen by username, since the username which is used by the login screen can be configured. A better check might to see if the at-spi-registryd program is already running for the user. If so, then you can assume a11y is available (regardless of whether started by the a11y key or directly by a program like GDM). Perhaps it makes the most sense to just fix mousetweaks to accept a --login argument like GOK which avoids checks that cause problems at login time. Then when GDM launches mousetweaks it can pass this argument. I think the reason your workaround works is because your system probably has a writable $HOME directory for the "gdm" user, so it is actually turning on the key for the user. However, aside from mousetweaks checking it, the key isn't actually used. In a normal session the key is used to start up the at-spi-registryd and make sure programs are started with the right a11y modules. However, since GDM is doing this directory without checking the GConf key, the key isn't really useful at login time.
Adding a --login option to the 2.24.x versions of mousetweaks might not be ideal as it would have repercussions on things that should remain frozen (like documentation). Whether to add --login for 2.25.x and beyond will depend on the solution implemented now by Gerd completely solves the problem. Mousetweaks now only relies on the return value of SPI_init() which returns an error code under several circumstances; and one of these circumstances is at-spi-registryd not running. So mousetweaks does not anymore use the Assistive Technology gconf key and if the current solution with SPI_init() does not have unexpected consequences, we can do without the --login option for mousetweaks 2.25.x and beyond.