GNOME Bugzilla – Bug 619946
It would be useful export _gtk_find_module as a public method
Last modified: 2010-08-12 13:38:59 UTC
gtkmodules.h define some within gtk methods, in order to find and initialize gtkmodules. gtk modules are being loaded during initialization (gtk_init). Some times the gtk modules are required to be loaded manually, as for any reason, it is required to be loaded after gtk_init. In these cases, it is hard to find the path of the gtk modules, or at least in a non-hacky way. This become more important with the imminent gtk-3.0 release, as gtk-2.0 and gtk-3.0 can coexist in the same environment (for this reason ideally this should be a change in gtk-2.0 and gtk-3.0). A way to improve this solution would be being able to call the function _gtk_find_module (right now the header is included in the public headers, but the symbol is not included in gtk.symbols, and the name starts with a underscore). You can check bug 612599 as a example. (I will work in a patch implementing this).
Created attachment 162229 [details] [review] Provisional patch Proposed patch. Some comments: In this case I renamed _gtk_find_module, but not sure if this is the way to implement it, as means a internal API change, and it require changes in other files. Just after finished this quick patch, I'm start to wonder if it would be better to maintain _gtk_find_module, and define a new public method gtk_find_module that would just call it (a wrapper). But this work (in my little tests), so can be the base for any other solution.
Created attachment 162388 [details] [review] Adding a public method without removing the private one It is the same, but without removing the private method. Less files changed, and no internal-GTK+ API change. I know that it is somewhat strange a gtk_find_module that just call a method called _gtk_find_module, but in general I think that this patch is somewhat cleaner. I also added a meaningful description. Missing things: * The "Since " part (X.X right now) as not sure in which release this would appear (if finally accepted). * Proper gtkdoc section, probably in GTK+ Tools section, ala gtk-query-immodules, but I think that it is worth to have it in a different patch (first because they will be independent on which patch, this or the previous one, will be used), work in process.
(In reply to comment #2) > * Proper gtkdoc section, probably in GTK+ Tools section, ala > gtk-query-immodules, After check this, I realized that this is not the proper section to place that, forget this comment.
Created attachment 162395 [details] [review] gtkmodules documentation Added a modules subsection on "GTK+ Core Reference" section and a brief description of the module
Honestly, looking at the bug that you cite, I cannot help but feel that this entire area is a big mess, and that things will not get better if we start exposing parts of the gtkmodules internals like this function. Just look at your patch: You use the function to find the module, and then you duplicate all the module loading code from gtk to load it yourself. This is just not right. The source of all this trouble is the ordering dependency of the a11y modules.
(In reply to comment #5) > Honestly, looking at the bug that you cite, I cannot help but feel that this > entire area is a big mess, and that things will not get better if we start Yes, this entire area is a big mess. But this is not new. Solutions that could be considered hacky as NO_GAIL_ENV and NO_AT_BRIDGE were created to fix thinks like that. Firefox is doing something similar for years, as they are using a different AtkUtil implementation (and also use Gail). After our little conversation on IRC, when I asked you about public this method, Mike Gorse commented that something similar is happening with Mono a11y. > exposing parts of the gtkmodules internals like this function. Just look at > your patch: You use the function to find the module, and then you duplicate all > the module loading code from gtk to load it yourself. This is just not right. The code to load the module is just GModule loading methods, I don't see that really specific, but it is just a opinion. And about opinions, I really think that exposing this method could make the situation better. At least I avoid to copy all the directory-search code, wondering libdir, hardcoding gtk-2.0/gtk-3.0, etc. You can check attachment 161651 [details] [review] to see that the patch was really worse (IMHO), compared with attachment 162467 [details] [review], using the method. In the same way, I don't see any harm making public this method (or other gtkmodules one). But yes, you are right about that this doesn't fix the whole mess. > The source of all this trouble is the ordering dependency of the a11y modules. It is not only about the ordering dependency (although important too). In this case we don't require gail at all, as we are avoiding any mixed gtk-clutter environment. And as today AtkUtil supposes a unique class, we should ensure that gail doesn't override cally AtkUtil implementation. And as GS is calling gtk_init and then cally_init, we need to load atk-bridge after gtk_init, not during it. In fact, technically, we don't need to load any gtk+ module. As I said in an old thread [1] atk-bridge is really general, not gtk-specific (in fact, at-spi2 removed gtk dependency in his last release 0.3.3), and it is in the gtk module directory just for convenience reasons, as you put there the module, and will be loaded without worry about where it is. But in fact it is "just a glib module". In the same way, being so abstracted, is other reason to maintain atk-bridge as a module, as any app using a atk compatible toolkit could try to use it. Although Mark Doffman pointed really interesting ideas in his answer to the thread [2], mainly due problems caused by current AtkUtil API, this would mean a API change really important (ATK-2.0?), something that right now we can't afford due time restraints, manpower, and priorities [3]. Yes, probably right now we are maintaining a whole bunch of little hacks here and there, but solutions like that are the lesser evil right now. Thanks for review the patch. Opinions, ideas and suggestions are welcome. [1] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00019.html [2] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00027.html [3] http://live.gnome.org/Accessibility/GNOME3
(In reply to comment #6) > In fact, technically, we don't need to load any gtk+ module. As I said in an > old thread [1] atk-bridge is really general, not gtk-specific (in fact, at-spi2 > removed gtk dependency in his last release 0.3.3), and it is in the gtk module > directory just for convenience reasons Maybe the right fix then is to move the "real" atk-bridge module somewhere public and well-known (eg, $libdir/at-spi/libatk-bridge.so), but also keep $gtk_modules_dir/libatk-bridge.so as just a tiny wrapper that g_module_opens() the public module, so we can continue to use the GTK_MODULES hack to load it automatically in gtk programs. Maybe the new-and-improved atk-bridge module could even have a better initialization API to fix the needing-to-load-a11y-modules-in-the-right-order problem? (The gtk module wrapper wouldn't make use of that API, but apps like gnome-shell/firefox/mono that were loading it by hand could.)
(In reply to comment #7) > (In reply to comment #6) > > In fact, technically, we don't need to load any gtk+ module. As I said in an > > old thread [1] atk-bridge is really general, not gtk-specific (in fact, at-spi2 > > removed gtk dependency in his last release 0.3.3), and it is in the gtk module > > directory just for convenience reasons > > Maybe the right fix then is to move the "real" atk-bridge module somewhere > public and well-known (eg, $libdir/at-spi/libatk-bridge.so), but also keep As I already suggested almost one year ago [1] ? > $gtk_modules_dir/libatk-bridge.so as just a tiny wrapper that g_module_opens() > the public module, so we can continue to use the GTK_MODULES hack to load it > automatically in gtk programs. although I didn't said anything about it, of course the idea would be maintain the atk bridge in the gtk module directories for legacy reasons. > Maybe the new-and-improved atk-bridge module could even have a better > initialization API to fix the needing-to-load-a11y-modules-in-the-right-order Better module initialization API? Right now the initialization API is just the method called gnome_accessibility_module_init. The initalization of this module makes a lot of common things when you start the a11y support. For example register the application in the at-spi. Right now, in the implementation, when you register a application, it calls atk_util_get_root, in order to have available the application a11y hierarchy. This is the reason you need a correct order. You need to have any a11y implementation toolkit providing a valid AtkUtil implementation, and in the same way being sure that if you have two, the wrong one is not overriding the correct one. So, in any case, it should be something different, changing how atk-bridge internally implements this (lazy approach probably), and probably some changes in the AtkUtil API, as Mark Doffman suggested [2] > problem? (The gtk module wrapper wouldn't make use of that API, but apps like > gnome-shell/firefox/mono that were loading it by hand could.) Anyway, at this moment, have a "common place" directory for the bridge could be a solution. Mike Gorse is included in the CC. Opinions? [1] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00019.html [2] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00027.html
Taking into account comment 5, I have proposed other option in bug 612599 comment 14. So I feel that it would be really unlikely this patch to be applied. Should I close this bug as WONTFIX?
Taking into account negative feedback from comment 5, bug 612599 is being resolved with other solution, and no feedback to comment 9, I will close this bug as WONTFIX. Thanks.