GNOME Bugzilla – Bug 139237
gaim non-accessible without manually export 'GTK_MODULES'
Last modified: 2004-12-22 21:47:04 UTC
using gaim 0.75-8 - it should not be necessary to have to manually export an environment variable to enable accessibility in gaim. As part of a stack one would expect accessibility to be enabled out of the box/when gconf key is set. Just like other apps. currently 'export GTK_MODULES="gail:atk-bridge"' has to specified.
Proposed solution: 1) Add support for using gconf to gaim 2) Add code similar to that added to metacity in GNOME 2,4 timeframe to check GConf accessibility key and add required modules. See patch attached to bug #120025.
alternative solution (since this happens with other pure-gtk+ apps) might be to add code to gnome-settings-daemon to export GTK_MODULES when the a11y key is set; this would only effect apps launched from shells that were started after the gconf key was set. I am not sure whether there's a clean way for g-s-d to export this variable to the panel, terminal, nautilus, etc. but it seems plausible. Why is this marked URGENT? it's also not an at-spi bug, strictly speaking, since at-spi has no responsibility for this issue.
Looking at it from an end-user perspective, it is an accessibility blocker. Gaim is not functional without it. There is no documentation or implication to export this variable so the end-user will not be know/be able to do so. It's very well for folk who know what to do, but otherwise I would regard this as an urgent fix..
well, sure, but it's not an at-spi bug. And there is a straightforward workaround, even though it may not be documented well.
moving to 'gnome-desktop' though that's not the right (cvs) module; I suppose we need a meta-gnome-desktop bugzilla category for things like this that aren't bugs against specific components (at least until a technical solution is agreed)
One possible tweak, if we go with a solution which more aggressively sets GTK_MODULES, might be for atk-bridge to check gconf before registering. This would regress a few "test" uses, so we might need a special "A11Y_DEBUG" env variable to override the gconf check. The above gconf check in atk-bridge would reduce the impact of more-aggressively setting the GTK_MODULES environment variables. Since we don't want gail to depend on gconf, we can't really do the same for gail's gmodule. I disagree with "AP0" category since AP0 infers total accessibility blocker, i.e. hangs desktop, blocks entire app, crasher, etc. Moving to AP1.
The suggestion to add code to g-s-d seems to be predicated on the assuption that setting the GTK_MODULES environment variable in that process will cause it to be set for processes subsequently started. This does not seem correct. Could gaim be started by a wrapper that checks the Gconf accessibility key and sets the GTK_MODULES environment variable if not set.
setting the env for the g-s-d process does little, I agree; I was talking about a mechanism whereby g-s-d could set the env for other shells subsequently started. I suppose this really would fall to gnome-session, if it were possible.
Moving it back to a11y until you guys figure out what you're doing. It has nothing to do with gnome-desktop
at-spi is not the correct module, it is not an accessibility "catch-all". The proposals being discussed would require code changes to either g-s-d, gnome-session, or both.
Updating priority and severity to match status whiteboard AP value.
Padraig: since I don't even think at-spi is the correct module, I can't abide by 'critical' severity or even urgent priority for this bug.
This is not a stopper IMO since a workaround exists. It probably merits AP2 however.
I am closing this as NOTGNOME.