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

["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?

I just did a couple of google's for this and finally found
http://library.gnome.org/devel/gtk/unstable/gtk-running.html
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?

= > Marcus von Appen has documented "Wrapping ATK" here:
= > http://www.sysfault.org/atk.html.  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.

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.

-Sam


-----Original Message-----
From: Piñeiro [mailto:apinheiro igalia com] 
Sent: Monday, October 05, 2009 3:30 AM
To: Quiring, Sam
Cc: gnome-accessibility-list gnome org
Subject: Re: Can two ATK toolkits cooperate in the same app?

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

> I am working on making a Python application accessible by creating ATK
> objects corresponding to the GUI objects of the application.  The Python
> app is under development and I recently fetched a new version of the
> source and it caused my ATK interface to stop working.  I've tracked it
> down to a single line in the Python app:
>  
> import gtk
>  
> As I mentioned in a previous posting, my implementation of
> add_global_event_listener() in the AtkUtilClass prints the name of the
> event for each listener added.  If I initialize the ATK system:
>  
> before "import gtk":
> 1. The usual list of events is printed
> 2. My AT-SPI clients sees the ATK object with role ATK_ROLE_APPLICATION
> that my ATK code defines.
> 3. The toolkit name (obtained by my AT-SPI client from
> AccessibleApplication_getToolkitName) is "PAPI" - the ATK tookit I'm
> using
>  
> after "import gtk":
> 1. no list of events is printed
> 2. the application object is not mine, it has name "atkapplication.py"
> 3. the toolkit name is "GAIL"

This means that you loaded GAIL. I'm don't know anything about this
new PAPI tookit, but if you want to use it as the root toolkit, you
need to be sure to be loaded after GAIL. So you'll need something
like:

GTK_MODULES=gail:papi:atk-bridge

or just define GTK_MODULES as empty

GTK_MODULES=
and then load the modules by hand.

BTW: if you are just adding the a11y support for a specific
application, with custom widgets, you'll probably don't need to create
a full new module for that. If this application is a GTK application,
you can just define the a11y object, and then redefine the method
gtk_widget_get_accessible in this widget.

> Marcus von Appen has documented "Wrapping ATK" here:
> http://www.sysfault.org/atk.html.  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.

> I forsee a problem when I start trying to interface to Cally, Clutter's
> accessibility implementation.  Sure enough, this is a problem that
> Alejendro Iglesias, the author of Cally, has identified, see
> http://bugzilla.o-hand.com/show_bug.cgi?id=1738).  Cally is a toolkit
> just like GAIL (see page 12 of this PDF:
> http://personales.igalia.com/apinheiro/files/cally_guadec_2009_slides.pd
> f.gz).  If I have a GTK app that is accessible (GAIL, ATK) and I add
> Clutter along with its accessibility (Cally, ATK) to my app, only one of
> Cally or GAIL will successfully connect to ATK.  I do not see a way for
> the two toolkits to cooperate.

One of the top things on my TODO list is just try to check the
cooperation between GAIL and Cally. In the past I implemented the a11y
support for the GtkClutterEmbed widget. This allows me to have a11y
support for a mixed Gtk+Clutter application.

In this case I load Cally, and *then* I loaded GAIL, so was GAIL the
one redefining (wrapping) AtkUtil methods. We can say that in this
case, GAIL is the "chief".

But as I said, and pointed in the presentation that you showed, this
is just a specific environment, and we need to check how to resolve
the other issues.

I still need to push this GtkClutterEmbed a11y support somewhere. But
I prefer to take a look to the whole gtk-clutter stack, now that it is
updatd, to see how to do that.

I tried to explain my concerns about all this gtk vs cally, and the
problems with only a root toolkit in a past mail [1]

[1] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00028.html

Best regards

===
API (apinheiro igalia com)