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

[Friedrich W. H. Kossebau]

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:
> > > this is not the common case. this is, actually, uncommon. most $HOMEs
> > > out there don't have binaries installed to them. so instead of
> > > enforcing a $HOME/files on _everyone_, why not provide for a $HOME/bin
> > > when and if you install programs in your home directory. that way we're
> > > effecting fewer people and providing a more sensible default: your home
> > > is where you keep your data.
> >
> > I beg to differ here, there are a NUMBER of users I know that do just as
> > James has stated. They install programs in $HOME.
>
> which is the wrong thing to optimize IMO for since it's not common and
> easily cased for with an applications directory. 

Which is placed where? Among the documents? 
And it is not so common due to bad support by the packet managers. Ever tried 
to install a package as plain user? The file system does support it, I can 
make a file executable. But the packet managers are admin centric. Bad. More 
power to the user. The need is there.

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

Can anybody tell why the hidden flag was invented at all? What does it achieve 
that cannot be achieved otherwise? The unix file flags do not even mention 
it, it's a (crappy) artificial addon. I guess it was introduced to 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! 

What is the (artificial) hidden flag used for? With the desktop environments 
we abuse it to implement file metadata (ignoring it's available in a lot of 
filesystems nowadays), see .directory, .thumbnails, .hidden. Also pipes are 
hidden away. And then there are config files. A whole mess of them. And data 
managed by apps (Mail) or DEs (trash, icons, ...). And other categories 
perhaps.

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? 

The whole file system hierarchie for users needs a rethought. $HOME is 
overcrowded. The hidden flag is not the solution. Separation of settings, app 
ressources, app managed data, user managed data (the plain old files), 
applications, whatever else, is needed. 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? ;)

I strongly vote for a more structured $HOME standard. With visible paths. 
Details left to working groups.

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/20050812/b4fb7484/attachment.sig>