From: Sven Herzberg <[email protected]> > 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 ([email protected]) _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
