[RFC] "Documents Folder" icon in "system:/"

Gábor Lehel illissius at gmail.com
Thu Aug 18 18:30:43 BST 2005

Side comment: It's unfortunate how the people in the easiest position
to choose Linux over Windows, those who haven't used computers before
-- they don't have any investment in another OS, and thus zero cost of
"migration" -- are also quite unlikely to do so, as they naturally
have very little knowledge of computers, most probably don't even know
the concept of an operating system, so they just go down to the local
store for a computer, which comes with, you guessed it... Windows.
Those that know about Linux are already committed and don't want to
switch, and the rest don't know about Linux...

Anyways, I'll just weigh in with my opinion merely as a user (as some
have expressed doubt over whether such people exist), that I highly
appreciate the option as currently exists to specify a documents path
other than the default. I may just be a control freak, but I like to
have a seperate directory where my stuff, and _only_ my stuff resides,
that I can do whatever I want with, without having to worry about
unintended consequences. (It also has the advantage that I can create
hidden files of my own, without having them all jumbled up with the
rest in ~).

So, if I understand the proposals correctly...

Status quo:
- user (documents path) and system files (the distinction here being
not who has permissions to them, but who put them there) both in
/home/username; system files start with a "." and are thereby hidden
in most applications.
- correct location for things that are sort of both (placed there and
managed by an application by default, but the user may want to manage
them directly as well -- such as mail, desktop, and autostart)
unclear. hide them and have special systems/applications to access
them? or just show them and risk confusion? (currently, it's a mix)

New proposal:
- user files (documents path) set to a subdirectory of /home/username
(Files, Documents, semantics), open/save dialogs open here (konqueror
also?). clean slate; applications put _nothing_ in here by themselves.
- /home/username itself contains application-managed files; stuff that
the user would legimitately want to manage themselves (aforementioned
Mail, Autostart, Desktop, maybe others) unhidden, rest hidden (or
split out into a seperate visible Settings directory, but pulling that
off would require a social engineering feat of such proportions we'll
sooner have unified package management, so there's not much practical
point to considering it). if the user tries to delete something from
here (eg, an entire toplevel directory, not necessarily the contents),
they will be very sternly warned that it is a Bad Idea, if not
prevented from doing so outright.
So it might look like:
$ ls -A /home/username

Personally, I prefer the latter. Fewer ambiguities for one thing, and
it doesn't rely on an implicit agreement on the part of every single
application to put a . on the beginning of their files, and to hide
files with a . on the beginning. Getting 99% of applications to obey
this is possible (evidenced by it being reality), but getting 100%
would be at the very least hard, and until then the 1% will be causing
significant annoyance. (What Friedrich mentions is also a (somewhat
smaller) factor, namely that it can be disorienting when you enable
"show hidden files" and everything becomes a complete mess of your
files, not your files, hidden files, visible files... Konqueror here
is smart enough to sort them seperately, but other applications may
not be.)

On 8/17/05, James Richard Tyrer <tyrerj at acm.org> wrote:
> David Johnson wrote:
> > On Tuesday 16 August 2005 01:07 am, James Richard Tyrer wrote:
> >
> >
> >>I believe that the question at issue is only what to use as a
> >>default.
> >
> > Fair enough. But this doesn't explain why the Windows way is better than
> > the Unix way for a default. I remain unconvinced that there is a
> > problem with a plain traditional vanilla $HOME. I don't know of anyone
> > (besides you) who has ever complained about this.
> >
> > My work used to have Solaris/CDE on the desktop for all users. I've thus
> > had an opportunity to see newbies from Windows thrown into the "deep
> > end" of a Unix-only environment. My observation shows that while they
> > may have had problems with the ugliness and clunkiness of CDE, but they
> > never had a problem with a home directory.
> >
> >
> >>Yes, but ... (tm) it is newbies that defaults should be designed for
> >>since they will not start changing defaults as soon as they first
> >>login. When they are no longer newbies, they can change settings to
> >>suit their needs.
> >
> >
> > It is this philosophy which I have a problem with. Why must the newbie
> > be catered to? Why does the desktop design have to revolve around them?
> I thought that what I said was almost a tautology.
> But to answer your question: To quote Mr. Spock, because logic requires it.
> > I am completely in favor of sensible defaults. But they need to be
> > *sensible*. That means they need to be appropriate for both the newbie
> > and the advanced user, and everyone in between. In the case of defining
> > a Documents directory, $HOME is the sensible default.
> So, since you didn't answer what I thought was a very relevant question:
> > I do not have a Mac with OS/X so it would help if you described how it
> > does the directory tree for the user account directory and where it
> > stores user files.
> [Even snipped it out. :-|]
> I did some research and from what I found on Google, both current
> Windows and current Mac OS/X do not use HOME as the default location to
> store 'user files'.  Now it is true that they don't have the same method
> of not using HOME to store 'user files', but neither of them use it as
> the default location for 'user files'.  I think that either method is
> acceptable, but I see some advantages (for an open system) for the
> Windows method -- or better yet the current method which I use (with a
> $HOME/Files/Documents folder).  Even if the Mac OS/X method is better,
> we have to consider that it might now work as well on an open system as
> it does on the Mac, and that, therefore, something else might be better.
> --

Work is punishment for failing to procrastinate effectively.

More information about the kde-core-devel mailing list