Re: Loading a11y related modules and atk-bridge module directory

[Piñeiro <apinheiro igalia com>]

From: Mark Doffman <mark doffman codethink co uk>

> I discussed this briefly with regards to Firefox in an a11y conference
> call recently.
> 
> I personally think that the ATK API is broken. (The AtkUtil API in
> particular)
> 
> What happens at the moment is that when an ATK implementation library
> loads it sets its own AtkUtil implementation as the default / standard.
> Li - Is this correct? Its hard to work out as it uses quite an obtuse
> method. (Asking GType for a class with a particular name) The problem is
> that the AtkUtil "getRoot" method ends up being implemented by whatever
> was the last Atk implementation module to load.

Yes this is an additional issue, and in fact more complex that the
"atk-bridge should be on a common place". Atk was designed as a
general and abstract toolkit-indepent library, but thinking with only
a toolkit at time (one example [1]). The problem arises when one
application requires to add a different root, or when there are
several toolkits running at the same moment, and several
atk-implementations tries to give support for them.

In my case the evident case is when you have a mixed environment
Gtk+Clutter, something that seems part of the future in GNOME, and
several developers are working on.

The problem is that we have here several scenarios:
 * Pure Gtk app -> GAIL
 * Pure Clutter app -> Cally
 * Gtk+ + Clutter: -> GAIL + Cally, but:
   * GtkClutterEmbed-> GAIL is the root [2]
   * Clutter app using GtkClutterActor  -> Cally is the root

So in the end, each app should decide which modules and order to use.

> AtkUtil needs to disappear as an interface to be implemented by the
> modules and instead be implemented in Atk iself. There should be an
> AtkUtil method "setRoot (AtkObject *)" that way Firefox could load Atk
> implementations without worrying about order and later set the root
> AtkObject to be of whatever class it chose.

This has sense. Right now there are a implicitly setRoot while you
are loading the specific module:
  g_type_class_unref (g_type_class_ref (GAIL_TYPE_UTIL));

This basically loads the class, and in the gail_util_class_init,
overrides several AtkUtil methods. 

> Similar changes should be made to the AtkUtil events code. The Gail code
> for registering event listeners and dispatching events should be moved
> in to Atk. Gail, and other AtkImplementation libraries should then
> inform Atk of events they feel are pertinent.
> 
> I'm sure there is a-lot more to this than I have found out, but I'm
> certain that what Firefox / Mono / Silverlight are doing to modify the
> order of module loading is a hack. There must be a better way to solve
> this within Atk itself.

Well, I'm sure that you have been investigating this more than me,
and probably you are right. I still have pending implement this on
Cally [3], but at first it seems complex, and I'm not sure if we can
just move that to Atk, as it works from an abstract POV. Although most
of current gail implementation seems general, then we have tricky
issues, like for example the key snooping. Gail implements this using
gtk_key_snooper_install (BTW, something equivalent on Clutter?).

As I said before, I need to review this more on detail, but I'm not
sure if we can just move that to Atk, probably not without modifying
the API as you suggested.


[1] http://library.gnome.org/devel/atk/stable/AtkUtil.html#atk-get-toolkit-name
[2] I have a a11y implementation for GtkClutterEmbed in somewhere, someday I should
    upload this
[3] http://bugzilla.o-hand.com/show_bug.cgi?id=1735

===
API (apinheiro igalia com)