Re: Structure in $HOME

[Sean Middleditch <elanthis awesomeplay com>]

On Sun, 2003-01-12 at 19: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?

There's plenty reason for it to be hidden.  It's clutter.  There's no
reason to start adding 400 entries to my desktop (which is $HOME).

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

This isn't a fault of the URIs, but instead a fault of the default
layout in GNOME.  We have (had) that start-here:/// icon by default; a
*real* system uri (say, computer:///) with an icon on the desktop by
default, that links not only to application data files that 95% of
people will never use, but also to removable media,
preferences/settings, etc. would be a lot more useful.  It could easily
link to a fonts:/// and themes:///.  The font installation and theme
installation utilities could (and do, I think) have buttons for
launching these URIs.

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

Abstraction.  Making applications have to store "some data" in a
~/Data/$APPNAME folder, other data in ~/.$APPNAME/ folder, other
information in $prefix/$APPNAME/ folder, and then some, it's all a
serious pita.

Second, users do dumb things with folders.  I can just see someone
deciding the clutter of the Data/ folder on their desktop is too much,
send it to their Trash, then wondering why all their apps just stopped
working properly.

Alternatively, a nice data:/// URI with a link on the desktop, a user
can remove the link, yet the information doesn't go anywhere; just the
easy access, which the user obviously didn't care about anyways (or, if
she did, she can just add the icon back - either by making a new icon,
or by some hopefully existant "restore default icons" method).

All this URI has to do is map to file:///$HOME/.Data/ ...  Heck, if we
do this, we could even add special methods to the icon (for example,
right-click and select Transfer Settings to open a dialog for moving
them to a remote machine, or Backup Settings, or Restore Settings,
etc.).
> 
> -Seth
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.