[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. :-)
Cheers,
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
- Re: Installer UI advices, (continued)
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/11
- Re: Installer UI advices, Markus Hitter, 2005/03/12
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/14
- Re: Installer UI advices, Jesse Ross, 2005/03/14
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/14
- Re: Installer UI advices, Quentin Mathé, 2005/03/15
- Re: Installer UI advices,
Markus Hitter <=
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/14
- Re: Installer UI advices, Markus Hitter, 2005/03/15
- Re: Installer UI advices, Graham J Lee, 2005/03/15
- Re: Installer UI advices, Jesse Ross, 2005/03/15
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/15
- Re: Installer UI advices, Quentin Mathé, 2005/03/15
- Re: Installer UI advices, Jonathan Isom, 2005/03/14
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/14
- Message not available
- Re: Installer UI advices, M. Uli Kusterer, 2005/03/15
- Re: Installer UI advices, Quentin Mathé, 2005/03/15