Re: Icons of program

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Fri, 24 Apr, 1998 at 03:22:34PM +0200, Andreas Kostyrka set free these words:
> 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.)
> 
This is true.  But that doesn't change my analysis one whit.

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

In another part of the discussion (forgive me, I thought I included some of
that here, but didn't.  Must of fallen aslepp first :-) I stated reasons for
this.  People who only use the shell shouldn't be forced to look at
all the clunky info files sitting around in directories.  This is very
intrusive.  A single-user machine's admin may decide to delte all the .info
files (takes some time since they're spread all over the machine [well machine
intensive, anyways... `find` can do it.]) but will then find that when someone
releases a new package that installs .info files, he'll have to go through and
delete files again.  
> 
> > 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.
> 
That's exactly what I mean by brokenness.  It doesn't act the same way in both
cases.  I know why it doesn't act the same way, but one shouldn't go around
saying that .info files work with the standard command-line tools when it
doesn't.

> > 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.
> 
But that doesn't work for all files.  non-ELF binaries, certain image formats,
etc.  Plus you need a special decoder for each type of file that you include
the data in.  This is a bad idea. (It does solve the movement problem
though:-) The real place to "embed info in the file" is in the filesystem
layer; but this isn't going to happen for us (unless we all switch to hfs when
linux-2.2 comes out and convince the other *nix systems to do the same:-).
most of the proposals here will embed into the VFS layer of various apps (I
think Miguel once mentioned that the VFS layer in mc could be extracted out
into a library as part of this....) So any app using an aware VFS will be able
to operate transparently on meta-info. 

> > (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.
> 
Indeed possible.  But the benefits may outweigh the pains for some users.  by
leaving in hooks, individuals can choose to play around with various backends
until a clear winner comes to the fore (or no clear winner comes to the fore.)
In all cases -- the files and meta-info associated will be the same, as will
the API a program uses to store and retrieve the meta-info.  Only the method
of storage will differ from machine to machine.

> 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 :)
> 
Customization is a very integral part of the *nix experience for me.  I
suppose we just have differing opinions here.

-Toshio
-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

PGP signature