Re: Installer UI advices

[Jesse Ross]

> BTW, the division between apps and frameworks, libraries, etc  in what
> regards a need for an installer isn't so clearcut. Many apps need to
> install files to different places, i.e. they are not self contained.
> They are apps, just not appbundles

I think this is really where the confusion is. We have three GUI-based
methods for geting an application onto our system:

 - Appbundle (drag and drop)
 - App (Installer-based)
 - Package (Installer-based)

Appbundle is straightforward. Drag it, drop it, double click to launch.
That's all the installation that's required, and it can be moved around in
the file system at whim.

Package is also straightforward. This would be used for CLI-based apps, I
would assume. Here the app (or apps) are bundled as a pkg or whatever,
double-clicked which launched Installer.app, then we track down where the
files were put and we run them. Easy enough.

The App is what Nicolas and myself are referring to. Here, you have an
application that relies on some external library. Perhaps it's part of a
suite, like Office or Adobe's Creative Suite, and there are a bunch of
apps with similar functionality, and the developer wants to move that
functionalty to a shared library. Here is where we see use of an Installer
framework.

The app is exactly like an appbundle, except it also has a package
contained within it called, I don't know, libs.pkg for example. Now in
order for OurApp.app to run, the contents of libs.pkg should be located
outside the Applications folder, in an Application Support folder or in
Libraries or somewhere similar. When you first double click on OurApp.app,
it checks to see if libs.pkg's contents are in that folder. If not, it
uses the Installer framework and starts up something that looks just like
Installer.app, but just starts installing the contents of libs.pkg where
they need to go. When it's done, OurApp.app starts up (because we double
clicked on it), and could, theoretically, remove libs.pkg from its own
bundle. Now, say we also have OurOtherApp.app, which uses the same
libs.pkg. When we launch it, it sees that the contents of libs.pkg are in
the file system, so it removes libs.pkg from it's own bundle, pulls in the
shared libs, and off it goes.

That way, an appbundle and an app behave exactly the same: drag and drop.
One just happens to run an installer on first launch, the other doesn't
doesn't. You get all the benefits of using a package installer, using
shared libs, and the only place you have bulk and extra disk space, is in
the initial, unlaunched app. Afterwards, the extra pkg is removed so you
don't have wasted disk space.


Is that any more clear?


J.