Re: Icons of program

[Andreas Kostyrka <andreas ag or at>]

On Thu, 23 Apr 1998, Toshio Kuratomi wrote:

> Item: The GUI filemanager needs metainfo (in .info files if you're raster, in
> a db if you're Fred Bacon.)
It's not just the filemanager. A app needs also metainfo that isn't to be
considered the data file proper, at least to store it's configuration when
the file was saved. (This is VITAL for session management to be useful.)

> 
> Item: The shell does not need metainfo
> 
> Item: People new to UNIX are going to use the filemanager and not the shell.
> 
> Conclusion: Putting metadata into the filesystem alongside the regular files
> is the wrong way to go about this.  Users who only use the filemanager are
Don't know how you get the conclusion. Most advanced users will probably
be in the position to use both.
For some things a proper UI may be nice, ... But other things are best
done in a shell.

Additionally, you seem to be mistaking the metainformation as a pure
filemanager thing. This can't be so:
-) the desktop needs the same informations. (And propably even more.)
-) It's not just the filemanager, that needs metainfo, but also the apps
   to cleanly store things that are associated with a file, but are not
   proper data for the file.

> never going to know where the metainfo is anyways.  People who only use the
> shell are not going to have to look at the extra .info (actually:  have to
> have another name -- .info's already taken :-)  files.  People who use both
> the filemanager and the shell are the only losers, but they're the loser's no
> matter what -- They will always be forced to move their metainfo along with
> their files, whether the metainfo is in the same directory, another directory,
> or in a database.  Sometimes having it right next to the real file will be
> better (cp gnome* public/) other times it won't (cp gnome*html public_html/).
This actually would work with .info file schema:
cp gnome* public/
  copies gnome* including .info files.
cp gnome*html public_html/
  copyies only the data html files proper into public_html.

> what we should do is provide tools to move metainfo along with normal files
> (we could hack cp -- or we could simply provide a shell script) -- People
> unconcerned with metainfo can go on using cp, mv, etc and not care whether
> meta-info is there or gets lost.  People concerned with such things can use
> gcp gmv etc....
The problem is, that you don't want to care about metainformation as such
in normal day operation.

That's why I'm proposing to embed the metainformation in all possible
cases in the file proper.

> (I think we should think about leaving hooks for both db and file-dir
> meta-info, and whoever has the time and will to code the backends is welcome
> to do it and we can judge relative merits then.... What I am against is .info
> files in directories alongside normal files.)
Nope. Having them in a global db is bad: There are two things that can go
wrong. And you will probably forget to tar the metainformation on tape
when you are moving some files from site to site, if the information is
tucked away somewhere.

Additionally, I'm not that sure that users should be ``allowed'' (by
shadowing directories) to modify the system directories tools.
This way, every standard tool looks the same, no matter if it's my
account, or that of a client I'm trying to explain something :)

(If you don't like to icon for netscape or so, than make data symlink and
 but an overriding .info on your desktop.)

Andreas

PGP signature