User:Mnyromyr

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

Seamonkey /xpfe to /toolkit transition (toolbars example)

Seamonkey /xpfe to /toolkit transition (toolbars example)

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

While the actual transition to toolkit is 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

making /xpfe toolbars base upon /toolkit (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 addons doing the same!

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.

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.

Currently, I see only 4. as a useful way to make /xpfe bindings be based upon /toolkit --- if possible at all (and that still needs some exploring). After all, we can still go for 5. and take the risk of "being behind"...