Re: USER report, file-object hierarchies

["Justin Ross" <opiskin hotmail com>]

>5) gmc tended to be fragile, and didn't get a lot of use. As a
>   suggestion, when gmc is opened to my home directory, that
>   should be the 'root' of the left panel instead of the real
>   root. The left panel tends to have too much information, and
>   gets to be a navigation problem. There would need to be a way
>   to 'reposition' the root of the left panel, in that case.

I urge the same.  Why?

Because the FHS isn't simple, and its design has been influenced not 
only by the semantic relation of system files but also by practical and 
existing-technology-bound reasoning.  As an example, the / and /usr 
dichotomy apparently originally arose because the software had to be 
split on to two separate reels of magnetic tape.  Over time it the 
division became useful for separating system-critical and 
application-oriented software.  

Another example, the /var directory is a separate one (as far as I can 
reason it out) because its contents vary in size, and their use is high.  
Hence, it is a boon to be able to put them on a separate partition or 
storage device.  What's notable about this is that the categories into 
which the FHS splits system files are, while largely semantic in their 
organization (lib, bin, doc, etc.), also practical, and as a result 
unintuitive to the non-sysadmin.

It's notable that the HURD has the technology, and the developers have 
the intention, to eventually simplify the traditional UNIX file 
hierarchy into something relatively more intuitive.  They can do that, 
since Gnu is not unix.  Linux, I think we'd agree, is right close to 
being unix.

Given that Linux is unix, and that unix's file hierarchy is a bit of a 
bear, we should try to treat it with some discretion.  We should neither 
altogether obscure it (that would be annoying), nor should gmc show it 
all the time.

Let's do as he proposes and conceal it *when* the user is in the 
/home/nobody/ directory.  As I've proposed elsewhere, let's raise the 
desktop to its proper prominence: give it an icon, and use this icon in 
any path describing a directory under the user's home directory.  
Example:

  [#]/documents/work/foodstuffs.xml

And then let the sysadmin types turn it off, because it will annoy them 
to have some cutesy icon in their path.

Advantages:

  * it allows us to build a user-oriented file-object hierarchy
    starting from the desktop.  When gnome gets ported to different
    OSes, the user's hierarchy doesn't change.

  * the user's hierarchy can be completely semantic in its design. 
    As it will link in system resources, it need not deny the user
    of the features the system's file hierarchy exposes.  For 
    instance, the Gnome desktop may want to link in the info, doc,
    and man directories.  On another system, these directories may
    not be present, but whatever is there can be linked to the same
    interface: a "Library" folder on the desktop.

  * in general, it allows to define a single consistent interface in
    a world in which many file-hierarchy implementations are already
    entrenched in their idiosyncracy.

Note that what I'm (we're? maybe not) proposing is akin to OS/2's WPS.  
It had a nice file-object hierarchy.  Best I've seen.

Justin


So, rather than expose the user to all this

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com