Closed Bug 90293 Opened 21 years ago Closed 19 years ago
allow for mailnews stand alone application
allow for mailnews stand alone app I'm not planning on doing this, but I want it in bugzilla so I can point to this bug.
This question comes up in n.p.m.mail-news every so often. see news://news.mozilla.org/3A427646.6060606%40netscape.com Unlike browser only (which I think you can get if you build with DISABLE_MAILNEWS), no one has done the work to produce a build with just mail/news. It isn't impossible, but it would be quite a bit of work. And after the build issues, we'd have to work on browser integration, so that clicking on a link in a mail message would launch what ever browser was registered. (like IE or netscape 4.x)
Severity: normal → enhancement
Target Milestone: --- → Future
Summary: allow for mailnews stand alone app → allow for mailnews stand alone application
accepting. the work for this has been done, on a branch. Notes: 1) not all the changes are pretty. 2) no work was done to deal with migrating mail from an existing mozilla or netscape profile to the stand alone app. I'll attach a patch, in case someone wanted to take it, and build their own stand alone mail application from the mozilla code base.
Status: NEW → ASSIGNED
see new thread to n.p.m.mail-news news://news.mozilla.org:119/3D5066E4.email@example.com
for starters, see: [disable migration] see http://bonsai.mozilla.org/cvsview2.cgi? diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/profile/src& command=DIFF_FRAMESET&root=/cvsroot&file=nsProfile.cpp&rev1=1.256&rev2=1.256.2.1 [set profile home to ~/.mozmail] and http://bonsai.mozilla.org/cvsview2.cgi? diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpcom/io&com mand=DIFF_FRAMESET&root=/cvsroot&file=nsAppFileLocationProvider.cpp&rev1=1.37&re v2=184.108.40.206 [launch the default browser] and http://bonsai.mozilla.org/cvsview2.cgi? diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/docshell/bas e&command=DIFF_FRAMESET&root=/cvsroot&file=nsWebShell.cpp&rev1=1.581.2.2&rev2=1. 581.2.3
[force launch of mail] http://bonsai.mozilla.org/cvsview2.cgi? diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpfe/bootstr ap&command=DIFF_FRAMESET&root=/cvsroot&file=nsAppRunner.cpp&rev1=1.353&rev2=1.35 3.2.1
We want to hide / remove the UI elements that mailnews currently has for browser, editor, aim / chatzilla, etc. Hopefully we don't have to fork the UI to do that. One idea is to follow how the spell checker UI works. If I fail to get a certain contract ID (say, the browser instance, since I'm no longer going to build / package it), I'll hide certain UI.
I would highly recommend forking the UI. We did this in m/b (it's still an ongoing process now), but you can collapse overlays back into the same file, just rip out UI elements that aren't relevant, and just generally improve both your startup and new window performance (and in-memory footprint). The trick is to make standalone mail and browser the future, to get nightly builds, and to raise awareness to the point where people know about the new UI and run it and test it. What you've done to disable migration and hardcode a profile subdir is exactly what I was planning to do with m/b. We're working on getting a build symbol defined so that we can actually check into the trunk. Another thing we should do IMO is fork all.js as well based off application so that we can separate the prefs and remove the ones that aren't relevant to specific apps. (Maybe we do this by loading an extra prefs file, e.g., browser.js or mail.js.) This is great stuff!
In m/b we are also developing a new toolkit in mozilla/toolkit, e.g., to make the new customizable toolbars and such. If m/m does commit to forking the UI, then we could set it up to use the new XUL widgets etc. etc.
Improving startup, new window, performance and in-memory footprint are definitely good reasons to fork. What kind of improvements are you seeing with m/b? > Another thing we should do IMO is fork all.js We already have this, see mozilla/modules/libpref/src/init/mailnews.js (there is editor.js and all.js, too.)
Seth, this is great, something I've always wanted with mailnews ... About performance improvements: hyatt mentioned on IRC that new window time for m/b was decreased with about 20/30%. I'd definitely support forking the mailnews UI (and making it slicker?)
Very interested in a standalone mail & news reader expecially for Mac OS X. Thanks for sugesting it.
about the patch, here's some general comments: profile/src/nsProfile.cpp [disable migration since we don't care about 4.x, no profile command line args] mailnews/base/public/nsIMessenger.idl mailnews/base/src/nsMessenger.cpp xpfe/communicator/resources/content/utilityOverlay.js [click on link in mail message, open default browser click on throbber, open default browser right click on link, open in new window, open default browser] xpfe/bootstrap/nsAppRunner.cpp [force -mail, no splash] docshell/base/nsWebShell.cpp [clicking on links mailto, stay internal, other schemes, go to default] xpcom/io/nsAppFileLocationProvider.cpp [different profile root] here's what's on my current todo list: nntp and news:// urls? new throbber url tools | search | search the web download manager? window | navigator window | compose File | New | Browser File | New | Compose Page browser in task bar? compose in task bar? chat / aim in task bar? bookmark this link? rename exe and internal reference to app to minotaur (we use minotaur as the profile root) remove chrome / dll bloat help issues? about: issues? go | start page from stand alone msg window? As I mentioned before, the patch isn't ready for prime time yet, but getting closer. This is done against the mozilla 1.0 branch.
Attachment #94725 - Attachment is obsolete: true
Would this bug allow to go further in a direction of bug 115903? This would be a really nice thing to have some time!
There's no point in keeping most of the browser UI when mailnews is its own application; are you planning to remove some of that with this patch?
see http://www.mozilla.org/mailnews/minotaur/index.html for info about this patch.
Attachment #94781 - Attachment is obsolete: true
I think it would be great if it wasn't necessary to hack up xpfe/bootstrap for creating an arbitrary application. (In additon to what you've done, you'd also need to hack splash.rc on win32 or you won't be able to run minotaur concurrently with mozilla). There are basically 3 types of files that live in xpfe/bootstrap: (1) platform-specific native code (nsNativeAppSupport*) (2) generic XUL application code (nsAppRunner.cpp) (3) application-specific code (splash screens, rc files, icon files) It would be great if (1) and (2) could be linked into a static library, which then could be linked with application-specific code and resources to create an executable in a non-central location (for example, mozilla/mailnews/app).
good ideas bryner. bryner tells me: "if you don't change splash.rc, and you have mozilla running, launching minotaur will just give you a new navigator window because it does the dde thing or it may give you a mozilla mail window (not sure exactly how that works)... but it most likely won't start your app" "you also shouldn't really have to hack in the xpcom stuff for the profile location. it might be better to register your own nsIDirectoryServiceProvider. let's avoid a thousand #ifdef's" I'll have to do these things, and http://bugzilla.mozilla.org/show_bug.cgi? id=90293#c19 before I can land on the trunk. all this is needed for the XRE, too.
before minotaur and phoenix can properly (and cleanly) co-exist on the trunk, we need to do http://bugzilla.mozilla.org/show_bug.cgi?id=90293#c19 I'm going to spin up a bug on bryner about this, he said he's going to start working on it.
bryner's ideas spun off to bug http://bugzilla.mozilla.org/show_bug.cgi?id=163586
Seth wrote: > http://bugzilla.mozilla.org/show_bug.cgi?id=90293#c19 > http://bugzilla.mozilla.org/show_bug.cgi?id=163586 Sorry for the SPAM, this is just a bit of bugzilla love: Comment 19 Bug 163586
I think this bug is ripe for wrapping up, right?
Yes, this is clearly done (thanks mscott!).
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.