Summary: | Allow at-spi2-core files to co-exist with AT-SPI/CORBA | ||
---|---|---|---|
Product: | at-spi2 | Reporter: | Willie Walker <walker.willie> |
Component: | core | Assignee: | Mark Doffman <mark.doffman> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | mark.doffman, mgorse |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 24108 | ||
Attachments: |
Patch
Patch to remove all notions of session management and a *.desktop file |
Description
Willie Walker
2009-09-23 05:43:04 UTC
Created attachment 29801 [details] [review] Patch See also bug #24108 for the at-spi2-atk patch associated with this patch. Created attachment 29983 [details] [review] Patch to remove all notions of session management and a *.desktop file This patch cleans up core, ridding it of any knowledge of session management and a *.desktop file. As intended, the launching of at-spi-registryd now relies upon D-Bus activation. In looking at the GTK+ AT-SPI mechanics some more, there is already magic in gnome-session (gnome-settings-daemon more specifically) and GTK+ that eliminates the need to set the GTK_MODULES environment variable. So, there's really no need for the AT-SPI registry daemon to talk to the session manager now. NOTE - after applying the patch, if you want to build/install at-spi2-core in a way that allows it to co-exist with the CORBA/Bonobo-based at-spi, you can do this: ./{autgen.sh,configure} --prefix=/usr --libexecdir=/opt/atspi-dbus/libexec --disable-xevie This will place most files (e.g., droute, dbind, etc.) under /usr, but will install at-spi-registryd under /opt/atspi-dbus/libexec/at-spi-registryd and make sure the D-Bus service file points to the location of the at-spi-registryd. NOTE: it would be nice to find a way to disable the launching of the CORBA-based at-spi-registryd. Right now it is launched via the /etc/xdg/at-spi-registry*.desktop files based upon the /desktop/gnome/interface/accessibility gconf setting. While having the CORBA-based registry start and not talk to anything doesn't seem so bad, apparently there *might* be an interaction with it and the input device code (e.g., keyboard event interception) that can cause a lock up. So, it would be desirable to not have this the CORBA one launch if we don't want it launched. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.