Closed Bug 255807 Opened 20 years ago Closed 17 years ago

Migrate Seamonkey UI from XPFE to New Toolkit

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: jag+mozilla)

References

Details

This idea has come up in de.comm.software.mozilla.* a few times already, it
would mark a big change for Seamonkey but opens new possibilities for its UI and
ensures long life of the suite for those who do not like the "single apps".

Several people already showed interest, I CC a few of them. The idea is to use
this as a tracking bug to coordinate efforts in this direction and collect
people to help.
I'd love to help out with creating a mini- or full branch for that development,
I'm not sure though how much time I'll have left to do real work on that.

I think the first think we'd need here is a bunch of people who are willing to
do work and have time to do so (I'm sure you'll be able to learn the needed
technology on the way). So who else than Peter can do work on that task?

The second issue is that we'll need to decide on what base we'll start the work.
Should we do a full branch off of the 1.7 branch so that we have a stable base
to work on and we're near current aviary work? Should we do a mini-branch off of
trunk, so that we automatically incorporate new developments of Seamonkey and
keep the volume of changes as small as possible? Should we do something somehow
in between those ways?
> I think the first think we'd need here is a bunch of people who are willing to
> do work and have time to do so (I'm sure you'll be able to learn the needed
> technology on the way). So who else than Peter can do work on that task?

Me, but with a grain of salt: beginning from Sep. 1, I've (finally!) a new job.
Even though it's Mozilla related, I don't know now how much time I can devote then.
I would prefer branching off the trunk, that makes remerging easier, when (if?)
we finish with this transition. Trunk has already diverged from the 1.7 branch
quite a bit so that it gets harder to keep some patches I am juggling with
working on both. But that would mean that we need to merge changes from the
trunk every daily or weekly at least. Do you think that would be easily possible?

Perhaps more importantly, we need some kind of ToDo list or plan. How/where do
we start? Do we need to go through all the directories below xpfe/, see what
interfaces are defined, where in Mozilla they are used and change that use to
the corresponding interface from toolkit?  That will keep lxr busy and sounds
like a lot of (tedious) work. Well, I guess I asked for it... Is there a more
intelligent approach?

Btw, I also have a daytime job (that has nothing to do with Mozilla), and am
away most of September.
With a "Mini-Branch", i.e. only branching files/directories where we need
changes, we should be able to keep up with trunk development. For SVG they had
it this way before it was merged into the trunk, probably we should ask Alex
Fritze about how to do this best.

For the TODO, we should probably ask doron (probably best on IRC in
#developers), who already partly tried such an effort more-or-less privately
(called FireMonkey at that time). He probably knows what to do. I guess most of
the work won't be C/C++ but XUL, XBL, probably JS, and CSS.

The CSS reminds me that we'll also have to discuss themes when we're really
starting, as the default theme for toolkit is [p|w]instripe and Seamonkey has
Classic. Toolkit people would of course prefer us to use the default toolkit
theme (and it would be the easiest way to keep up with their changes), but
probably Seamonkey lovers would like to keep Classic and Modern intact.
So we have to go somewhere between the extremes of supporting only *instripe and
having all three intact. I guess we'll start off with the first extreme, and mix
the toolkit default with existing Seamonkey Classic, but we should know where we
want to go in the end. (BTW, I for myself ain't very fond of Classic, so I'd
even be happy with replacing it by some *instripe-type theme completely.)

But for now, people, branching and TODO are more important - the theme
discussion can move off to a newsgroup and/or a dependent bug as we're working
out a solution.
Doing this on a branch would only make sense if seamonkey's UI was frozen for a
period of time.

Personally, I would port Navigator first.  Mailnews should probably be discarded
and rather use Tbird and build on top of it any removed features, as unlike
gecko, the mailnews interfaces are being worked on by mscott and friends.

My "Firemonkey" concept was nothing more than taking firebird at the time, and
doing firebird.exe -chrome xpfe/etc/navigator.xul and fixing up the issues to
get a useable browser.
This should become a XUL Runner project probably
(http://wiki.mozilla.org/XULDev?action=browse&diff=1&id=XulRunner)
migrating to toolkit (as it is currently) has the severe downside that toolkit
patches do not need review. this DOES lead to wrong code (last shown by bug 241028).
Well, that may be true. But there are also errors in code that did go through
review. I guess the main problems for this project here lie somewhere else...

Even though we have lots of CC'd helpers now, nobody seems to know exactly where
to start (or didn't have time to). Doron's idea of making this a XULRunner
project may or may not be a good one. I have looked at XULRunner before it went
into the trunk, but when I encountered problems, I couldn't find anybody to ask.
That may be clearer now.
But personally, I would need specific guidelines before doing any serious work.
A short example how to change a certain bit of code would be best. :-)

I have only received this bit
   ...you have the option of cutting a 'mini-branch' where
   only the files that you really change are tagged and all 
   others are taken from the trunk, or a full branch. The 
   mini-branch approach has the advantage that you get many 
   changes 'automatically', but if the files you tagged change 
   frequently then it often gets out of sync and needs merging.
from Alex Fritze on my search for info on doing branching. The other option he
mentions, branching on one's own machine, would only work if only one works on
this. (Well, for now that would be enough. ;-) )
Not needing/having any review is probably bad for any code. Not needing two
reviews (r+sr) may be OK for many parts of code.

I believe though that code that multiple applications build on should get very
good review normally. Because of that, I guess we'll need tougher review for
toolkit in the future anyways (post-aviary-1.0 stuff, I guess) now that toolkit
has matured quite a bit.

We probably should discuss this with toolkit owner(s) - whoever that is
officially now - and I think at some point we'll have to adopt certain rules
there when toolkit should be as base and more or less an API (think xulrunner
etc.) for mozilla apps to build on.

That's orthogonal though to the effort this bug is really about. The issue with
that here is that it differs a lot from usual procedures in Seamonkey, and
users/devs of that product might be uncomfortable building upon a
not-so-well-reviewed base.

As we might lose vivid development on Seamonkey without porting, I guess we'll
have to go this way some way nevertheless.
oh, it occurs to me that only irc regulars on #developers know that I started to
work on this already...

my current plan is, basically, to unfork chrome://global/content, then replace
xpfe/bootstrap with XRE, then make seamonkey use xulrunner. along these lines
somewhere, unfork other stuff in toolkit/.

I will not complete the unforking with the current review rules (as hinted in my
above comment)
For the record, I added a feature on the aviary branch, and have since ported it
to the trunk, where you can use topsrcdir-relative paths in jar.mn files:

[in xpfe/global/jar.mn]

toolkit.jar:
  global/content/xul.css         (/toolkit/content/xul.css)

This would provide an easy way to un-fork a lot of the core XUL/binding files.
biesi: if you need any help, I can spend time on it :)
that'd be great; feel free to port patches between toolkit and xpfe ;)
and maybe branch->trunk too, because I suspect that "the great merging" might
cause some incompatible changes...

this reminds me, some files only differ because they are relicensed in xpfe, but
not in toolkit; gerv, do you plan to relicense toolkit sometime soon?
> this reminds me, some files only differ because they are relicensed in xpfe, but
> not in toolkit; gerv, do you plan to relicense toolkit sometime soon?

At some point. I'm attempting to get the code which makes up Mozilla done,
before moving on to Firefox and Thunderbird.

However, if this caused people inconvenience, this plan could be changed.

Gerv
Depends on: 263042
Is there some way interested parties can follow progress on this project without
getting in the way?  Or has nothing further been done since October?
Depends on: 276572
Severity: normal → enhancement
Severity from normal to enhancement, logical.
Meaning; don't hold your breath?
No, it is "annoying user playing with bugs he shouldn't"
No, not a user. Users can't change the Severity. If they could I would have
changed back to normal now. Can someone with the needed permissions please
change back (or even to a higher severity)? This bug isn't related to Firefox
and Thunderbird at all and for the suite I think this task is a very important one!
(In reply to comment #6)
> Personally, I would port Navigator first.  Mailnews should probably be
> discarded and rather use Tbird and build on top of it any removed features,
> as unlike gecko, the mailnews interfaces are being worked on by mscott and
> friends.

But not only removed features have to be added. We would also have to remove
useless features (or at least disable them by default). I personally like the
mozilla (suite) mailer as is...
(In reply to comment #1)
> (I'm sure you'll be able to learn the needed technology on the way).

If that's really possible then I could also do some work. As much as possible
for someone that has limited time (who hasn't?) and only a very bad connection
to the internet (very bad analog modem connection) which makes it impossible to
me to keep a local CVS-Copy up-to-date...
Severity: enhancement → normal
Component: Tracking → XP Apps
Product: Core → Mozilla Application Suite
Assignee: chofmann → jag
QA Contact: chofmann
(In reply to comment #18)
> Severity from normal to enhancement, logical.
> Meaning; don't hold your breath?

This, I don't know: (last progress report) comment #17 from Christian was on
2004-12-22...

(In reply to comment #19)
> No, it is "annoying user playing with bugs he shouldn't"

Sorry ... what I avoided was to change "New/ChrisH" to "Assigned/ChristianB"... :-|

(In reply to comment #20)
> No, not a user. Users can't change the Severity. If they could I would have
> changed back to normal now. Can someone with the needed permissions please
> change back (or even to a higher severity)? This bug isn't related to Firefox
> and Thunderbird at all and for the suite I think this task is a very important
one!

(How well, someone else than me reverted it, and more...)
Bug 282177 is a tracking bug for the various bindings in xpfe vs toolkit.  Those
have to be sync'ed up before this happens.  The lack of developer comments here
doesn't mean this isn't being worked on.

As I understand it, this isn't a time-critical bug... it only needs to happen
before somebody somewhere decides the Mozilla suite should die because it takes
too much effort to maintain (presumably sharing the bindings reduces the
maintenance required).
Depends on: 282177
See also http://wiki.mozilla.org/wiki/SeaMonkey:Home_Page - we need people to
work on all that ASAP.

I think it doesn't depend on where we start, the most important thing is that it
gets done. If we have a few manageable regressions in the 1.9a cycle(s), it's OK
as long as it means that SeaMonkey is being worked on.

Due to the issue of SeaMonkey being no priority any more for MoFo, we need to
get something done soon or else...
Blocks: 272429
Blocks: 304309
(In reply to comment #25)
> Due to the issue of SeaMonkey being no priority any more for MoFo, we need to
> get something done soon or else...

Well, has there been any progress? That last comment is from March...

I know a project plan is being formulated and this bug should probably be a tracking bug for where things are at rather than having any patches attached. Work will be happening on the trunk fairly soon.
(In reply to comment #27) from IanN
> I know a project plan is being formulated and this bug should probably be a
> tracking bug for where things are at rather than having any patches attached.
> Work will be happening on the trunk fairly soon.

Ok, fairly soon was over three months ago. Can I take a look at this project plan somewhere? Any guess when work will start on this?
Have a look on the SeaMonkey Wiki pages, especially <http://wiki.mozilla.org/SeaMonkey:Toolkit_Transition>.
Subject: Re: [oodisc] =?koi8-r?b?7sHT1NLPysvBINDSyc7UxdLBIC4=?=

In the notifier the subject is shown as "7sHT1NLPysvBINDSyc7UxdLBIC4". In message pane it is showb as normal "Re: [oodisc] &#1053;&#1072;&#1089;&#1090;&#1088;&#1086;&#1081;&#1082;&#1072; &#1087;&#1088;&#1080;&#1085;&#1090;&#1077;&#1088;&#1072; ."
UPS. Sorry. Not the right bug.
SeaMonkey is using toolkit now as bug 328887 has been fixed, can this bug be closed?
As the original reporter I can say that the goal of this bug was reached. Thanks to all who made it happen! Marking fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
QA Contact: ui-design
You need to log in before you can comment on or make changes to this bug.