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

[Piñeiro <apinheiro igalia com>]

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)