User:Mnyromyr: Difference between revisions

Jump to navigation Jump to search

User:Mnyromyr (view source)

Revision as of 16:54, 16 January 2009

4,510 bytes removed ,  16 January 2009
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Some unordered thoughts about SeaMonkey and things I'd like to see hacked, maybe even by myself. '''<tt>;-)</tt>'''
Some unordered thoughts about SeaMonkey and things I'd like to see hacked, maybe even by myself. '''<tt>;-)</tt>'''
<ul>
<ul>
<li>[[User:Mnyromyr:SeaMonkeyXPFE2toolkit_widget_transition|SeaMonkey /xpfe to /toolkit widget transition]]</li>
  <li>[https://bugzilla.mozilla.org/show_bug.cgi?id=360488 Stuff we (may) want to port over from Thunderbird into SeaMonkey MailNews (bug 360488)]</li>
  <li>[https://bugzilla.mozilla.org/show_bug.cgi?id=360488 Stuff we (may) want to port over from Thunderbird into SeaMonkey MailNews (bug 360488)]</li>
  <li>[[User:Mnyromyr:MailFilters|Improvements for SeaMonkey MailNews filters]]</li>
  <li>[[User:Mnyromyr:MailFilters|Improvements for SeaMonkey MailNews filters]]</li>
  <li>[[User:Mnyromyr:MessageViews|Fixing Message Views]]</li>
  <li>[[User:Mnyromyr:MessageViews|Fixing Message Views]]</li>
  <li>[[User:Mnyromyr:BayesFacts|Technical Notes on the Bayesian Junk Filter]]</li>
  <li>[[User:Mnyromyr:BayesFacts|Technical Notes on the Bayesian Junk Filter]]</li>
<li>[[User:Mnyromyr:SeaMonkeyXPFE2toolkit_widget_transition|SeaMonkey /xpfe to /toolkit widget transition]] (historic)</li>
</ul>
</ul>
== SeaMonkey /xpfe to /toolkit widget transition ==
It is a stated [http://wiki.mozilla.org/index.php?title=SeaMonkey:Project_Goals#Future_Releases (future) goal] of the SeaMonkey project to switch to the "new" XUL widget toolkit used by XULRunner, Firefox, Thunderbird, etc.
But apart from the backend stuff like /bootstrap etc., porting the Seamonkey ''bindings'' will also pose quite some problems. Toolbars, for example, are quite different: /xpfe has grippies, /toolkit's toolbars are customizable... (And both are non-movable, btw.)
The actual transition to toolkit has been 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
Work has already begun to identify those widgets falling under 1) or 2) above, and up to now, this has only lead to a '''loss''' of functionality for SeaMonkey, because /toolkit peers are (not unexpectedly) unwilling to take back stuff they kicked out before (see [https://bugzilla.mozilla.org/show_bug.cgi?id=282187 bug 282187] for details).
===So how do we cope with this?===
While the loss of a minor context menu item might be acceptable in the light of a greater cause, making eg. /xpfe toolbars base upon /toolkit (as in 3) above) will be problematic:
1. Make chrome://global/content/bindings/* refer to /toolkit and introduce chrome://xpfe/content/bindings/* for /xpfe
<ul>This means touching all Seamonkey stuff that relies upon the /xpfe implementation and will break (lots of? how many?) addons doing the same.
All these /xpfe bindings would inherit as much as possible from the /toolkit version. Files "interested" in the /xpfe widgets would have to include a special <tt>xpfe.css</tt> stylesheet with the /xpfe widget's -moz-binding rules.</ul>
<ul>''We need to get an overview about which SeaMonkey addons will break!''</ul>
2. Keep chrome://global/content/bindings/* refer to /xpfe and introduce chrome://toolkit/content/bindings/* for /toolkit
<ul>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.</ul>
3. Drop /xpfe and put all the stuff into /toolkit
<ul>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.</ul>
4. Make /xpfe binding files include the /toolkit files via some ?xbl-include? magic
<ul>This needs two steps:
<ul>
  <li>introduce chrome://toolkit/content/bindings/* for /toolkit binding files. These files remain unchanged and thus refer internally to chrome://global/content/bindings/* still.</li>
  <li>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.</li>
</ul>
</ul>
<ul>This will keep all /xpfe chrome://global/content/bindings/* references intact while using unchanged /toolkit bindings as a base, but this, too, is very hackish.</ul>
5. Just keep /xpfe in sync with /toolkit by backporting interesting stuff
<ul>While this is the easiest way with regard to infrastructural changes, it may be quite tedious to watch out for changes in /toolkit files.</ul>
6. Use the existing ''communicator'' infrastructure as it's supposed to be included by all main windows!
<ul>This means that we can shadow the toolkit bindings in xul.css with our own in /xpfe/communicator/resources/content/communicator.css! No extra magic foo is required...</ul>
When first writing this, I saw 4. (and maybe 5.) as viable roads, but both
neglect the XULRunner case. Targetting XULRunner will mean that we have no (nice) chance of tinkering with the toolkit itself, we're bound to derive from it.
But then Neil told me about the communicator.css, and now the toolbar transition [https://bugzilla.mozilla.org/show_bug.cgi?id=282188 bug 282188] has a ''little'' patch that even allows for usage of both toolkit and XPFE bindings...
The derived bindings there are stored in chrome://communicator/content/bindings/, more are likely to follow.
(Oh, now that I alter this page I see that Neil did propose that, too - nice :) )
Mnyromyr
235

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/124396"

Navigation menu