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

[Piñeiro <apinheiro igalia com>]

From: Sven Herzberg <herzberg sven googlemail com>

> Hi,
> 
> Am Donnerstag, den 18.11.2010, 16:50 +1100 schrieb Luke Yelavich:
>> 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.
> 
> I haven't followed this with much attention, but that other toolkit,
> does it use GTK+'s module interface to load the so?

Clutter based applications like GNOME Shell require to load by hand
atk-bridge. In this case is uses g module code. You can see a patch
here [1]

And not use gtk module interface is the reason is hard to get where
the atk-bridge is. In fact I proposed to export extra information from
the gtk modules [2], but I agree that this was not a long term
solution.

> My recommendation would be to split up the so into a shared libraries
> and one loadable module per toolkit (which would then, be placed into
> the module folders of the corresponding toolkits).

atk-bridge is not a per toolkit module. atk-bridge can be used on Gtk,
or Clutter. In summary in any toolkit implementing ATK. More
information here [3]

But the fact is that for historic reasons it was placed on gtk module
directory (historic reasons == at that moment gtk was the only toolkit
implementing atk). It has sense and mades easier to implement the
atk-bridge loading.

> As long as the at-spi so exports GTK+'s module interface it seems to
> make sense to keep it in GTK+'s module folder, doesn't it?

As I said, atk-bridge is a shared module. It makes sense to keep it on
the GTK+ module folder because this makes really easy for GTK+
applications to load the accessibility modules.

> PS: What is the second toolkit you're talking about? If that one uses
> GTK+'s module API to load at-spi, maybe it makes sense to have that
> toolkit install a symlink from its module folder to the location GTK+'s
> at-spi module would be placed at (or install that symlink when at-spi is
> installed)?

Clutter is the second toolkit that can use atk-bridge. FWIW: at-spi is
the accessibility daemon. You don't load at-spi. atk-bridge is the
module that it is loaded in any application, so at-spi and this
application can communicate using ATK as the common language. qt uses
his own bridge, so qt apps loads the qt-bridge (well right now it
doesn't work) so qt apps could communicate with at-spi.

About the symlink: this could work, but doesn't solve the problem of
non-gtk apps to know where the bridge module is.

BR

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

===
API (apinheiro igalia com)