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.
I'd like to help out.
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
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?
my current plan is at http://wiki.mozilla.org/index.php/User:Biesi I'm at stage 1 currently.
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
(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...
(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] Настройка принтера ."
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
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.