On Fri, Nov 19, 2010 at 12:06:11AM EST, Piñeiro wrote: > From: Luke Yelavich <[email protected]> > > > 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. _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
