> 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:apinhe...@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.quir...@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 (apinhe...@igalia.com) _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
