Re: Structure in $HOME

[Andrew Sobala <aes gnome org>]

On Sun, 2003-01-12 at 23:21, Seth Nickell wrote:
> > I might want to back up all of my preferences, for backup reasons,
> > without backing up the whole galeon cache. For this reason, it would be
> > easier to have a single preferences directory to back up, with
> > application-specific data in separate directories after that.
> 
> Then the galeon cache probably shouldn't be a part of this structure. As
> I said, some sorts of data should probably still remain in hidden
> folders. The data should be "anything that makes the application work
> like it does on this system". That includes more than just
> "preferences", per se, but also things like the mail filters I've
> defined, the extra clipart I installed, or my web browser history. Its
> tricky to draw a precise line, so common sense should prevail. 
> 
> > So preferences could be stored centrally, and I could additionally back
> > up evolution (all my emails) but not certain other programs (eg.
> > galeon). Which isn't so far from what we have at the moment.
> > 
> > I don't agree that it should be unhidden though; I hate the way
> > evolution stores its data in an unhidden directory. A user shouldn't
> > need to access program data files 99.999% of the time - backups, that's
> > pretty much it. 
> 
> I claim this is neither reasonable given historical patterns, nor
> desirable. Hiding the "inner workings" of the computer behind a thin
> boundary has almost always led to problems. Windows is a clear testament
> to this, particularly in contrast to the Macintosh.
> 
> Windows has historically taken the approach of taking archane systems
> (and not just filesystem things, of course), calling them internals,
> hiding them, and presenting a friendly "GUI" that users can access to
> change things. When something breaks in Windows, mortal users are often
> pretty much screwed. When they want to transfer their mail to the new
> computer, they usually don't know where the mail is kept, and usually
> can't find it. When an application has a hidden menu bar and tool bar
> and they just want to throw away all its settings and "make it work"
> again, they usually can't.
> 
> By way of example, compare the Macintosh "System Folder" to the
> C:\Windows folder (which is its rough analogue):
> 
>   - The Windows folder is hard to "use" even if you know exactly what
> you are doing. If you don't know what you are doing, its a "useless" and
> potentially dangerous system internal, so Microsoft hides it. Visit
> C:\Windows and instead of a directory listing you get a "You probably
> don't want to be here" message and the option of continuing if you think
> you know what you're doing. 
>   - By contrast, the Macintosh system folder is fairly friendly, if
> often rather full. User's often add things to it themselves, and a
> surprising number of them know how to do a fairly complex task like
> disabling an extension. Most importantly, its very explorable: its easy
> to figure out things like how to add a new font, sound set, or how to
> remove an application's preferences and set it back to "ground zero".
> Macintosh users (even non enthusiasts) frequently demonstrate a much
> greater ability to administer, customize, and extend their computers
> than Windows users, and this in spite of the fact that many people use
> Macintosh precisely because they are not comfortable with computers.
> 
> 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.

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

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.

> Ideally, every file on the system would be intelligible to normal human
> users based on its name and location. *nix is waaaaaaay off here,
> probably farther than any other system, but at the very least we could
> reclaim the home folder for people again.

If you want to reclaim the home folder for people, why make config files
that they don't care about unhidden? I haven't touched .gnome* since 2.0
alphas. 

-- 
Andrew Sobala <aes gnome org>