An idea for integrating Unix filesystem and GUI

[Magnus Bergman]

On Sat, 29 Nov 2003 10:27:41 -0800
"Brenden T." <brenden at rcsis.com> wrote:

> James G wrote:
> 
>  > I think that this is unfortunate, and that the Unix file system is 
> not far from being suitable as the foundation
>  > for a GUI. ... I think that the addition of three new directories 
> within the root directory would be a
>  > significant step towards making the Unix file system a suitable 
> scheme for building GUIs upon.
> 
> Well, I like your idea, I think it has merit.  Certainly Apple seems
> to have had good success with a similar technique with their file
> browser.  Having a standard that OS file browsers could standardize on
> might assist Linux acceptance on the desktop.
> 
> Here's a few questions I have for the list:
> 
> 1. Is anyone working on anything similar?  It does no good I think to
> be redundant or work at cross-purposes, perhaps there is an existing 
> project that already aims to provide this feature.

I have thought about ideas related to this, at least aiming for the same
goal. That is to reduce the differences between what the file system
looks like and what the user sees. What the file system does is
arranging data in a tree structure. And what we want to present to the
user is data arranged in a tree structure, right? Instead of creating
something totally new here I believe the file system, with all its nice
features, should be used, and just extended then needed.

The reason the file system (root) looks like it does is because it's
following posix standard. If you don't like it you don't like the posix
standard. Many new ideas for gnu/linux based desktop systems have
solutions that are completely redundant to what classic unix already
provide (in some cases they may even break the posix standard). So why
not ignore the posix standard completely, throw out the old and bring in
the new?

It is fully possible to put whatever directories you want in the root,
and name them whatever you want. I have done it, it works well enough
(a minor amount of packages needs to be patched before it would work
perfectly). It wouldn't be too hard to create an experimental
distribution with the directory structure proposed.

Then it comes to extending the file system I have an idea called "file
system objects". Such an object is an extension to a directory, made by
putting a (hidden) file inside the directory. That file can contain:

o Localised names for the directory. But they are only translated if the
  real name matches a "common name" mentioned in the file.

o Icon name. Could be an icon located inside the directory (to make the
  object self contained) or perhaps an icon from the current theme.

o Actions (or predicates or verbs or methods) for the object. Actions
  such as "open" could be defined to launch a specific program or fall
  back to a default action (enter the directory). While some actions are
  directly inherited from the file system such as delete, copy, move and
  rename are directly inherited from the common file system behaviour.

But I don't think this should be tied to the desktop really, rather in a
layer underneath. It would make as much sense in a shell as in a graphic
environment IMHO.

> 2. Assuming that the answer to 1 is "no", would anyone be interested
> in seeing a standard for a "desktop file system hierarchy" developed? 
> Would anyone participate in such a project, at least for feedback and 
> critique?

What I would very much not like to see is a development of abstractions
upon abstractions. Keep it sane and keep it simple. I have seem more and
less horrible examples of where some thing has been implemented in one
layer and then left unused in a higher layer and then implemented again
in a layer on top of that (mainly in windows, but the madness is slowly
approaching the unix world too).