90293 - allow for mailnews stand alone application

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[(not reading, please use [e-mail] instead)]

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.

Comment 1

[(not reading, please use [e-mail] instead)]

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)

Comment 2

[(not reading, please use [e-mail] instead)]

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.

Comment 3

[(not reading, please use [e-mail] instead)]

see new thread to n.p.m.mail-news

news://news.mozilla.org:119/[e-mail]

Comment 4

[(not reading, please use [e-mail] instead)]

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=1.37.2.1

[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

Comment 5

[(not reading, please use [e-mail] instead)]

[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

Comment 6

[(not reading, please use [e-mail] instead)]

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.

Comment 7

[David Hyatt]

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!

Comment 8

[David Hyatt]

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.

Comment 9

[(not reading, please use [e-mail] instead)]

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.)

Comment 10

[Håkan Waara]

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?)

Comment 11

[Don Crandall]

Very interested in a standalone mail & news reader expecially for Mac OS X.
Thanks for sugesting it.

Comment 12

[(not reading, please use [e-mail] instead)]

Attachment: some initial work, in patch form. not ready for prime time yet.

Comment 13

[(not reading, please use [e-mail] instead)]

Attachment: more of the patch, comments coming soon

Comment 14

[(not reading, please use [e-mail] instead)]

Attachment: new patch

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.

Comment 15

[Robert Kaiser]

Would this bug allow to go further in a direction of bug 115903?
This would be a really nice thing to have some time!

Comment 16

[Håkan Waara]

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?

Comment 17

[(not reading, please use [e-mail] instead)]

Attachment: still in "hack" stage.

Comment 18

[(not reading, please use [e-mail] instead)]

Attachment: more work...

see http://www.mozilla.org/mailnews/minotaur/index.html for info about this
patch.

Comment 19

[Brian Ryner (not reading)]

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).

Comment 20

[(not reading, please use [e-mail] instead)]

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.

Comment 21

[(not reading, please use [e-mail] instead)]

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.

Comment 22

[(not reading, please use [e-mail] instead)]

bryner's ideas spun off to bug http://bugzilla.mozilla.org/show_bug.cgi?id=163586

Comment 23

[[e-mail]]

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

Comment 24

[Brian King [:kinger]]

I think this bug is ripe for wrapping up, right?

Comment 25

[Dan Mosedale (:dmosedale, :dmose)]

Yes, this is clearly done (thanks mscott!).