Re: Installer UI advices

[Frederico Muñoz]

On 2005-03-11 18:56:12 +0000 Jesse Ross <jesse@jesseross.com> wrote:

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

Yes, very much so, thanks!

The idea is sound, and now that I got it I can even see it being 
implemented.

Let me make an example, using already available methods and terms. 
This doesn't mean that developing a proper API for it is out of the 
question, it's probably the way to go (e.g. add specific fields in 
Info.plist just for this sort of packages), but for now I want to know 
if I can describe it in pratical terms.

Besindes .pkg there is also .mpkg, a metapackage that is basically a 
collection of several .pkg's with some specific keys to describe which 
ones are mandatory, which aren't, and the overall relation and 
dependencies between them. This is usually used when an application 
has several components that can be all installed or can be customized 
(e.g. a GCC metapackage has gcc-lib, gcc, gobjc and gjc. One can 
choose to only install gcc, but that means gcc-lib has to be 
installed). There are also, for .pkgs' generally, specific scripts 
that, if present, are executed at the appropriate stage (preInstall, 
postInstall, etc). This are implemented as real scripts, I think that 
the only thing that matters is the return code, they could be shell, 
perl or StepTalk scripts. These are used do so some extra 
housecleaning and more custom tasks that can't possibly be streamlined 
and given a general API.

With this facilities, I can imagine an SomeApp.mpkg that, when double 
clicked, launches Installer, and trough a simple key tells it "Hey, 
I'm one of those bundle/package hybrids you heard on -discuss!". With 
this information Installer would not present a step-by-step UI, but 
instead jump directly to the actual installation phase. It would check 
for installed software (preInstall or preFlight, there is actually a 
page at Apple describing how to search for installed software even 
outside the regular places - using "find" I think). If some software 
wasn't installed, it would be installed (again, default values, no 
interaction, this is all one step, one progress bar, etc). The 
relocatable part of the app would be left where it is, and at 
postInstall the other "support" packages inside would be cleaned and 
the Installer specific files would be removed.

Would this be somewhat like what you are describing? The net effect is 
the same. It would also leave the possibility open for someone to use 
the regular interactive installation  if needed. In my example above 
the user would just clic the app, see the Installer doing some stuff 
the first time it clicked on the app, and then never see it again 
(exceptions to the "no interaction" can be someone that wants the 
license displayd and agreed to, this can be put on a key).

Again, this is using methods that will have to be implemented for 
regular packages. I like this idea, but also feel it's essential to 
keep a normal installation process in place. Some people will always 
prefer having some interaction with things than to put everything on 
auto. If the same overall method of doing shings are the same the code 
is smaller and much more easily managed.


Best Regards,

fsmunoz