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

List:       kde-devel
Subject:    Re: KListView, Dolphin and usability
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2007-02-16 19:21:35
Message-ID: er5080$p8a$1 () sea ! gmane ! org
[Download RAW message or body]

Mark A. Taff wrote:
> On Wednesday 14 February 2007 09:42:48 Aaron J. Seigo wrote:
>> a related possibility is stacking: defined drop zones where you can put
>> icons into stacks; when a stack is selected (e.g. clicked on) it "expands"
>> (hopefully with a cute animation) to show those icons primarily or even
>> exclusively. this is a form of fast ad-hoc tagging using a non-textual
>> interface.
>> this seems a more powerful concept to me than moving icons into amorphous
>> blobs on small (compared to, say, my real world desk) surfaces.
> 
> Now we're cooking with gas!  Call it a stack, bin, basket, cart, whatever.  
> This is an improvement I would love too see.

At some point there was talk of longhorn using a database file system. 
I'm pretty sure that didn't happen, but it would *completely* rock if 
KDE could do this sort of thing on top of normal file systems on a 
per-folder basis.

Ideas: What if it were possible to open a folder in 'iTunes/Amarok' 
view? That is, details view where the columns, instead of 'type', 
'size', etc are things like 'album', 'track', 'artist', etc? Now, expand 
this so that it uses some sort of configurable meta-data system that is 
plug-in aware. So as another example, I can open my photos directory and 
the columns would be 'date taken', 'subject matter' (e.g. 'family', 
'nature', etc, the point is the category and values are user-defined), 
'edited' (a user-defined flag), and so on. And, of course, any of these 
can *also* be used as categories in other view modes.

The point isn't that all of this should be done now, or even by the time 
KDE4 ships. The real objective is to make it /possible/ to do these 
things. Plug-ins would provide additional methods of supplying and 
editing meta-data (i.e. to use information from id3 tags or jpeg 
comments), but the main objective is to have a way to add arbitrary 
user-defined data to any file type (either through alternate data 
streams or more probably an index file). I think this is exactly what 
Aaron is thinking about already, so I guess I'm just pointing out how 
much this would absolutely rock. :-)

What would *really* be icing is if this applied recursively, i.e. the 
files could be organized on disk one way and presented in the same 
window as being 'in the same location', or even better if the 
categorizations became "virtual" folders. I think all of this should be 
do-able, especially since the main objective is to change how things are 
presented in a file browser. Maybe the 'virtual folders' thing isn't 
needed if categories can be collapsed and there is a 'collapse all', but 
it would be best if there was a way to have a category tree where the 
user can rearrange the criteria.

-- 
Matthew
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]