SeaMonkey:Toolkit Transition

From MozillaWiki
Jump to: navigation, search
Note:
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.

Note:
This is work in progress!

We really welcome any effort to fill in the gaps! If you intend to make substantial changes here, though, please confer with Biesi, Neil or Mnyromyr before!

ToDo: Widget bug status! Who's really working on these?

ToDo: Startup phase transition needs to be explored!

ToDo: Components section lacks detail!


Introduction

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.


The Transition

Making SeaMonkey avian, though, will require substantial changes in these major areas (roughly sorted by "backendishness"):

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!

Startup

(write me)

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

Components

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.

Possible Component Transition Plan
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
console console Yes
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
mozapps/ downloads No
- 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.
 ? gnome TBD
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)
related  ? No
- remote - We already build with this.
resetPref - - Not packaged by FF/XULRunner (although dir entered)
search  ? No Currently specially included in build.mk
sidebar  ? No
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.
urlwidget  ? No
 ? viewconfig  ?
(part of xpfe/ browser) viewsource No?
windowds - - FF, TB & XULRunner runner still build this.
winhooks  ?  ?
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

XUL Widgets

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?

GUI

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)


The Plan

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:

Status of each component

These bugs are filed, one for each specific component: (enter list here)


Unsorted stuff

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_? ;-)

--> [1] 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

Retrieved from "https://wiki.mozilla.org/index.php?title=SeaMonkey:Toolkit_Transition&oldid=83813"