Re: Structure in $HOME

[Andrew Sobala <aes gnome org>]

On Mon, 2003-01-13 at 00:06, Seth Nickell wrote:
> > > Simple and visible beats complicated and hidden any day of the week.
> > > 
> > 
> > I'd say it should be simple and hidden, apart from things that are
> > easily user editable. So a fonts folder might be visible, if that's how
> > you install them, but things like mail filters for evolution should stay
> > hidden since they are really edited, unless you live in XML, by a GUI.
> 
> If its simple there's no point in having it be hidden. So I'll focus on
> a single use case because I think its easier this way. Lets talk about
> borrowing a friend's laptop for a week. How do you propose I get my mail
> filters, existing mail files, and preferably my server configurations
> onto the new computer? Add a menu entry or a button for saving mail
> filters somewhere? Then exporting my mail to a file and then copying
> that file?
> 

OK, in that use case a visible directory is best. But making it visible
encourages people to explore it - in cases like fonts directories,
that's a good thing. But some things are stored in a way that is just
not user editable - gconf is a good example, since IIRC the server
caches things anyway. And if the directory is being explored, people may
try to change files that they are not meant to.

So we have 2 aspects of having a visible folder:

1. Makes copying preferences and data to another computer very easy
2. Makes non-editable files visible

User-editable files and non-user-editable files have to be in the same
folder for (1) to work, and that causes the problem in (2).

> > > > Installing fonts and themes should have a reasonable
> > > > GUI.
> > > 
> > > Guess what the most reasonable "GUI" is for installing fonts and themes?
> > > Its already been developed, its called a "file manager". ;-)
> > > 
> > 
> > We have fonts:///. We could implement other user-installable items in a
> > similar way - themes:/// for example. It has the advantage that you can
> > merge several directories into one vfolder, which is the case with fonts
> > and themes (system wide + user installed).
> 
> 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.
> 

Agreed. But a directory will not list fonts on the X font server, which
people may want to know about.

> > But this should be done one, right, way, not by being implemented 6
> > different ways with 6! ways to break it. I don't know what the right way
> > is.
> 
> The right way is the filesystem. It already exists, its already user
> navigable. Why invent new ways that have to be discovered?

If the resources exist in multiple places, see above.

-- 
Andrew Sobala <aes gnome org>