Re: Structure in $HOME

[Andrew Sobala <aes gnome org>]

On Mon, 2003-01-13 at 00:34, Seth Nickell wrote:
> 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).

Urm... that could work. But what if someone plays with opaque files in a
different environment to GNOME? You're still encouraging access to a
cluttered directory that could have uneditable files in it. Say, editing
a gconf file outside GNOME but with a GNOME app running, so gconfd is
also running. Breakage could ensue.

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

Performance and locking could then be a problem. The solution for "human
issues" is gconf-editor.

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

So to install a font you use the file manager, but to see a list you
have to launch a word processor.

> 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
-- 
Andrew Sobala <aes gnome org>