Closed Bug 90293 Opened 21 years ago Closed 19 years ago

allow for mailnews stand alone application


(SeaMonkey :: MailNews: Message Display, enhancement)

Not set


(Not tracked)



(Reporter: sspitzer, Assigned: sspitzer)





(1 file, 4 obsolete files)

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 
This question comes up in n.p.m.mail-news every so often.


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 

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
Hardware: PC → All
Summary: allow for mailnews stand alone app → allow for mailnews stand alone application

the work for this has been done, on a branch.


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.
for starters, see:

[disable migration]

[set profile home to ~/.mozmail]

[launch the default browser]
[force launch of mail]
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.
Attachment #94713 - Attachment is obsolete: true
Attached patch new patch (obsolete) — Splinter Review
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]


[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?
Attached patch still in "hack" stage. (obsolete) — Splinter Review
Attachment #94728 - Attachment is obsolete: true
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
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

I'm going to spin up a bug on bryner about this, he said he's going to start
working on it.
I think this bug is ripe for wrapping up, right?
Yes, this is clearly done (thanks mscott!).
Closed: 19 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.