Re: [g-a-devel] The atk bridge, and a location to place the atk-bridge shared object.

[Piñeiro <apinheiro igalia com>]

From: Luke Yelavich <themuso ubuntu com>

> Hi all,
> Since we now have more than one toolkit other than GTK making use of atk for accessibility, I think its time we revisit the discussion about a location for the atk bridge shared object, i.e other than the GTK module directory. From skimming through the mail from this list, this was previously discussed, without a concensus reached. Perhaps if a proposal is offered, it could then be improved upon/discussed further, to help reacha concensus much sooner, and thereby be implemented ASAP.

Yes, this is a old discussion. I guess that you read my mail about
this [1], almost one year and a half ago.

> I am still learning about the finer details of atk, so please forgive me if my proposal is somewhat lacking in its assessment and consideration of all the pieces in the puzzle. So far as I understand, this is not a complicated issue, therefore it should be relatively simple to solve.

Well, IMHO it is somewhat complex ;) the main complexity is avoid to
interfere with the current working applications and how to get the
placement of the shared module.

> * We still use a shared object, in a similar form to what we have now, except the object doesn't bare any resemblance to gtk in terms of method names.

Right now the only method names resembling gtk are the hooks
gtk_module_init and gtk_module_shutdown *

Anyway, althouh the current atk bridge provides this hooks, it also
provides gnome_accessibility_module_init. This is the one I use on my
patch to load the bridge on gnome-shell [2].

So, although I agree that in order to make the atk-bridge probably all
this references to gtk should be removed, this is not a priority right
now, as we already have a hook with a proper method name.

> * The shared object is placed in $libdir/atk, and called atk-bridge.$platform_shared_object_extension
> * The libatk API is extended to provide methods for locating and managing the bridge.

IMHO, libatk is not the proper place to place or manage the
bridge. Take into account that the bridge is a module provided by
at-spi or at-spi2-atk. I think that ATK should remains as the abstract
interfaces, the way a app expose his accessibility information. The
atk-bridge is the way at-spi communicates with the app. In fact,
remember that on your application you can start to create atk-objects
without the atk-bridge. Ie: to start to add by hand accessibility
information before the bridge is loaded.

In the same way, not sure if this should be provided as a API. I can't
think in any library providing a directory localization using an
API. This seems more like a setting of the library (see below).

> * A new GTK module is created that wraps libatk to load the atk-bridge shared object for the currently running app.

Hmm, this is a good idea to maintain the support with the current
working apps. I guess that we could create a gnome module, or just be
provided by at-spi due "historic reasons".

> Suggestions, criticisms etc, most welcome. As stated, I may have missed something, so if I have, please point it out.

FWIW, right now the patch to load the atk-bridge on gnome-shell [2],
uses a gconf entry to know where the bridge is. On a weekly meeting, I
talked with Mike Gorse, and he was receptive to that. I created a bug
on at-spi2 [3] providing a provisional patch (waiting for
feedback). This patch just exposes the current gtk-located module, so
it still requires to move the module in a common directory, but this
is transparent to the current apps.

Anyway, we can discuss this.

* and a "Gtk" header when you register events, something that should
  be modified IMHO, as it is confusing.

BR

[1] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00019.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=612599
[3] https://bugs.freedesktop.org/show_bug.cgi?id=28580

===
API (apinheiro igalia com)