Improved explanation, I hope. (was Re: Icons of program)

[robert havoc pennington <rhpennin midway uchicago edu>]

[Toshio, I've been working on this re-explanation, and just got your
 response to my last mail, which I'll try to respond to as well.]

On Mon, 20 Apr 1998, robert havoc pennington wrote:
> 
> [this got long, sorry - if someone can summarize it better please do.]
> 

OK, shorter way to explain (and maybe thought out better). Sorry about the
mess. I think it's less complex than I thought.

Say gmc or GnomeFileSelection looks in a real Unix directory. 

1) If there's no .directory info, it assumes it's a regular Unix dir,
   and guesses at icons via filename, 'file'.

2) If there's a .directory file, the directory type will be recorded in
   it.  gmc reads the type:

 a) Regular Unix dir with meta information. For files with meta info, use 
    it. Otherwise fall back to what would happen in 1). This directory
    is meant to be accessible from the shell, though doing so requires
    some intelligence from the user to maintain meta info.
    There can be "pure links"  which point out of the dir into /usr/bin 
    or wherever, or to directories. 

 b) "SimpleVFS" dir. Not meant to be viewed from the shell. From the
    shell, it's indistinguishable from a). The difference is in Gnome's
    treatment of it. All Unix filenames are hidden; only files with 
    meta information are seen, and they are named as in the "Name" field
    of the .desktop meta information. Files without meta info are hidden.
  
So 2b is 2a plus special display requests - no big deal. 2a is the
meta-information approach. All three at once is the "SimpleVFS" approach. 

That's pretty much all I was saying before maybe. Now to explain why they
should appear as separate file systems or "partitions."

New idea - the three types of directory are nestable. By default gmc
starts in a special 2b-inside-1 implementation, .GnomeDir or Desktop or
whatever; this is the root of the simple virtual file system.

So I might have:

  Home/
  Gnome/
    Applications Menu/
    Startup Items/
  Trash/

as default directories of type 2b. As an implementation detail, these are
in .GnomeDir, but they appear on the desktop and are assumed to be
independent of the real filesystem.

Somewhere under the hierarchy, I could put a link to a directory of type
1 (regular Unix), which is my /home/hp directory, say called RealHome. In
this directory I'd see .GnomeDir. If I enter Home/RealHome/.GnomeDir, I'd
see the real implementation of the SimpleVFS:

Home/                           2b
  RealHome/                     link to /home/hp 
   .bashrc
   .xsession
   .GnomeDir/                   1
     Home/                      1 
      .directory                etc.
       RealHome.desktop 
     Gnome/
      .directory 
      Applications Menu
      Applications Menu.desktop
      Startup Items
      Startup Items.desktop
     Trash/
      .directory

You see the .desktop files because the containing directory is marked as
type 1. Nesting of 2b below type 1 is not allowed on the 2b "partition." 
So gmc has to be smart about how we arrived in this directory, i.e. via
the 2b "SimpleVFS" or the regular type 1 Unix fs. It's not circular
because a type 1 directory is assumed to be of homogeneous type all the
way down through subdirectories *in the SimpleVFS world*, i.e. from
the desktop. 

Now, if you start at the type 1 root (/), the nesting rules are reversed.
You can't have type 1 below type 2b. 

You need the "two separate partitions" idea to do the nesting properly,
and to make the default desktop clean and uncluttered by legacy Unix
files. This allows you to separate directories of type 1 from directories
of type 2b *implemented as* directories of type 1 - because the two are
indistinguishable except for the partition they are on. Simple Gnome world
vs. standard Unix universe. A toggle button flips gmc between them.
You can make either environment the "master environment," and have it
appear as a subdirectory(ies) of the other. You can also entirely ignore
one environment or the other, if you're a newbie or wizard.

2a is the meta-information approach. The problem is that it's confusing. 
It could as easily be called 1b - in which case you'd want to see the
.desktop files and not have "pure links" with no accompanying file.
gmc doesn't know whether to display everything, or hide .desktop files.
Thus the above toggle button, "two environments," etc.

But there's no problem having 2a in addition to 1 and 2b.  There is a
problem in having *only* 2a, because you lose a lot of the power and
flexibility you get from my scheme, since there's only one unified
environment. In my scheme, you can have only traditional Unix, only Gnome
simple, or either/both nested inside the other. You flow smoothly between
environments, or you can choose only one.  However, I don't think my
scheme is significantly harder to implement, though it's certainly harder
to explain. It's still just .directory and .desktop files. 

The whole thing is roughly analogous to devices and mount points, only
with a circularity or multiple-mount aspect.

Sorry about the earlier post, I hope this one is better. Thanks for
reading...

Havoc Pennington
http://pobox.com/~hp