[Rhythmbox-devel] Search Box Behaviour

["sean" <sean meluv net>]

After a quick browse through the archives, I hesitate to suggest this,
but:

How about changing the behaviour of the search box to allow multiple
keywords? I develop systems that, for historical reasons, rely on clumsy
lists with many hundreds of entries. Not a lot in terms of an MP3
collection, but a lot for our users to cope with. In addition, the text
in the list entry can be formatted in a fairly illogical way, making
simple/strict searches difficult.


The way I alleviate this is:


1) Preprocess the list entry before applying the search term. This
involves removing multiple spaces and punctuation, and ignoring case.

2) If a search term is composed of several text fragments seperated by
spaces, *all* of the fragments must appear in the list entry text for a
match to occur, but the order is unimportant

given:

"The Best Of Some Tedious Band"
"Tedium As A Way to Achieve Some Level of Relaxation"
"Is This The Way to Sleep"
"Time For Bed, Its Three OClock"

both will be matched by "ted som" or "som ted"

This gives us a loose sort of logical AND.


3) The pipe character, "|" is used to seperate alternate search terms
(loosely, logical OR)

This means that, for instance, the search term:

"ted best | clock"

would match the 1st and 4th entries.

"band | way achi | time"

would match the 1st, 2nd and 4th entries.

This relatively simple extension seems to work extremely effectively,
and its very easy to implement; split on the pipe and apply each term in
turn.


I also have a setting that allows the search term to be applied
automatically if it changes and there is a suitable pause, usually at
about 1.5 seconds. This allows the user to type the term, and when they
stop for breath (or just stop), the list is filtered, but they can carry
on to further refine if need be.

Generally lists of up to about 10-15,000 entries can be searched in this
way in a near interactive fashion (given lots of other criteria
concerning memory, processor speed, language etc. that I haven't defined
:)).
-- 
Sean Inglis