Re: RFC: Common desktop-wide paths

Hi Maciej,

Today at 12:33, Maciej Katafiasz wrote:

> Dnia 02-10-2004, sob o godzinie 11:33 +0200, Danilo Šegan napisał:
>> It's common that configuration files are hidden in $HOME, so this
>> point seems moot.  Gnome already supports using $HOME for Desktop.
> That's big, ugly hack, not support.

Care to elaborate?  I cannot see a difference in behaviour apart from
my $HOME being shown on the desktop instead of $HOME/Desktop.

[I haven't looked into implementation — is that what you're referring
to as a "hack"?]

>> We do not want user to know about "Desktop folder" or something.  If
>> they can technically write someplace (i.e. $HOME), they should better
>> know that (i.e. make $HOME be Desktop) or they'll blame mysterious
>> forces or the system once they screw something up.
> How can you screw anything by having $Desktop != $HOME? You have _less_
> possibilities of playing around then. OTOH in case of $HOME == $Desktop
> if something is not hidden (not all folders under $HOME are dotted,
> and .hidden requires manual add) yet shouldn't be touched, and user
> "cleans" it (since she didn't put it there), _then_ you have mysterious
> screwup.

We have $HOME pointers all around the system.  Hell, Alt+HOME gets us
back to $HOME immediately from any Nautilus window.  Alt+Up will get
us to $HOME if we're in Desktop.

Ah, I see.  You're talking about an "ideal" situation where we don't
even have $HOME pointers in very visible places, yet I'm *not* allowed
to discuss the merits of $HOME vs. $HOME/Desktop in my "ideal"
situation of apps putting all their configuration data into dotted
directories?  I'm not any less practical than you are.

Of course, we still have the terminal application in Gnome, and they
open commonly in $HOME.  So, you start testing your newly-learned
rm-foo in your "own" directory (heck, you know you haven't created
anything useful there, it doesn't show up on "Desktop", so it
certainly doesn't exist), and guess what — you did screw up your
emails, contacts, whatever.  

Now, remember, if you want to improve by going the route of removing
Gnome terminal and $HOME pointers, you need to ack that we can also
go the route of removing non-user generated unhidden folders from
$HOME.  Latter approach means letting others fix their own problems,
and first approach means us fixing others' problems in Gnome.  I
prefer the latter, but you will probably disagree.

If we don't ask everybody to fix this problem for their own apps
(outside Gnome), and keep easy access to $HOME, it's easier to screw
up than if we ask everybody to (and they do) fix their apps.
That's what I compared in my "easier to screw up" analysis.

> Because Desktop != $HOME. $HOME is root of user-writable space, it's not
> meant to be presented as user's workplace in graphical way, nor is it
> traditionally organized as such. I for one have lots of cruft in $HOME
> (like ~/cvs/ for jhbuild checkouts, ~/opt/ for jhbuild target binaries,
> ~/bin/ for custom binaries overriding ones from /usr/bin/, and many,
> many others) which should not be on desktop. It's just like real home
> vs. desktop - home includes desktop, but is not equal to it. You don't
> use your dekstop to prepare meals, do you? Shoehorning $HOME into
> Desktop location is just silly.

Bad analogy.  "Desktop" — place we do stuff on.  $HOME — place we do
stuff on.  Your ~/cvs/ is where you do some stuff.  So is your
~/opt/.  Are you *really* expecting users who use JHBuild, not to know
about .hidden if they feel like it?  Now, if you ever want to do some
work on Gnome CVS, and those Nautilus CVS extensions get better (if
they haven't already), wouldn't you want to see ~/cvs on your desktop?
You seem to be comparing apples and oranges here.

I agree that traditional Unix directory/security model isn't the best
option here (it'd be way better to have two completely separate
"domains"/directories, eg. /configurations/<user> and /home/<user>—
this may be /desktops/<user>, the real name doesn't matter from
usability point, it's again implementation detail), but using $HOME for
configurations and $HOME/Desktop for user data doesn't go a long way
IMO: you still have a very easy way to get access to $HOME (easier
than it is to access dotted files and directories).

So, I consider your assertion of "$HOME is root of user-writable space"
to be true on Unix-systems in practice, but inappropriate for what you
seem to be aiming for.  We should not have "root of user-writable
space", since users should only be exposed to one, single "root of
user working space".  We have different ideas on how to solve that,
and that's all.

If you're to fantasize about $HOME being hidden from users, let
others fantasize about no-app being borken and producing non-dotted
files in $HOME.

FWIW, my $HOME/.hidden contains only these 4 lines:
  TeX # my local texmf, using TEXMFCNF, set up long before Gnome
  semantic.cache # Emacs Semantic extension generates these, I'd consider it buggy
  Mail # I haven't gone to the trouble of changing default Gnus "sent" mails directory; bug in Gnus anyway
  News # as above, pertaining to "drafts"

Everything here is of pretty "hackish" nature, I'd say, so I think
we're pretty safe on using $HOME for Desktop (i.e. most programs use
dotted folders).  If it wasn't so easy to add files to .hidden, I'd
probably set all of these as dotted directories anyway.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]