[Top][All Lists]

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

Re: Installer UI advices

From: Markus Hitter
Subject: Re: Installer UI advices
Date: Mon, 14 Mar 2005 21:54:51 +0100

Am 14.03.2005 um 14:43 schrieb M. Uli Kusterer:

Adrian's comment sounded like .DMGs contained some special magic that was what made drop-installs possible [...]

There is no special magic. Drap & drop works with every type of disk image like it works with every type of real disk.

[...] A .ZIP archive would work just fine. You unpack the archive and run the app. All a .DMG does is add an intermediate step [...]

It removes the step to unpack something. It removes the step to install something. It removes the step to remove the app in case you decided not to use it further. A quite common case, here.

[...] where the app is unpacked to a bit of RAM as you're running it.

This is done automatically, you can't really call it a "step".

[...] I think .DMGs are not a facility worth emulating.

All OS's I'm aware of support disk images already. You just have to use them.

Am 14.03.2005 um 15:46 schrieb Adrian Robert:

On Mar 12, 2005, at 5:40 AM, Markus Hitter wrote:
This scheme is only used for apps that don't require additional files.

It should be highly encouraged to design apps this way, even at the cost of some duplicated files/libraries/whatever. It makes handling the software so much easier and you won't have any headaches with different version requirements for the same framework/library.

In an ideal world, yes, but in practice there are certain resources that need to be installed in system-wide locations.

Libraries come first to mind, ...

You can put a copy of the libraries needed into the app's bundle. This is less overhead you might think: most libraries come with the system installed and you can rely on having them there or request the user to install this library package before.

... but there are others like info files, man pages, desktop menu or icon files, and so on. All of these must either go into a standard place on the system so that management and access applications (indexers, browsers, UI constructors, etc.) can find them.

Instead of modifying each app to work around system limitations, how about enhancing the system instead? GNUstep is in the fortunate position to be a system add-on. So, it could add automatic resource handling as well.

This could be fixed by developing a standard for bundling system resources inside an app and having some type of system scanning process pick up information on newly installed materials. But it's not easy to pull this off.

Agreed. Start would be to put something into NSApplication or the openapp utility telling the workspace manager "Hello, I'm here". This way you could make all your resource files available with a simple app launch without moving any files around. The workspace manager would check every now and then wether this resource is still available.

More ideal approach would be to scan every appearing volume automatically but this has to be done carefully to avoid noticeable system slowdowns.

How long would a "find /NewVolume -name "*.app/Contents/Info.plist" take nowadays? For full featured system volumes? For one-app image based volumes?

Uli again:

Now, imagine we used an "on-launch-installer"-approach ...

This would be quite similar to what I described above except the workspace manager would handle it instead of the app its self.

... as discussed in other messages for more complex projects that need this feature: It'd install symlinks to the necessary files in those system directories, and complex applications could be used like any other GNUstep application.

Admittedly, symlinks are too brittle for this to work in an optimal fashion (move the app, and the symlink goes dead), but maybe there are alternatives in Linux or Unix that perform a similar function?

All/most resource pools can be extended by modifying system variables: PATH, MANPATH, LD_LIBRARY_PATH etc.

For files elsewhere on the disk - design your app to avoid them. Generate temporary files as you need them. Generate preference files when it's time to store something. Try not to fiddle with system files, i.e. those in /etc.

For most end-user apps, these recommendations will work.

Great. :-)


- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter

reply via email to

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