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