Re: Importance of setting match_value when returning search results



https://bugzilla.gnome.org/show_bug.cgi?id=782044

On Tue, May 2, 2017 at 5:05 PM Robert Ancell <robert ancell canonical com> wrote:
On Thu, Apr 20, 2017 at 7:28 AM Richard Hughes <hughsient gmail com> wrote:
Hi,

I'm working on a patch that limits the number of search results to
around 50 when doing search-as-you-type. At the moment you can search
for "gno" and get 900 results, which takes a long time to refine and
then add as widgets. The user clearly doesn't want to see scroll
through 900 results, so we can just show the top few pages and then a
simple label saying more are available -- typically the user is
entering the next character anyway and the list never gets shown.
Limiting to 50 results turns the search-as-you-type back to being
responsive for all searches.

To do this, I'm thinking we should truncate the GsAppList results
after calling gs_plugin_search() on each plugin, but before we do the
gs_plugin_refine_app() calls. The issue is that to truncate the list
we need to order the high-priority apps at the top rather than leaving
the sorting to the UI side. The most obvious thing to use is the match
value which is populated according to what matched. For instance, if
the app name *and* the description match, the value would be
AS_APP_SEARCH_MATCH_NAME | AS_APP_SEARCH_MATCH_DESCRIPTION -- a
bitfield.

Most search results at the moment come via the various
GsAppstream-using plugins, and these already use the match value for
all the returned GsApp's. Plugins returning non-AppStream results will
need to set something appropriate here. If the search quality isn't
known, I guess you could use just MATCH_NAME although this might
effect how the results are sorted. Ideally you need to know how "good"
the match is.

The only plugin I don't know how to fix is snap, the others should be
straightforward. Questions welcome,

We don't have any information from snapd to indicate which part of the metadata matched though you could probably work this out by scanning the search results (they contain all the metadata). Also note that snap results are returned in importance order (as determined by the server side search).

With your changes will snaps get deprioritized compared to other packages? I guess the right solution is to scan the returned metadata to avoid this or change snapd to provide this information.

--Robert


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]