Re: Advice requested on deprecating AT-SPI/CORBA



2009/10/21 Willie Walker <William Walker sun com>:
> Hi All:
>
> We're slated to have the AT-SPI/D-Bus stuff in place for 2.29.2.  Things are
> chugging away and looking positive.  I have some questions about some
> approaches we are going to take and would like some opinions and advice for
> how to do it better if your stomach is weakened by the proposed approaches.
>  In other words, speak up now before it's too late. ;-)
>
> One of the goals is to try to keep the AT-SPI/CORBA stuff around for a bit
> so as to let people who depend up AT-SPI for other things to have some
> stability.  The current path is that people would get AT-SPI/D-Bus with
> GNOME 2.29.2 by default, but we'd have an option for people to choose
> AT-SPI/CORBA if they want/need it.
>
> For the most part, we can set things up so there is very little overlap
> between AT-SPI/CORBA and AT-SPI/D-Bus on the file system.  The two main
> overlaps that we are facing are the atk-bridge GTK+ module and the pyatspi
> module.  We also need to deal with *not* always launching the AT-SPI/CORBA
> at-spi-registryd deamon when we know the AT-SPI/D-Bus stuff will be used --
> launching the CORBA and D-Bus based registryd's simultaneously can cause the
> desktop to hang.
>
> Not launching both registryd's at once
> --------------------------------------
>
> The AT-SPI/D-Bus registryd starts/restarts via D-Bus activation, so there's
> no need for it to have a *.desktop file and it will only launch if someone
> tickles it (e.g., via the D-Bus based atk-bridge or pyatspi module).  The
> AT-SPI/CORBA registryd, however, currently starts with an autostart
> *.desktop file,
> /etc/xdg/autostart/at-spi-registryd.desktop, that is keyed off the GNOME
> a11y gconf key, /desktop/gnome/interface/accessibility.
>
> As a potential solution, we can modify the AT-SPI/CORBA *.desktop file to
> key off of a new gconf key, /desktop/gnome/interface/at-spi-corba. The
> existing /desktop/gnome/interface/accessibility key will be used everywhere
> else as normal, but this new key will be used to specify whether the old or
> new infrastructure should be used.
>
> atk-bridge
> -----------
>
> Due to others hardcoding the string "atk-bridge" in their code (e.g.,
> Firefox and OOo), the GTK+ a11y module has to be named "atk-bridge".  We
> could ask Firefox and OOo to not hardcode the name, but we'd end up in a
> versioning hell with external apps not tied to the GNOME release schedule.
>  So, I'd like to make the simplifying assumption that they will not change
> and we need to deal with "atk-bridge".

Can we force them to not hardcode it and yet preserve atk-bridge so
that we can change it in the future if needed? a pkg-config variable
would solve this I'd say.

-- 
Un saludo,
Alberto Ruiz


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