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

[Friedrich W. H. Kossebau]

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:
> > >
> > > better yet, that
> > > applications directory ought to be hidden and the apps can simply
> > > install .desktop files like good little citizens.
> >
> > So we better should convert /bin -> /.bin, /usr -> /.usr, /etc -> /.ect,
> > too?
>
> seeing as those aren't in the user's home directory and therefore they look
> at all the time in the user interface (e.g. KDE), of course not.

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. 

No need for the additional concept of hidden files. And if you are concerned 
about the localization, yes, I strongly support to add support for that, too. 
It's doable. 
And I would be only delighted if this would be extended 
to /bin, /usr, /etc, ... This is 2005. Those restrictions were needed in 
times where bytes did count. They do not that much, any more. 
(Only recently I heared that OSX has already something along those lines, is 
that true?)

> > Can anybody tell why the hidden flag was invented at all?
>
> 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.

> the files that applications tend to generate are usually not meant to be
> managed directly by users except in unusual situations. as a user, we
> shouldn't have to care that they exist and therefore they are hidden from
> normal view (though still there for emergencies or tweakfesting)
>
> pragmatism.

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

> > hide away (system files) from being listed. But does it scale? I always
> > get kind of shocked when I come across my $HOME with "Show hidden files"
> > on. There are more hidden files and directories than regular ones!
>
> if they are hidden, why do you care exactly?

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. 

It should be "Show hidden only". And then this made up separation could be 
easily also done by explicit separation in different directories. No need for 
the concept (featurism) of hidden files. 

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?

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

> > A funny exception is Desktop. It is treated both as a plain file
> > directory (by default being not hidden and in $HOME) and a ressource
> > managed by an app (KDesktop). Which now and then creates happy user
> > experiences, not. Should it be hidden, too?
>
> that was already covered in this thread.

Not. And even to cover things does not solve them, only puts them out of 
view. :P

> > The whole file system hierarchie for users needs a rethought. $HOME is
> > overcrowded. The hidden flag is not the solution.
>
> 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? ;)

> > Separation of settings,
> > app ressources, app managed data, user managed data (the plain old
> > files), applications, whatever else, is needed.
>
> we already do this.

And could improve it.

> > And presented unencrypted to the
> > user if he really wants to look next to his plain files. After all we
> > support open source, don't we? ;)
>
> we already do this.

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.

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/30ad99e4/attachment.sig>