[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KDE improvement suggestions
From:       Luke-Jr <luke-jr () utopios ! org>
Date:       2005-02-28 6:41:20
Message-ID: 200502280641.23008.luke-jr () utopios ! org
[Download RAW message or body]

On Monday 28 February 2005 02:06, Aaron J. Seigo wrote:
> On Sunday 27 February 2005 06:24, ziga@mail.ljudmila.org wrote:
> > > On Sunday 27 February 2005 01:56, Marco Martin wrote:
> > >> that is also the method used by nautilus for hiding files, so this
> > >> would also interoperable with gnome, that would be also nice
> > >
> > > do you have a URL to the spec, or a description of the behaviour to
> > > offer?
> >
> > There is something about hidden files at
> > http://www.westwind.com/reference/OS-X/invisibles.html
>
> yes, the OS X way of doing it; i was wondering about how _nautilus_ did
> it... google apparently says nautilus also uses .hidden files (same as OS
> X). this would be fairly trivial to add, really. but it feels a bit like
> blunt force trauma: suddenly the listed items aren't visible to anyone in
> the GUI (though the "show hidden files" setting could probably be set to
> override it easily enough) ...

.* aren't visible to anyone in the GUI either...

> but this still doesn't solve a few issues:
>
>  o bookkeeping: which directories are visible, which aren't?

The ones listed in .hidden, i would think?

>  o profiles: how do you make a directory/file invisible for one person(s)
> but not another?

You don't. I don't see my .kde directory visible to me but not to other 
people, or vice versa.

> in other words, how can we "kiosk" this? 

kiosk is about restricting what the user can do. Hiding things is not a 
restriction.

>  o working with the FHS: if we don't want to show /var, then /.hidden
> contains "var", but then how are users supposed to navigate to
> /var/www/html?

They aren't. If users should be able to navigate to /var/www/html, then either 
var shouldn't be hidden or there should be an alternate route (via a symlink)

> i wonder (for the second time in this thread =) if blacklisting really
> isn't such a great idea.

Hiding != blacklisting

> it puts restrictions on people that create documentation conflicts ("I was
> reading this HOWTO and it said to open a file in /etc but I couldn't
> find /etc!"),

And what if documentation says to open the .myconfig file?

> treats users like they don't own their system, 

How so? You can type in a path manually, and if you have access, modify 
the .hidden file.

> and really doesn't help with the problem of "we only want to see X, Y and
> Z". 

The problem, from what I can tell, is "we *don't* want to see X, Y, and Z" and 
this solves it perfectly fine. Inclusion for visibilities would have some 
pretty obvious problems... one being users creating files and not seeing 
anything happen.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]