I have taken a recent set of XULRunner 1.8.0.1 tinderbox builds for intensive testing candidates before the release of XULRunner 1.8.0.1. Please download and test these builds. See the XULRunner roadmap for details about release schedules and future plans.

Merry Christmas everyone! I will be away on vacation until Jan. 3. I may be checking email early in the week, but don’t count on it. If there’s anything emergency-like, my Mozilla Corporation coworkers have my cell phone number. Blog comments may be moderated until I get back.

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.

The weeks right around Christmas are a hard time to get coding done: many coworkers (both Mozilla employees and others) are on vacation. So I’ve spent a decent amount of time this week working on projects that don’t require extensive collaboration:

XULRunner Roadmap

I’ve put up a new draft of the XULRunner Roadmap and reworked a lot of the XULRunner documentation on wiki.mozilla.org and developer.mozilla.org. I still need to document the -install-app feature and how to run mac application bundles.

Extensions that Require Dependent Libraries

Advanced extensions may depend on external libraries that need to be shipped with the extension. This is hard because Firefox does not automatically load any dependent libraries when loading XPCOM components. I’ve written up an article on using dependent libraries in extension components. This should also work for loading dependent libraries in XULRunner components…

Stop exporting nonfrozen symbols from libxul

Bug 305949 and its blockers: this is almost done, and once it is done I can tackle the “build Firefox on XULRunner” problem in earnest.

If you haven’t heard the buzz, Songbird is making a splash as an open-source media player and is using XULRunner to drive its user interface! I got a chance to meet the Songbird development team and get a sneak preview of their app; I’m excited that XULRunner is able to make rapid application development of great new apps possible.

I have updated the Locale-Switcher extension for Firefox and Thunderbird 1.5. It is available on my website, and I have submitted it to addons.mozilla.org.

New features include fixing the extension for Firefox 1.5 and for mac and loading language and region names from the toolkit languageNames.properties and regionNames.properties files.

A couple of people have asked me how they could deploy standalone XUL applications based on XULRunner 1.8. I have written up the solution (I had to fix bug 316857 first) on the Mozilla Developer Center.

A platform is a set of APIs that can be relied on to build something great/cool/whatever. The characteristics of a platform include stability, documentation, and good APIs (or at least good-enough). I’m very sorry that Daniel Glazman wants the gecko internals to somehow magically morph into a platform of stable APIs, but it doesn’t make sense to allow that to happen yet. The internals of gecko such as the serializer, plaintext editor, and other bits that Daniel wants to hack are just not good enough to make stable and platform-worthy yet, and are hardly documented at all.

I’m insanely proud of what Daniel has been able to do with a customized gecko! I know that we all want to see his gecko changes incorporated back into the codebase and future releases of XULRunner/Firefox; but that involves tracking the changes that happen on the trunk between 1.7 (which branched 4-April-2004) and 1.8 (31-October-2005), filing bugs, and getting changes landed in reviewable and testable chunks, just like any other gecko hacker has to do.

Finally, I’d like to mention that XULRunner was designed specifically with NVU (standalone composer) in mind: sure, XULRunner is still immature in that it doesn’t have all the deployment code written, but that doesn’t mean that it’s not ready now for NVU to ship it as a bootstrap mechanism and easily-built gecko deployment device. As XULRunner lead, I’m happy to help, and document that deployment strategy as necessary.

I have written a design document on how I plan to implement a clean XPCOM shutdown sequence so that we can restart XPCOM in the same process and make it easier to debug and fix shutdown crashes. Please add any comments to the discussion page on the wiki.

I am going to close the Mozilla trunk for several hours tomorrow morning (Friday 11-November) starting at 6AM PST, in order to land parts of bug 313309.

If you’re a hacker who wants to help out Mozilla (and especially XULRunner), I’ve got a couple bugs that need owning: they both have to do with converting a cross-platform image format (probably PNG) into a platform-specific icon format.

Bug 314651

API to generate Mac .icns from a PNG image

Bug 314030

API to generate Windows icons from a PNG image

If you’re able and willing to help, please comment in the bug… I’ve got people who can help you with the Mozilla-API side of things such as getting image bit data from a PNG.