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)
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.)
Making /xpfe toolbars base upon /toolkit 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"...