discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Installer UI advices


From: Frederico Muñoz
Subject: Re: Installer UI advices
Date: Sat, 12 Mar 2005 12:01:17 +0100

On 2005-03-11 18:56:12 +0000 Jesse Ross <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]