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

[Aaron J. Seigo]

On Saturday 13 August 2005 09:47, Friedrich W. H. Kossebau wrote:
> Am Freitag, 12. August 2005 21:40, schrieb Aaron J. Seigo:
> > On Friday 12 August 2005 07:26, Friedrich W. H. Kossebau wrote:
> > > Am Freitag, 12. August 2005 10:17, schrieb Aaron J. Seigo:
> > > > On Thursday 11 August 2005 08:11, Gary Greene wrote:
> > > > > On Thursday 11 August 2005 05:26 pm, Aaron J. Seigo wrote:
> So we agree, fine. You say they are not in the user's home directory. This
> implies that all apps have $HOME as their base path, right? So what if all
> apps get a new base path, e.g. $HOME/files? Then $HOME/settings,
> $HOME/local, etc. won't be in there view, too.

because the average user should not be bothered with visible "settings" 
folders because the average user _does not know what to do with them nor how 
they got there_. one more time:

	there were people who deleted their Mail directory not knowing
	how it got there

files that users are not directly responsible for should not be visible by 
default to them. period.

as for $HOME/files all it does is create more hierarchy. this is a step 
backwards. as you note later on in this email the traditional UNIX system 
hierarchy is not user friendly and yet you want to create a more complex 
hierarchy in the most user visible area of all, their $HOME.

> > to keep files that the user doesn't create nor needs to manage directly
> > out of the way so when you do an `ls` you see just your files, not the
> > configurations for all the apps you use. it's a simple an effective tool
> > that allows applications a place to store files without making them
> > completely inaccessible to the user, without requiring a separate area on
> > disk one must manage with quotas and permissions and without cluttering
> > up the every day directory listings for users.
>
> The usages are nothing that could not be solved with separate dirs and
> metadata.

but we already have these things covered. and in a rather more foolproof 
manner. and without changing the initial directory a user sees in UNIX 
($HOME). 

> And added complexity. Pragmatism is only for short time solutions, it's a
> placeholder for the better solution once it is developed.

i suggest you look up the meaning of pragmatism then. i have yet to see a 
better solution proffered, either.

> I care because the moment I try to look at them I still do not see them due
> to a whole mess of hidden and unhidden files, funny as it is. Just have a
> look at your $HOME with "Show hidden" on.

you keep saying this and yet offer no reason for why this matters. is it a 
matter of it bothering you because you know in the back of your mind they are 
there?

> A plain user does not need to see those files? Well, as long as they do not
> need to tweak their system to circumvent/solve problems or change
> configurations that are not supported by a GUI wizard. We have human
> readable config files for a reason, don't we?

yes, emergencies and tweakfests. aka "corner cases". optimize for the common 
case, or "make simple things easy and hard things possible".... 

> > we do have more and more common locations for things, however. look at
> > ~/.local and ~/.kde for instance.
>
> Yes. But it needs to be standardized. Like so many things.

~/.local *is* standardized.

> > overcrowded? this isn't a housing project. all that matters is what the
> > average user sees in their day to day work.
>
> There is more that matters. Your average admin/homeadmin helping himself. I
> do not think you are proposing to create/keep a whole mess outside of the
> user's view and say "well, this is admin field, honey, you are clueless
> anyway.", aren't you? ;)

guy, if the settings were exposed do you really think that alone would make it 
any more accessible to the average home admin? no, it wouldn't. that's one 
reason we are creating tools like KConfigXT and layering things like config 
editors and backup tools on top of them.

> We could improve it. That is my point. There is need for an coordinated
> effort to structure $HOME a lot more. Now the mess is just hidden. It will
> smell badly one day. For me it already does.

we already do coordinate the structure of $HOME within KDE ($KDEHOME). where 
you seem to take exception is that we don't shove it in the face of the user.

as for the structure and contents of $KDEHOME there have been long threads 
elsewhere about separating some of the concepts that we currently combine in 
$KDEHOME/share/apps (data, some settings and GUI customization) and creating 
backup/restore/transitional tools.

if you wish to discuss those items, then i think there's something highly 
useful to go over. hidden vs visible is ... well .. rediculous.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050813/fcd4e68c/attachment.sig>