This page is out of date
The SeaMonkey trunk is now based on toolkit since 2007-05-29. See SeaMonkey:suiterunner and SeaMonkey:New for 2.0.
ToDo: Widget bug status! Who's really working on these?
ToDo: Startup phase transition needs to be explored!
ToDo: Components section lacks detail!
It's a stated (future) goal of the SeaMonkey project to switch to the "new toolkit" environment provided/used by XULRunner, Firefox, Thunderbird et al., hence staying in touch with contemporary Mozilla.org development.
This so-called "SeaMonkey Toolkit Transition", though, will be made in the spirit of continuity — reaching new shores without sacrificing (too much of) the distinctive likeness of the former Mozilla Application Suite, its feature set or its data structures.
Making SeaMonkey avian, though, will require substantial changes in these major areas (roughly sorted by "backendishness"):
- Startup (bootstrap, chrome registry, etc.)
- Components (wallet vs. satchel, different autocomplete implementations, etc.)
- XUL Widgets (buttons, toolbars, grippies, etc.)
- GUI (window layouts, themes, locales)
- Other SeaMonkey-specific stuff (should reside in /suite)
Most of the transition work will probably end up in the suite/ directory of the mozilla.org tree, which should contain all SeaMonkey-specific code in the future. There is a separate document for describing the directory layout we're using there. Be sure to follow that when putting new stuff into that directory!
now we have a /suite directory, can it be used just like /browser for FF?
how do we maintain backwards compatibility with the old chrome registry?
I don't think we need to - but that means, we need EM when flipping the switch for that, and we need to have new chrome registration stuff in place in our jar.mn files at this time. We currently wrap those in #ifdef MOZ_XUL_APP so that they are not yet built by us - though I'm not yet sure where else flipping MOZ_XUL_APP to on would change stuff. --KaiRo 19:47, 13 Feb 2006 (PST)
Bug 328887 replace xpfe/bootstrap with toolkit/xre issues:
* splash screen (probably not as important) Bug 329742 * existing profiles Bug 329744
Toolkit's components structure is a barren wasteland compared with XPFE's richness, but we may use some of the similar components like filepicker, though. The rest of the components we need has to come from XPFE anyway.
We can easily (?) package SM specific components from XPFE (even toolkit does this [state example here]), but we need to figure out if there are name collisions of incompatible components before!
If there are collisions or functional shortcomings in toolkit, can we override that with SM-specific stuff? Would that be wise with regard to the XULRunner goal? It'd probably better to curse Toolkit, rename our component and package it from /suite!
(Detailed component move overview and plan needs to come here!)
The following list of components with a possible transition plan has not been discussed and is no where near final.
In the table below, Phase 1 means the first builds that are MOZ_XUL_APP=1 that would be complete enough for basic testing see also bug 328887. Phase 2 = anything after that, currently undecided.
|Existing Component||Toolkit Component||Phase 1||Comments|
|Alerts||Alerts||Yes||Code is the same|
|AutoComplete||Autocomplete||No||See bug 263042 - probably will be shipping both together|
|Bookmarks||?||No||Currently specially included in build.mk|
|cookie||cookie||Yes||We already package this.|
|directory||-||-||FF & XULRunner still build and package this.|
|download-manager||components/ downloads||No||Work in progress - will probably use toolkit-backend. See bug 348386|
|-||extensions||Yes||New extension manager required for the new chrome management|
|extensions/ help||help||Yes||Already Moved.|
|extensions/ wallet||satchel||No||Depends on having toolkit's autocomplete available.|
|(part of extensions/ wallet)||password manager||No||Depends on having toolkit's autocomplete available. See also bug 227632 and bug 222653 for things to consider.|
|filepicker||filepicker||Yes||Picks up js/xul change only, filepicker code for toolkit apps is still built in xpfe.|
|find||-||-||FF, TB & XULRunner still build this.|
|history||history||No||We need toolkit's autocomplete available first|
|intl||-||-||FF, TB & XULRunner still build this.|
|killAll||-||-||Not packaged by FF/XULRunner (although dir entered, see bug 348437)|
|-||remote||-||We already build with this.|
|resetPref||-||-||Not packaged by FF/XULRunner (although dir entered)|
|search||?||No||Currently specially included in build.mk|
|Startup||startup and commandlines||Yes||Code required to pick up new chrome and xre startup.|
|updates||toolkit/ mozapps/ update?||Yes?||I think this will allow us the update facilities that Firefox & Thunderbird have. We'll build with it initially, but that doesn't necessarily mean we have to use it straight off.|
|(part of xpfe/ browser)||viewsource||No?|
|windowds||-||-||FF, TB & XULRunner runner still build this.|
|xfer||(in toolkit locales)||Yes|| this only has a .properties file, which I (biesi) believe is still used.
Standard8 : The .properties file exists here in toolkit, therefore we should just drop this one and pick up the new one.
|xremote||?||?||Probably needs reimplementing based on this code|
While most XUL widgets provided by /xpfe or /toolkit are almost identical, some of them are quite different and need special treatment if we want to keep the Suite's overall look and feel, based upon the new toolkit.
Toolbars are a good example: /xpfe's have grippies, while /toolkit's are customizable - and both are still non-movable (just as a sidenote).
The widget transition process itself will look like this:
For each widget contained in /xpfe:
- If the widget is a functionally identical to its /toolkit counterpart, we package the /toolkit file in the global jar manifest file /xpfe/global/jar.mn, so that subsequent changes to the /toolkit file won't make the widget unsynced again. (Note: Camino just has embed.jar and pipnss.jar, so no problems here.)
- If the widget's behaviour differs, the widget used by SeaMonkey needs to be derived from its /toolkit counterpart, so that we don't lose SeaMonkey functionality:
- Widgets in toolkit.jar are referenced in XUL via chrome://global/-URIs, stuff used suite-wide is referenced via chrome://communicator/-URIs.
- Thus create a new widget with the SeaMonkey-specific parts contained in the communicator package, but derived from the respective global widget.
- The new derivation should reside physically in /suite/common/content/bindings/; be sure to update suite/common/jar.mn also. Mind the directory layout plan!
- Replace all references in XUL to the old base (global) widget by ones to the new (communicator) widget, hence the SeaMonkey appearance won't change, just the underlying implementation!
(See bug 282188 for an example of such a derivation.)
Once all widget references in /xpfe/global/jar.mn point into /toolkit, we may consider making /toolkit's binding directory be part of our build system.
But the avian toolkit.jar contains more than just bindings, e.g. the global package — how do we sync that?
There are changes ahead, but these aren't necessarily part of the actual Toolkit transition:
- We won't move over to the Aviary themes, but we are planning to improve and modernize both Modern and Classic in future. (Any help is greatly appreciated! See also bug 321927 et al.)
- We will be moving to so-called source L10n, so translating and localizing SeaMonkey will be much easier in future (see bug 286110 and bug 325473 also).
Other SeaMonkey-specific stuff
(should reside in /suite)
While becoming XULRunner compatible is a high goal and needs to be kept in mind when making other changes, it's nothing requiring immediate action. It's really a long-term task.
In the mid-term, all SeaMonkey-specific stuff (e.g. chrome stuff only used by us) should reside under the /suite directory. The toolkit used and packed should already be the aviary toolkit, plus our extensions in Seamonkey-specific packages. Ditto for SeaMonkey-specific components. If possible, the shift to source-based L10N should have already happened before this.
In the short term, though, we need to stop the toolkit widget partition, i.e. stop the increasing drift between both widget sets. This will mean to tackle the widget transition as detailed above and covered by meta bug 282177 ("Resync xpfe bindings with toolkit widgets").
Status of each widget
These bugs are filed, one for each specific widget:
- Bug 282178: sync xpfe tabbrowser with toolkit tabbrowser CTho?
- Bug 282179: sync xpfe browser.xml with toolkit browser.xml nobody
- Bug 282180: sync xpfe button.xml with toolkit button.xml Serge
- Bug 282181: sync xpfe dialog.xml with toolkit dialog.xml Gavin?
Bug 282182: sync xpfe general.xml with toolkit general.xml Serge
- Bug 282183: sync xpfe listbox.xml with toolkit listbox.xml Serge (helpwanted)
- Bug 282184: sync xpfe menu.xml with toolkit menu.xml ajvincent
- Bug 282186: sync xpfe text.xml with toolkit text.xml Serge (helpwanted)
- Bug 282187: sync xpfe textbox.xml with toolkit textbox.xml Serge (helpwanted)
Bug 282188: sync xpfe toolbar.xml with toolkit toolbar.xml Mnyromyr
Bug 282189: sync xpfe toolbarbutton.xml with toolkit toolbarbutton.xml Serge
- Bug 282190: sync xpfe tree.xml with toolkit tree.xml nobody
- Bug 282191: sync xpfe wizard.xml with toolkit wizard.xml nobody
- Bug 283182: sync xpfe tabbox with toolkit tabbox CTho?
- Bug 285374: sync xpfe colorpicker.xml with toolkit colorpicker.xml Jag?
- Bug 342087: make preferences use an extended toolkit Prefwindow
- binding Callek
- Various Preference Panes (see: Prefwindow Panes)
- (Others, help-wanted, after binding completion)
Status of each component
These bugs are filed, one for each specific component: (enter list here)
Retrieved from biesi
* implement "new tab" button on tab bar using an overlay * "Redo" in ctxt menu of textboxes will be lost, probably not much of a loss
I strongly deny that, but the milk seems to have been spilt already :-(
--Mnyromyr 13:16, 13 Feb 2006 (PST)
* <wizard> can't include statusbars any more (this is a Good Thing)
(added in bug 209550 (https://bugzilla.mozilla.org/show_bug.cgi?id=209550)) * more...
--> this means xpfe/global as well as xpfe/bootstrap are obsolete and can removed.
4. build system changes to build toolkit/content directly, instead of xpfe/global
* take care of l10n issues (dtd/properties are elsewhere in toolkit)
We should do a transition to the "source L10n" approach at the same time (I'm still awaiting a list of needed steps for that from gandalf), which means we can directly use the existing toolkit localizations then. L10n transition should probably be a step of its own though... --KaiRo 08:05, 2 Jan 2006 (PST)
5. gradually switch more stuff to toolkit
* DL Manager. At least backend, maybe frontend too * Wallet -> Satchel * more...
AxelHecht quotes Benjamin,
- bsmedberg Pike: that would fall under "port seamonkey to toolkit"
- Pike yes
- Pike or "unfork chrome registry"?
- Pike as a step in the port?
- bsmedberg The problem is, that the toolkit chrome registry doesn't check localeVersion/skinVersion.
- bsmedberg Compatibility is managed by the extension manager.
- bsmedberg So you have to get the extension manager working at the same time.
This should probably go into a bugzilla somehow.
From IRC (excerpts)
[16.12.2005 20:32] <ajschult> Mnyromyr: I was under the impression toolkit migration meant using the toolkit startup mechanism (XRE) and components from toolkit (history, autocomplete, etc) that were forked
[16.12.2005 20:34] <KaiRo> Mnyromyr: well, IMO, we should have one doc that touches the whole migration we need to do... but for now, the main parts are IMHO 1) widget migration, 2) moving of seamonkey-specific chrome to suite/ (content/skin/locale), 3) moving of seamonkey-specific code to suite, 4) making seamonkey toolkit.jar be the same as xulrunner/ff/tb toolkit.jar, 5) migration of further framework to xulrunner framework
[16.12.2005 20:35] <KaiRo> Mnyromyr: I think 4) and 5) don't need detailed plans for now
[16.12.2005 20:36] <KaiRo> 1) and 2) should have concrete plans and should start ASAP, IMO
[16.12.2005 20:36] <KaiRo> 3) is a mid-term task, 4) is longer-term, 5) is long-term
[16.12.2005 20:37] <Mnyromyr> KaiRo: 3 sounds like dropping /xpfe?
[16.12.2005 20:37] <Mnyromyr> (the directory)
[16.12.2005 20:38] <KaiRo> Mnyromyr: not really, much of it is shared with e.g. camino
[16.12.2005 20:39] <KaiRo> Mnyromyr: we should try not to move any stuff to suite/ that gets obsoleted by steps 4) or 5) - at least, as far as this is reasonable and easily possible
[16.12.2005 20:42] <Mnyromyr> my main problem currently is my understanding of the stuff under xpfe/components - how is it used, how can we transfer it, how does the whole shebang there actually _work_? ;-)
-->  is good reading stuff (--Mnyromyr 15:34, 19 Dec 2005 (PST))
[16.12.2005 20:45] <KaiRo> Mnyromyr: good question :) NeilAway or bsmedberg can probably shed some light on it... and bsmedberg also knows what directory structure it ideally should be put in :)
The discussion about suite/ directory layout that has been here previously moved over to SeaMonkey:Suite_Directory_Layout#IRC_discussion_snippets