User:Mnyromyr:SeaMonkeyXPFE2toolkit widget transition

The transition has been finished for quite a while by now. This page only serves historic purposes. ;-)

SeaMonkey /xpfe to /toolkit widget transition

It is a stated (future) goal of the SeaMonkey project to switch to the "new" XUL widget toolkit used by XULRunner, Firefox, Thunderbird, etc.

But apart from the backend stuff like /bootstrap etc., porting the Seamonkey bindings will also pose quite some problems. Toolbars, for example, are quite different: /xpfe has grippies, /toolkit's toolbars are customizable... (And both are non-movable, btw.)

The actual transition to toolkit has been outlined like this:

KaiRo	1) pack the toolkit version via jar.mn where we have a null diff
KaiRo	2) work on doing the same for all easy cases (contribute eventual
	   improvements from our side to toolkit)
KaiRo	3) for the hard stuff: eventually create new xbl files/bindings in the
	   communicator/ package that extend toolkit versions, or that do our
	   own implementations where applicable

Work has already begun to identify those widgets falling under 1) or 2) above, and up to now, this has only lead to a loss of functionality for SeaMonkey, because /toolkit peers are (not unexpectedly) unwilling to take back stuff they kicked out before (see bug 282187 for details).

So how do we cope with this?

While the loss of a minor context menu item might be acceptable in the light of a greater cause, making eg. /xpfe toolbars base upon /toolkit (as in 3) above) will be problematic:

1. Make chrome://global/content/bindings/* refer to /toolkit and introduce chrome://xpfe/content/bindings/* for /xpfe

This means touching all Seamonkey stuff that relies upon the /xpfe implementation and will break (lots of? how many?) addons doing the same. All these /xpfe bindings would inherit as much as possible from the /toolkit version. Files "interested" in the /xpfe widgets would have to include a special xpfe.css stylesheet with the /xpfe widget's -moz-binding rules.

We need to get an overview about which SeaMonkey addons will break!

2. Keep chrome://global/content/bindings/* refer to /xpfe and introduce chrome://toolkit/content/bindings/* for /toolkit

This will not work without changes to /toolkit, because /toolkit bindings expect to be available via chrome://global/content/bindings/* (as do /xpfe bindings) and so would refer to the (wrong) /xpfe ones.

3. Drop /xpfe and put all the stuff into /toolkit

This means putting lots of #ifdefs into /toolkit, because they most probably won't accept all the stuff back they dropped. Furthermore, it's a quite ugly.

4. Make /xpfe binding files include the /toolkit files via some ?xbl-include? magic

This needs two steps:
• introduce chrome://toolkit/content/bindings/* for /toolkit binding files. These files remain unchanged and thus refer internally to chrome://global/content/bindings/* still.
• implement an ?xbl-include? processing instruction (or do we already have something like that?), so that the /xpfe bindings can include the /toolkit files on file level.

This will keep all /xpfe chrome://global/content/bindings/* references intact while using unchanged /toolkit bindings as a base, but this, too, is very hackish.

5. Just keep /xpfe in sync with /toolkit by backporting interesting stuff

While this is the easiest way with regard to infrastructural changes, it may be quite tedious to watch out for changes in /toolkit files.

6. Use the existing communicator infrastructure as it's supposed to be included by all main windows!

This means that we can shadow the toolkit bindings in xul.css with our own in /xpfe/communicator/resources/content/communicator.css! No extra magic foo is required...

When first writing this, I saw 4. (and maybe 5.) as viable roads, but both neglect the XULRunner case. Targetting XULRunner will mean that we have no (nice) chance of tinkering with the toolkit itself, we're bound to derive from it.

But then Neil told me about the communicator.css, and now the toolbar transition bug 282188 has a little patch that even allows for usage of both toolkit and XPFE bindings...

The derived bindings there are stored in chrome://communicator/content/bindings/, more are likely to follow. (Oh, now that I alter this page I see that Neil did propose that, too - nice :) )