Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #53 (new enhancement)

Opened 5 years ago

Last modified 5 years ago

Better feedback of entered search term

Reported by: stuarth Owned by: stuarth
Priority: major Milestone:
Component: Plugin Version: 2.2.2
Keywords: Cc: jpdesmidt@…

Description

This was an enhancement idea from JPdS.

Currently the search you've entered is only displayed numerically on line 1 of the player - eg when you search for ABBA you only see 2222 on the top line. It would be better if that search feedback actually showed what was matching.

Change History

comment:1 Changed 5 years ago by stuarth

Before the search has been performed (ie before you've waiting after putting in the previous character of the search), I don't think it's possible to show what is being searched for. This is because you only know 2222 means ABBA when you've performed the lazy match against the database.

However, once the search has been performed and there are results being scrolled through, then we could do better. I think this would proceed as follows:

  • Before any search has been performed, or after inputting a new search character before waiting for the search to be performed (ie during the pending period), then the numbers entered will be displayed on line 1 (ie as it does now).
  • After the search has been performed then line 1 is dynamically updated to show the text that is matching from the current item in the results list. To do that the current item would have to be converted to its lazy search equivalent, then a match performed against the display text, then the matching portion of the display text extracted to show in line 1.

This has the possibility that the line 1 text will change as you're scrolling through the results list, but that's probably OK.

This will probably be quite hard if the lazy result contains any text that is dropped by the lazification process (multiple spaces, punctuation etc), so that might mean it won't work on all but the simplest search terms.

An alternative is to perform that matching using a Perl RE against the TITLESEARCH attribute - that way Perl can tell us what characters of the current title matched and we'd avoid those kind of headaches. If no match was found we'll still be able to display the numerical result so would be no worse than now.

More details to be added when I've thought some more about it.

Note: See TracTickets for help on using tickets.