[Top][All Lists]

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

Re: Installer UI advices

From: M. Uli Kusterer
Subject: Re: Installer UI advices
Date: Tue, 15 Mar 2005 03:23:01 +0100

At 21:54 Uhr +0100 14.03.2005, Markus Hitter wrote:
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.

I don't think we're understanding each other here. I know how DMGs and ZIP files and all that work. But from a usability standpoint, there's no difference whether you

1) Download a disk image file
2) Double-click it to mount it
3) Copy the self-contained application from the disk image's window


1) Download the ZIP archive file
2) Double-click it to unpack it (the browser may do that for you)
3) Copy the self-contained application from the unpacked folder's window

What *does* make a difference, however, is that people will easily understand that one file wraps a few others in a box. Once they are out, they are just files. 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.

It's powerful, but damned hard to understand to non-geeks. In addition, getting rid of disk images after you've used them works non-intuitive. Why would I eject a file? On MacOS this works, because the way to eject a disk is to drag it to the trash. But I needn't get into why I don't like that idea.

[...] 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".

That's the browser's doing. For what it's worth Safari both mounts disk images and unpacks other archives like ZIPs and SITs. But users can turn this off, and they definitely see it happening (progress panels in all three cases), and as such it is a step.

Am 14.03.2005 um 15:46 schrieb Adrian Robert:
Libraries come first to mind, ...

You can put a copy of the libraries needed into the app's bundle.

Yes, which is encouraged and good, though it doesn't necessarily work with libraries that are shared by several applications. For those, we'll need a special case, I'm afraid.

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.

Having the user explicitly install required libraries becomes *very* unwieldy and inconvenient when an application depends on more than one or two libraries. That's why we have .debs and all that stuff in the Linux world.

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.

Yes, this is a good first start, and should be easy to implement. Would be nice if it was possible to just designate a few apps that get called whenever a new app is launched.

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

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

If something like Lucene, Beagle or Spotlight was added to GNUstep, I'd guess you could do all of this in one go. Index your files, find special folders in all apps...

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.

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

All of them? I have to say I've tried to avoid that corner of Unix/Linux so far, so while I've heard about the three you mention, are there other such environment variables for system startup items, daemons etc.? That would be a nice way. GNUstep could use some more reliable scheme to store references to the various libraries, and just resolve them into paths upon startup that get stuffed in the appropriate environment variables. On file system changes it would then re-generate this list of paths.

 Though I guess we'd still have to make this work on Windows.

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

However, not all GNUstep projects are end-user apps. There are also dev tools, drivers or "virtual drivers" so to say, and a lot of other junk that can't do without system files.
M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

reply via email to

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