User:Mnyromyr

Some unordered thoughts about SeaMonkey and things I'd like to see hacked, maybe even by myself. ;-)

SeaMonkey /xpfe to /toolkit widget transition

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.

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.

So now I'm favouring option 1. ;-)

How that would work in detail

• Introduce a new package xpfe for all the widget features that are currently available in /xpfe but not in /toolkit. This would allow us eg. to have our own <textbox> derivate referenced by chrome://xpfe/content/bindings/textbox.xml (Neil: how about chrome://communicator/content/bindings/textbox.xml) and that binding would just xbl:extend the toolkit version.

Where would we put this package? /suite/xpfe?

• The respective -moz-binding rules would be collected in a xpfe.css file (Neil: possibly use the existing chrome://communicator/content/communicator.css).
• This xpfe.css could either be superimposed over xul.css by the yet-to-implement bug 297438 or included by each respective SeaMonkey .xul file directly (Neil: or import it from the theme's global.css or communicator.css?).