Re: Icons of program

[robert havoc pennington <rhpennin midway uchicago edu>]

On Mon, 20 Apr 1998, Toshio Kuratomi wrote:
> SimpleVFS has two components: the meta-info component and the Simplified File
> Space component.  I think the meta-info component could be generalized into a
> parallel tree architecture which could then be used for any available
> filesystem.  SimpleVFS would then only be a Simplified FileSpace which VFS
> aware apps (like gmc) could hook into.
> 
> SimpleVFS would have an advantage over regular fs's in the meta-info area
> because it can only be accessed via VFS (since the VFS takes care of meta-info
> in the parallel tree, SimpleVFS meta-info should usually be up to date with
> respect to what's actually in the tree.)  However, the meta-info model would
> be the same whether the file was in SimpleVFS or not.
>

Yes, I think this is good. The meta-info component is what I just called
"2a" and the Simplified FileSpace is the "two partitions" idea.

In that last post, I was talking about meta-info implemented in each
directory, rather than as a parallel tree. I'm not attached to either way
of doing it, just whatever seems easiest. From Simplified FileSpace it
makes no difference, of course.

Perhaps it's just a matter of two config options:

1) Use meta info vs. See raw files (whether to hide .desktop
                                    files, use meta-info or not)
2) Hide Unix vs. See Unix (whether the root directory is / or ~/desktop)
 
Gosh, that seems awfully simple for all my verbiage earlier. :)

The "nesting" suggestion in my last mail gets at these two options, but
the only thing you set explicitly is the root directory; the rest follows
from that. I don't know which is more intuitive. What I suggested before
hides more implementation details, and lets you have a more custom
directory structure; but it doesn't let you see the raw SimpleFS
implementation as easily (you have to "mount" it). No reason not to do
both I guess.

> If this sounds okay to you, we could think about how the two components shoudl
> be designed to work in more depth. 

Yes, definitely. My last mail is kind of an attempt at that.

> (Should real files be allowed in
> SimpleVFS?  

In my other mail the answer is yes, because SimpleVFS is implemented as a
regular directory with meta-info. However, links can "point out" to files
in the real filesystem, e.g. to apps in /usr/bin.

The answer is essentially the same if parallel meta-info directories or a
database are used in place of local .desktop files; because there has to
be a real directory that the meta-info corresponds to. Still, there can be
pure links.

I wonder what happens if a file is copied from the regular filesystem to
the simple one, though. Is it linked or actually copied? Perhaps ask the
user?

> Should SImpleVFS be a special directory under the user's home dir
> by default, or the user's home dir? 

I'd say it definitely has to be a special dir, because otherwise it won't
coexist peacefully with non-Gnome Unix usage. Also you don't want
.bash_profile and the like showing up in Simple mode.

> How much overhead is there in a parallel
> tree?  How much in a database?  Could apps needing efficiency sync a db with
> the parallel tree?  

In Simple FileSpace there will probably be very few files, so I imagine
efficiency isn't a big deal.

There can't be too much overhead, though. If you're moving n files, at
most you have to move n meta-info files. So that's double the time, *if*
all you're doing is moving files on a single filesystem. Most likely
whatever you're doing is a function of file size (e.g. moving across the
network, grepping), and in that case the overhead of meta-info will be
negligible. 

However, for most efficiency-type operations I wouldn't think you'd use a
filesystem with meta-info. Most efficiency-sensitive tools won't even work
with meta-info, I bet.

>How would we keep the files up to date? and so on...)
> 

It's a big problem from the regular shell. I think this is an argument for
putting the .desktop files in each directory, not in a parallel one,
though it's not a complete solution.

Personally, I wouldn't waffle in the middle region here. I'd have GUI
directories and non-GUI directories on my system. But if people want to
play with it, might as well set it up so they can hack cp and write crazy
shell functions to move the meta-info along with the real files. Avoiding
this particular pleasure on my system is the main reason I'd be in favor
of the two clearly distinct kinds of file system, Simple and Unix. My
earlier mail is the best idea I've had so far on how to integrate the two
smoothly.

Hard problem - too bad we aren't starting from scratch like BeOS. :)
(Though starting from scratch might be bad in every other way!)

I'm going to bed before I type anything else.

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