Re: Structure in $HOME

[Mike Hearn <mike theoretic com>]

> And how do you propose that users find about fonts:///? If you're going
> to put links somewhere, you might as well just have a directory. Its
> simpler, its less error prone, and its easier to develop a conceptual
> model of. At least Nils (Sun usability engineer) and I have been fuming
> about the URIs. They can't be easily discovered, and they're relatively
> complex. They're not a solution, they're a problem.

URIs are fine IMHO, they are far more flexible than file paths. The
filing system as we have today is far too limited, if we start trying to
use directories as views then we'll run into issues because raw
directories aren't programmable.

Now, it'd be cool if they were, definately a project for the future (I
believe reiserFS does some stuff in this area) but out of scope for this
project.

It *is* too hard to discover URIs at the moment, but that's because the
filing system isn't properly abstracted. Have you ever seen the file
path for Dial up Network in Explorer? I have, it's horrible. References
to COM objects abound. Nonetheless, it doesn't matter, because for the
user DUN appears to be a part of the filing system (hanging off my
computer). You can drag objects into and out of it.

The Mac way of integrating stuff with the filing system has several long
term issues I think - for instance a frequent question I get at the
autopackage project is why we aren't using appfolders. Well, that causes
big problems because there's actually more to installing software often
than just copying a directory (mostly dep resolution, of course there
are other issues but they could be worked around). 

So - my point is that the filing system technically is not strong enough
to present information as files and directories at the moment, so a URI
based VFS is the next best thing.

Really I think perhaps the start-here:/// uri should be extended - it's
on the desktop by default, is labelled in a way that should invite user
curiousity, so they can discover new directories and such that way.

The main problem is that the Linux VFS situation is split, there are
apps that don't use a VFS, some use KIO and some use gnome-vfs, which is
pretty confusing for the poor user.

Implementing fonts as a directory in ~ wouldn't really work too well for
reasons others have mentioned, system/user fonts, XFS compatability etc.

> The right way is the filesystem. It already exists, its already user
> navigable. Why invent new ways that have to be discovered?

Well in short because the current system really sucks?

I think the closest thing to what you want would be widespread adoption of LUFS,
which lets you easily write filing system "plugins" that can be mounted as
normal filing systems, so you could have ~/System/Fonts be mounted like the fonts
view in nautilus, it gives you programmable directories in effect. 
In fact LUFS can already use gnome-vfs. Problem is that it's linux specific :/

Oh, about the directory names, remember that the cryptic names have benefits, 
for i18n, as a lot of unix software depends upon the current names. The solution
windows takes is to have APIs for finding all the directories you might need, so
if Program Files gets translated apps still work (in theory). So ~/.prefs or
~/Choices might sound good, but it takes quite a bit of work to make them i18n-able

thanks -mike

-- 
Mike Hearn <mike theoretic com>