[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: Mon, 14 Mar 2005 14:43:53 +0100

At 11:40 Uhr +0100 12.03.2005, Markus Hitter wrote:
Actually, .dmg's are no archives at all, they are disk image files.

Yes, of course. Adrian's comment sounded like .DMGs contained some special magic that was what made drop-installs possible, I just wanted to clarify that: All a disk image does when it comes to software distribution could be done similarly with any other kind of archive.

In fact, from a usability standpoint, disk images are worse, because the concept of a "disk images" requires that the user understand the concept of a "virtual disk". Just treating it like any archive, which is a file that wraps up downloaded files in a space-saving way, requires less mental effort and learning on the user's part. And the less users have to think when using the UI, the more brain power is available for the tasks they're actually trying to achieve by using the computer.

You can do drop-install with apps from zipped archives, or .tgz ones just as well.

Goal would be not to require any installation at all. With the .dmg mounted, you can run most well designed apps right off the mounted volume, without copying anything anywhere.

I do this quite often and after a few runs to figure whether this new app fits my needs or not, I possibly drag it over to a more appropriate place for long term usage. But most apps I try out disappear as soon as I unmount the .dmg. I was interested in testing but have no further use for them.

Yes, this would be the ideal case. But again, you don't need a disk image for that. A .ZIP archive would work just fine. You unpack the archive and run the app. All a .DMG does is add an intermediate step where the app is unpacked to a bit of RAM as you're running it. And for the reason mentioned above, I think .DMGs are not a facility worth emulating.

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.

Yes, I fully agree. The self-contained-package-approach is very desirable. But due to GNUstep's Linux/Unix underpinnings, there are currently pieces of infrastructure in place that require certain files to be in certain places.

Now, imagine we used an "on-launch-installer"-approach 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?

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. But for some apps, like those that talk to special hardware, or developer tools that need access to special hooks, we'll still need to mess with system files. This won't change until someone puts GNUstep and a GNUstep desktop on top of a specially modified operating system.

The advantage of built-in installers is that there could be special GNUstep packages for GNU software. Like some people are using Apple's PackageMaker to create installer packages that install a new version of PHP. It would be away to quickly port any FOSS project to GNUstep. Embed it in an AppKit-based configuration app, and installation is as easy as copying one file to your hard disk and launching it.

M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

reply via email to

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