I’ve made a lot of progress recently with low-level libxul and embedding changes, and I’ve been needing to post about my plans for the gtkmozembed framework: I’ve already made commitments in the roadmap that the gtkmozembed code would be integrated into libxul, but but I never really said what I’m trying to accomplish:
- Define a recommended linking strategy for gtkmozembed: currently many distributions compile Mozilla with -rpath /usr/lib/mozilla-1.7.10 or whatnot, but this is a poor solution because it means that any embedder who uses gtkmozembed (Epiphany etc) is tied to a particular version of Mozilla, and distros have to recompile these apps every time there is a security release of Mozilla.
- Remove the necessity for any special environment variables such as MOZILLA_FIVE_HOME or LD_LIBRARY_PATH: the fact that you can’t set LD_LIBRARY_PATH and have it take effect in the same process is a particularly odious situation for embedders who actually want to use the GRE the way it was intended.
The solution I am going to implement fixes these problem by exporting the gtkmozembed API from within libxul. There won’t be any more “libgtkembedmoz.so” separate from the main libxul library, the symbols will be incorporated directly. This will allow gtkmozembed embedders (such as Epiphany) to link using the XPCOM glue and the new XUL glue functionality (agh, I need to document this on devmo!). They will no longer have to directly link against any of the mozilla libs, and therefore won’t be tied to a particular installation of XULRunner/Mozilla/whathaveyou.
The typical process for bootstrapping a gtkmozembed app will be something like this (in sketch form):
GRE_GetGREWithProperties("gtkmozembed=1"); XPCOMGlueStartup(); XPCOMGlueLoadXULFunctions("all those pesky gtkmozembed APIs"); gtk_moz_embed_set_path(the path from gre_getgre above); // instead of setting MOZILLA_FIVE_HOME, we tell gtkmozembed where we found it Use gtkmozembed APIs the way you always would (no changes to the APIs) When you're done: XPCOMGlueShutdown();
This app will only need to link against libxpcomglue.a… it won’t need to (and shouldn’t) link against libxpcom.so or libxul.so or anything like that.