[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
or
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.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.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, 2005/03/14
- Re: Installer UI advices,
M. Uli Kusterer <=
- 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
- Re: Installer UI advices, Benoit, 2005/03/16