[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: Tue, 15 Mar 2005 10:24:36 +0100

Am 15.03.2005 um 03:23 schrieb M. Uli Kusterer:

[...] from a usability standpoint, there's no difference

Agreed. Obviously some sort of installer allergic here. Most of the currently available installers put the files to absolute paths but this can be improved, of course.

OTOH, telling them that there is a disk (which to most users is a physical medium or device in their computer) inside a file, will confuse them, because it mixes the concept of files and physical storage media.

Since it's easy to handle (just double-click), they will learn quickly.

Why would I eject a file?

You don't eject the file, you eject the volume which happens to reside in a file. This is the same as handling a physical media, i.e. a CD.

Having the user explicitly install required libraries becomes *very* unwieldy and inconvenient when an application depends on more than one or two libraries.

Right. This is the same for .zip archived apps as for .dmg archived apps. Unless you have installers installing into absolute paths, of course.

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

Slowdowns are the least of my worries. Security is more of an issue. I don't think an application that has just been downloaded but not launched should be scanned. Otherwise it'd be the equivalent of AutoStart ... :-o

There's a little difference between scanning a bundle for what it contains and actually executing something. :-)

You are right, this has to be done carefully to not allow execution of unwanted code. You don't want to get this unknown app over there in the net to be used when you double-click a commonly known document. It's similar to setting the PATH variable mindfully.

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.

Yes. I don't really care which of them does it.

Well, the app is just unpacked/mounted while the workspace manager is already running ...

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

All of them?

I couldn't think of one which doesn't.

not all GNUstep projects are end-user apps.

You could start there.


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

reply via email to

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