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

Sat Aug 13 21:15:26 BST 2005

Am Samstag, 13. August 2005 18:49, schrieb 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 

Like all the things outside his $HOME, of course. Pardon. Direct them per 
default always to $HOME/i18n(Files), e.g. by giving them a proper setup for 
Konqueror (sidebar starting there, start button) and the file dialogs 
(default location, bookmarks). And they will feel at home there with their 
files. And not see the settings and app managed ressources.

> 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

Won't they delete Desktop, too? public_html? And all of those hidden files, 
once they accidently or being curious checked the menu entry "Show hidden 
files" and do not remember how to turn it off? 

Now get why did they delete Mail? Because perhaps it was in their place. It 
was where they thought they have full control, where only their files are. 
The place they were directed to by the file managers to store _their_ files.

Out of experience and therefore broader expectations I tend to say this will 
far less happen with $HOME/i18n(Files), only at the rate of people who delete 
the hidden files. And this could be catched by file managers and/or readonly 
flags (well, then they can catch the deletion of hidden files now, too.)

And then there are smart people who delete .kde, because they think, by the 
dotted name, it only contains settings.

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

Totally agree. But we have different solutions.

> as for $HOME/files all it does is create more hierarchy. this is a step
> backwards. 

Hierarchy to gain order. Oh, and rather forward.

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

Visible due to the file managers' defaults. When they start at 
$HOME/i18n(Files) I do not see how more complex this is to a user than $HOME. 
It even tells them "Here your files." The separate directories solution even 
makes things less complex having parallel structures, global and per user. 
(Per group would be nice to have, too).

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

Sees where? In a login? Can be changed. In Konqueror? Can be changed. It is 
doable. No technical barriere.

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

It may be rather my perception of pragmatism. It is too often, IMVHO also 
here, rather resignation to the results of uncoordinated activities instead 
of taking the hard way to give something a proper solution. 

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

You don't see those? Oh, it may be because I rather tend to produce randomized 
strings of letters and even full words. Thanks after all for answering. ;)

> is it a 
> matter of it bothering you because you know in the back of your mind they
> are there?

Yes, and they are attacking me. ;)
It is because it came across my way too often. When backuping my files (and I 
differ between data files and settings) the whole bunch of settings always 
trashed things a little. And fetching app managed user data out of the 
settings/ressources also needs more extra work than it really deserves.
And when searching for some config file/directory in $HOME I am (was) always 
confused by all the non-hidden and hidden stuff mixed up in Konqueror and 
looking so differently. So for me it is the pure wisdom to separate these 
things because it will at least easen my work. And it did, for half a year 
already.

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

True. I miss to see how hidden files are the optimum. Separate directories 
aren't, too, but they have more advantages.

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

That standard is a dot file, perhaps? I asked ms. google but she did not tell 
me. And with the LFHS it seems not to be mentioned, too: 
http://www.pathname.com/fhs/pub/fhs-2.3.html Could you please help and 
enlighten the standard? Why is .kde not merged in but makes up its own 
hierarchy?

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

Next to pragmatism is also realism, right?. And realism will tell us that all 
those tools will sadly never ever be enough. Period. Think yast.

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

It would not be shoved more than the rest of the installation is.

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

Thanks for the pointer, am aware of that. Nothing ready to throw into the 
discussion right now on my side. But it already assures me that the separate 
directories solution is the way to go.

> hidden vs visible is ... well .. rediculous. 

IYHO. Everyone scratches his itches. Some of your itches may look ridiculous 
to others, too. ;) 

Regards
Friedrich
-------------- 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/6d727a63/attachment.sig>