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

List:       kde-usability
Subject:    Re: KDE improvement suggestions
From:       Ziga Kranjec <ziga () ljudmila ! org>
Date:       2005-02-28 19:10:03
Message-ID: 42236C8B.1050103 () ljudmila ! org
[Download RAW message or body]


>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) ...
>
>  
>
Adding a file to .hidden and doing refresh properly hides the icon in 
nautilus.
Doing the same in Finder doesn't, strangely enough...

There could be GUI for doing this in file properies dialog.

>but this still doesn't solve a few issues:
>
> o bookkeeping: which directories are visible, which aren't?
> o profiles: how do you make a directory/file invisible for one person(s) but 
>not another? in other words, how can we "kiosk" this?
>  
>
It would be interesting to see some actual use cases for this.
Blacklist is good, because it seem to be somewhat agreed upon;
more complicated methods are likely to be too KDE specific at this point
and it's really good for this kind of stuff to be more desktop/toolkit 
agnostic.

> 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?
>  
>
Location toolbar? Maybe also "Go to folder..." in the menu, for people 
who don't have
location toolbar enabled. Visually searching for stuff in / is quite 
slow, compared to just typing
(and then bookmarking) the location. Bookmarks for FS navigation are great!

>i wonder (for the second time in this thread =) if blacklisting really isn't 
>such a great idea. 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!"), treats users like they don't own their system, and 
>really doesn't help with the problem of "we only want to see X, Y and Z".
>  
>
As luke-jr@utopios.org alredady pointed out, whitelisting has the 
fundamental problem
of not showing new stuff, which can be extremely confusing to the 
unexpecting user.
Konqueror actually has a form of whitelisting already - "use index.html" 
view menu option.
But it is global, which makes  it somewhat less useful than it could be.
Now, if that would be settable per directory... (stored in file 
.directory file)
Another useful feature from usinng index.html that it provides for nices 
views than just
plain file listing - one can include some text and pictures, etc...

>in my case, if i had a view that 
>showed /home/aseigo, /home/music/, /home/kdecvs and /var/www/html i'd be all 
>set.
>  
>
Most common for me is probably going to /mnt to find removable disks,
which with automounter and no floppy inserted is somewhat annoying...
I find  navigating to these locations  much faster and easier with 
places/bookmarks/sidebar
(or just typing the locaton). Having different set of bookmarks in konqi 
and in
file selector doesn't help here (not to mention the gtk stuff)

Is there some spec for specifying sidebar in a desktop/toolkit neutral 
manner?

>i mean, WHY do people venture out of their home directory?
>by accident? if so, what do they do when that happens? 
>on purpose? if so, what are they looking for, and who/when do they get lost?
>  
>
Answers to these questions are probably *exteremely* important for choosing
the right stuff to put on the sidebar.

_______________________________________________
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]