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

List:       kde-usability
Subject:    Re: amaroK's file-browser
From:       Laur Ivan <laur.ivan () corvil ! com>
Date:       2004-11-04 17:35:40
Message-ID: 200411041735.42943.laur.ivan () corvil ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 04 November 2004 13:03, Mark Kretschmann wrote:
> On Monday 01 November 2004 18:28, Laur Ivan wrote:
> > imho users are used with the "filter" widget at the bottom of a
> > file-based complex widget (see file open/save dialog). Otherwise, you
> > could try a "highlight" filter (something along the lines of what firefox
> > does. I'd see it as:
> >  * focus of the list widget
> >  * start typing
> >  * a lineedit pops up at the bottom of the widget (containing what you're
> > editing
> >  * on edit signal do a scan on the listview's content and highlight the
> > matching (visible) entries (might need a separate thread if the list is
> > huge). a QDict with the names should be faster to see if you have at
> > least one entry matching your input
> >  * on a timeout (or mouse click/ enter), remove the non-highlighted
> > (non-matching) entries from the list.
>
> Hmmm.. In general I find this idea interesting. But, how would the user
> know about this filtering mechanism, i.e. type stuff into the widget to
> reveal the filter widget? Is that not rather confusing?
i guess it'll be confusing first time one uses it. however, i think it's 
different enough (and intuitive enough) that the Average Joe user will 
remember it for the next use.
you could go the other way and assume the user whats to do a search if the 
list widget is focused. A simple logic would be:
- if the user clicks on a list item => (s)he wants to do something with the 
content => filter pops up
- if the user generates a wheel event, then all (s)he wants is to browse (no 
filter pops up)
- if the user selects the scrollbars, browse again (no filter)

this is "off top of my head", but I'm pretty sure that a really simple FSA(*) 
can be designed based on what happens in the widget (i.e. maybe popping up a 
line edit @ single click is not such a good idea :))

(*) finite state automaton

>
> Keep in mind that we always show the filter line at the top in other areas
> of amaroK, like the playlist. So I guess there should be some consistency.
It's a valid point. I don't use amarok on day-to-day basis (although i find it 
to be a cool app). you could do the same filter technique in amarok too 
(would save some real-estate) ;-P

thinking in a "grand scale", you could use this approach for filtering all 
listviews. However, if a listview gets to be editable (aka there is a 
possibility of changing a file's name for example), then the behaviour should 
be changed to accommodate both types (single click => filter, double click => 
change the field's text ?)

>
> > i think kdevelop has something along these lines...
>
> KDevelop always shows a static filter widget at the bottom.
However, i think the static widget is triggered (i.e. is not displayed all the 
time by default). Also the scope in kdevelop is different: the source widget 
is an editor and you need an explicit trigger (otherwise, the keys are 
captured by the editor). The listview is non-editable in amarok's use (i 
think).

---- another approach
you could get the filter widget to be adjacent to the list (i.e. no spacer 
pixels between the lineedit and the listview), but it will hit the same 
problem (re placement - if it's on top, it will look like the rest of 
amarok's filters, but it will be very close to the url...).

What do you think?

Cheers,

Laur

[Attachment #5 (application/pgp-signature)]

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