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

[Luke Yelavich <themuso ubuntu com>]

On Fri, Nov 19, 2010 at 12:06:11AM EST, Piñeiro wrote:
> 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.

Yes, thats correct.

> > 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.

I understand that, hense my thoughts about a stub, which you have addressed below.

> > * 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].

Yes, I am aware of those hooks. Since atk is not GTK or even GNOME specific, I thought there may have been a desire to clean up such method names to be desktop independant. if the status quoe is satisfactory, then thats fine too.
> 
> > * 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.

Given your points below about using a gconf/gsettings variable to point to the module, then as long as the ethod to be called is known, then things should be fine.

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

> 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.

Ok, sounds reasonable.

Of course, other thoughts from other aprts of the community are welcome.

Luke

P.S. I'm subscribed to the list, so I respectfully ask that people do not CC me when replying.