Re: Structure in $HOME

[Seth Nickell <snickell stanford edu>]

On Sun, 2003-01-12 at 16:27, Andrew Sobala wrote:
> 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).

I would encourage renaming the GConf files in this case to something
more understandable than %gconf.xml (such as settings.gconf, for
example, with a nice MIME type registration that has a short
description). But remember that even in the case where you don't think
these files should be edited, that is they are opaque, deleting them,
copying them, etc can still be relevant. Where GConf does not allow this
due to caching, I think its a case where it would be much better if
GConf's design allowed for this (and indeed, had this been an early
requirement it probably could have, which is a great example of why
human issues need to be considered early, even in very deep down
technical things). 

However, that said, the files could easily be made editable (remember
that with MIME type stuff they don't have to show up as text/xml files).
Why not have double clicking on them open the relevant node in GConf
editor?

> > > > > 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.

If you're want a list of fonts, I think most people already look in,
well, one of the font lists available in say AbiWord. This is mostly for
the case of customizing or extending the system. Aggregate filesystems
like fonts:/// solve certain problems, but they can also be very
confusing. They don't always behave in a simple predictable manner (one
just has to look to applications:// to see all the quirks involved in
trying to merge all this info together *AND* allow user
additions/customization/etc).

-Seth