[Project_owners] SeaMonkey XPFE -> toolkit transition

Axel Hecht axel at pike.org
Tue Jun 14 11:44:16 EDT 2005


Karsten Düsterloh wrote:
> Hi!
> 
> It is a stated (future) goal
> <http://wiki.mozilla.org/index.php?title=SeaMonkey:Project_Goals#Future_Releases>
> of the SeaMonkey project to make the suite XULRunner compatible, which
> of course includes the need of using the new aviary /toolkit instead of
> the /xpfe stuff while retaining (all) the functionality/featureset.
> 
> I've explored a few possibilities how to achieve this in
> <http://wiki.mozilla.org/User:Mnyromyr#SeaMonkey_.2Fxpfe_to_.2Ftoolkit_widget_transition>,
> but I need some "real" data about what will likely break:
> 
> If the transition would be made like this:
> - Use toolkit as a base, i.e.
> chrome://global/content/bindings/toolbar.xml will reference toolkit's
> toolbar widgets
> - Move all the /xpfe widget stuff that isn't part of /toolkit into a new
> package, so that they may be referenced via eg.
> chrome://xpfe/content/bindings/toolbar.xml. These widgets would
> xbl:extend their respective /toolkit counterparts.
> - Assemble the new -moz-bindings in a new chrome://xpfe/content/xpfe.css
> and include that in every file that wants to use this extended widget set
> 
> So, which of *your* addons will break then?
> Which addons use the xbl:extends mechanism to extend XPFE widgets and
> require xpfe specific functionality?

I would like to note that the goal is to make seamonkey a toolkit app. 
That involves much more than outlined here, and rules out some of the 
approaches (like #ifdefs).

But some of that may be intermediate steps.

We may want to look at catalogs and default stylesheets again, and get 
rid of the "you gotta include xul.css" alltogether, which would enable 
us to just load xpfe.css instead and include toolkits xul.css from there.

Axel


More information about the Project_owners mailing list