83705 - Mozilla should be distributed as a bundle on Mac OS X

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P4)

Description

[Mike Akers]

Most Mac OS X applications are distributed as application bundles (a described
on page 101 of <a
href="http://developer.apple.com/techpubs/macosx/SystemOverview/SystemOverview/SystemOverview.pdf">the
Mac OS X system overview</a>

Bundles are nice because:

<ul>
<li>They appear as a single file in the finder</li>
<li>Installation, relocating and uninstallation is as simple as dragging and
dropping the bundle</li>
<li>All support files for an application along with different versions for
localization can be stored in a single bundle</li>
<li>It's more "Mac OS X like"</li>
<li>Omniweb and IE are bundles now, mozilla looks kind of old fashioned</li>
</ul>

I don't know how hard it would be for mozilla to be packaged in a bundle, but it
would be a great feature to look into.

Comment 1

[Boris Zbarsky [:bzbarsky]]

over to build config

Comment 2

[Jon Granrose]

over to mac guru jj.

set to future since we have a MacOS X system before we can worry about bundling
it for it.

Comment 3

[Henri Sivonen (:hsivonen)]

Granrose: I'm not sure I understand the reason for futuring this. Do you mean a
separate build system for Mac OS X is required first? Couldn't this be
implemented as a post-processor script in the current Mac build system for the
time being?

Comment 4

[J.J. Enser]

Jon, this represents little work (flipping 1 bit, maybe adding a file or 2).
We're about to start posting daily fizilla builds out to mozilla.org and the 
tinderbox will also move to the tier1 page at some point before moz1.0, so I 
think it's pretty safe to target it for mozilla1.0

However, this is only cosmetic, so functional bugs will always have priority, and 
God knows how many of those we have ...

Comment 5

[Jon Granrose]

sounds good to me.  At the time the MacOS X future was hazy so I future'd it,
but since things are picking up 1.0 sounds like a good target even if it slips a
few times between now and when it's fixed.

Comment 6

[Adam Masri]

Here's a good overview of bundles & application packages.

http://developer.apple.com/techpubs/macosx/SystemOverview/SystemOverview/Bundles/index.html

This note mentions that you can create a single application package containing
OS 9 & X applications.

http://developer.apple.com/technotes/tn/tn2003.html#overview_pack

It would be pretty cool if there was such a Moz package, for people that need to
boot into OS 9 & X - they could have a single icon that would work in either OS.

Also, in case you guys want to get fancy with installers...

http://www.stepwise.com/Articles/Technical/2001-05-11.01.html

This is a good article that covers benefits & problems with the different
available installation methods for OS X, including problems with Apple's
built-in installer.

- Adam

Comment 7

[Steve Dagley]

Adam, funny I wuz just looking at the bundle docs for plugins under OS X :-)

Just to add my $.02, we're only interested in OS X bundles as OS 8.6/9.x is not a 
supported config for the Carbon version of Mozilla (we may run but as I said it's 
not supported and there are issues such as our custom memory allocators not 
working under Carbon on 8.6/9.x).  And the bundle would only be for the complete 
install version as the configurable download installer is not going to generate a 
bundle on the fly.

Comment 8

[finlay.dobbie]

You could create a bundle for the classic version, you know. Or even a megabundle for both classic and carbon...

Comment 9

[J.J. Enser]

After testing the new OSX bundle packaging, some changes need to be made to
mozilla.plist/netscape.plst in order to support the following feature:

- add a 'CFBundleExecutable' key to enable the launch of the app when double
clicking on the package
- change the 'CFBundleIconFile' value from a resource number to a file name for
the package to display the 128x128 high definition icon
- add a 'CFBundleGetInfoString' key to allow the Finder to display a version
string in the Get Info box.

I'll be submitting a patch to both Mozilla & Netscape accordingly.

Comment 10

[J.J. Enser]

Attachment: Patch to mozilla.plst enhancing OSX package support

Comment 11

[J.J. Enser]

We also need to check in the large icns icon in a separate file to package it as
/Resources/Mozilla.icns

This and the previous patch should go on the trunk AND on the 0.9.5 branch

Comment 12

[Mike Pinkerton (not reading bugmail)]

is there a way that we can keep the current plst for the physcial app and create
a new one for the package? I don't want to break the icon/etc for the app itself
since that's what developers get during builds. 

The downside to this is that unless we strip the extra stuff from the executable
when we ship, we will ship a 'icns' and a 'plst' that total to about 60K. How
easy is it to strip that in the packaging automation, or perhaps we can just do
a separate target in appRunner.mcp for package vs. stand-alone app.

Comment 13

[J.J. Enser]

Mike, I'd rather not duplicate information unless it's absolutely necessary.
It's going to be a headache to maintain both flavors of the plist, of the icon, etc.
Ultimately, the OSX bundle packaging should be part of the standard build script
and the release automation should be limited to adding the read me file and
creating the disk image... but we're not there yet.

For the upcoming Netscape release, I can use a "local" plist & icns file and we can 
work on a "standardized" plan for the trunk after that. What do you think ?

Comment 14

[J.J. Enser]

Mike says it's ok.

implemented with today's delivery, available at:
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-10-11-04-0.9.4/MozillaforMacOSX.smi.bin

marking fixed!

Comment 15

[Jason Kersey]

Verified.  This is excellent!

Comment 16

[Adam Masri]

This is very cool, but there are two minor problems. The 'Plug-ins' & 'Search
Plugins' folders should be outside the bundle, as they are more likely to need
direct access by the user. I don't believe the other folders need direct access,
but I'll leave that to others to decide.

- Adam

Comment 17

[Steve Dagley]

No, this bug is fixed.  If something needs to be added to a folder inside the 
package the user can be told how to do that.

Comment 18

[Greg K.]

I agree. Since Mozilla will happily use Systemwide Plug-Ins and Sherlock
plug-ins, it's not necessary to prominently feature Mozilla's versions of these
folders.

Comment 19

[Mike Akers]

Great job guys! This is just what I had in mind when I submitted this bug. Keep
it up!

Comment 20

[Adam Masri]

Here's why this bug should be reopened, and those folders should be moved out of
the bundle.

Bundles take the place of the single double-clickable application. Instead of
having tons of library files that are likely to only be updated at the same time
the application is, why show them and confuse the user? Bundles hide all this
stuff behind a single icon, so it's far simpler for the user to see, move, or
delete the application from their computer.

When should a folder NOT be part of the bundle? When the folder contains files
that the user may wish to directly manipulate, that may or may not be updated
when the application is updated.

1) Internet plug-ins don't all work on every browser. The global Internet
Plug-ins folder in /Library & the user's plugins in ~/Library are very cool for
global plugins that can be used by specific users, or all users, but this
doesn't cover an instance where a plug-in is designed to work in a specific
browser. The Default Plug-in is a perfect example of this. Would this plugin
make sense on any other browser? There may be future plugins that are
specifcally designed for Mozilla and no other browser. It makes no sense to
place these in a global Internet Plug-ins directory that may cause other
browsers to crash. Therefore, the user must have access to this directory.

2) The Search Plugins folder has individual search files. Some websites may
begin distributing these plugins to be used by Mozilla; their directions may
state to "place this file in your Search Plugins directory." An OS X user with
no terminal experience will have no clue how to do this.

Packages are very cool, but not when you're taking away functionality from the
GUI. Asking a user with no terminal experience to start doing mv plugin
/Applications/mozilla/mozilla.app/Search Plugins/ is ridiculous, when the user
could very easily drag the icon into a specific directory. Mac developers
wouldn't expect a user to dive in with ResEdit on a normal commercial app to
make a simple change; for that same reason, we shouldn't demand terminal
knowledge either.

- Adam

Comment 21

[J.J. Enser]

Let's discuss this in a separate bug please. This one was about implementing OSX
app bundles which has been completed.
marking verified again, as per Jason Kersey's comment @ 2001-10-11 12:16

Comment 22

[Steve Dagley]

To prevent having a separate bug logged since we're not going to change anything 
I'm gonna add my final comments here:

No special tools like ResEdit are needed to peek into a package.  Just ctrl-click 
on the app package and select "Show Package Contents" and the Finder gives you a 
folder view of the package.  We are not going to move any folders out of the 
package as we have a specific search hierarchy for folders based on their 
position relative to the application itself.  There are also installers that 
assume the same hierarchy.

Comment 23

[Adam Masri]

Huh, I didn't know you could do that. Live 'n learn.

The work is excellent. Thanks very much, this is a nice addition.

- Adam

Comment 24

[Marcus Pallinger]

Is this workin fro the trunk builds yet (or is that another bug?)

Comment 25

[J.J. Enser]

No this doesn't work on the trunk yet, but it will soon.
Automation changes need to be applied to the trunk build mac.

Instead of creating a new bug, we can just add the apropriate keyword to this
one. Since I'm not sure which one to use (vtrunk?), I'll let someone else do it.

In any case, trunk OSX builds will start to be delivered as an app bundle
wrapped in a disk image within a week.