Re: Can two ATK toolkits cooperate in the same app?

From: "Quiring, Sam" <Sam Quiring windriver com>

> > GTK_MODULES=gail:papi:atk-bridge
> This is a new one on me.  Where is the effect of this
> environment variable documented?  What form would papi
> have to be (.so file?) and where would it have to be
> located in the file system for this to work?

You can found this on the accessibility section in library.gnome [1].

The summary is that GAIL, HAIL, Cally and any other modules that add
a11y support for any UI toolkit (Gtk+, Hildon, Clutter) are supposed
to be loaded optionally, due the overhead. In GNOME they tried to make
it as general as possible, so this was the option to solve that.

GTK_MODULES [2] is just a variable where you put the dynamic modules
that you want to load using GModule, when you call gtk_init. So if you
are using a "pure-gtk" application, use that its enough. And this is
the reason atk-bridge is placed on the gtk directory for modules,
although technically, is not a gtk module [3]. In a mixed environment
it would be more complex [4].

In fact, right now use GTK_MODULES to load this modules in a general
way, has some problems related (see bugs [5][6][7] as some examples).

GTK_MODULES has a set of default directories to search for.

> I just did a couple of google's for this and finally found
> which says GTK_MODULES defines a list of modules to load.
> It does not say which order they are initialized.  Is there
> more definitive documentation?

Ups, just my [2] link ;). The order in which is loaded is left-right,
so with:


You are asking to load GAIL, and then load atk-bridge. And this is the
correct form. If you define it on the reverse, you'll get a crash, as
atk-bridge could call atk_util_get_root, that is not defined until
gail is loaded.

> = > Marcus von Appen has documented "Wrapping ATK" here:
> = >  It looks to me like the first
> = > toolkit to perform this wrapping is the one the app uses.  Is this
> = > limitation documented somewhere?    When my AT-SPI client starts
> = > exploring the accessible object tree rooted at the application object, it
> = > will see either the tree created by GTK or the tree create by PAPI, but
> = > not both.
> =
> = > AFAIK, not the first is the last, as each time a module defining this
> = > methods is loaded, it tries to use their own implementation of this
> = > AtkUtil methods. At least, this should work.
> We may be talking about two different strategies.  I think you
> are referring to the GTK_MODULES= order of loading (and initializing?).
> I am describing the effects of PAPI executing the code describe in
> "Wrapping ATK".  If PAPI wraps ATK after "import GTK" is executed,
> GAIL will be the toolkit, not PAPI.

Hmm, yes I think that you are right. This html shows you how to wrap
the current toolkit. As far as I understand, this means that you can
keep with the normal GTK_MODULES:


I suppose that you import gtk will call gtk_init (sorry I'm not really
used to python apps), so gail will be the one in use.

Then, you need to execute the methods explained in your link, and if
it works, you are providing your own AtkUtil method implementation, so
the toolkit should be PAPI.

> I've tracked through some of the code in the ATK Bridge, and I am pretty
> sure (but could be wrong) the first toolkit to execute
> gnome_accessibility_module_init() is the only toolkit that will work in
> the app.  This is consistent with the evidence I reported in my email.

The first toolkit will redefine the AtkUtil methods. This is a
standalone class. When you load the GailUtil class, it define the
AtkUtil methods, if you call gnome_accessibility_module_init with
other toolkit, this one would redefine this methods, as cally does. In
my attempts with mixed gail-cally it works at least. Anyway is
something that I need to check with detail.

Take a look to the implementation of gail_util_class_init or
cally_util_class_init for more information.


API (apinheiro igalia com)

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