Apologies if this appears twice - sent from the wrong personality the 1st time. Also a small correction applied to this version. ----------
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" The 1st and 2nd 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 _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
