GitLab

(cherry picked from commit e8623c019b763406afbb44dd0f5123d15c90fb44)

Depending on what we are doing with the search results sometimes we want to
prioritize certain types of applications.

When we run the search provider we return up to 20 results to gnome-shell and
then gnome-shell typically chooses only three to show. This means it's a bit
more critical how we sort the returned list as we only have three tries to get
it right.

For the case of the search provider, make sure we show available desktop
applications first and order them by how well they match the search term.

If the caller doesn't specify a custom sorting function just use the old
match_value sorting method if a truncation is required.

Using the desktop ID (rather than the unique) ID as the cache key could
potentially match different GsApp objects depending on the order they are
returned from the plugin loader.

Also, get the GsApp from the unique-id using the global cache rather than
trying to recreate it using refine -- this may be the source of a different
bug where two different GsApps had the same unique ID in the cache.

Three problems here:

1. The desktop file wasn't using the global configuration object
2. The global configuration only knew about BINDIR rather than bindir
3. The global BINDIR was using quoting as it's designed for source files

Just use a local configuration_data object with the one thing set with the
right name.

If you already have gnome-software running this filename is passed to the
existing process which is likely to be running in a different working directory.

Searching for 'gno' returns over 900 desktop apps, extensions and runtimes and
it's basically impossible to show that number for search-as-you-type. Limit the
number of search results by sorting the initial result set before refining the
list.

If the list is truncated tell the user how many results are missing in the form
of an insensitive label at the bottom of the search results.

Abusing keywords didn't really work as the origin should be a much lower search
match result, and also the origin is unlocalized and requires splitting.

The new code requires appstream-glib from master to work properly.

This is an incomplete fix as really the name needs splitting into tokens in the
case of sources like gnome-apps-nightly.

This ensures we can search for the repo name. Also, add a self test for this.

The tests cover currently gs_appstream_create_app.

When the popular overrides setting is set, we need to refine the apps in
order for them to be valid in the end.

This patch also updates the tests and covers the popular apps overrides.

When creating an app, if there's a matching cached one but it has the
"match any prefix" quirk, then we should proceed with creating a new app
because the cached one, due to that quirk, will behave differently than
our newly created one: e.g. it'll use refine_wildcard, it won't be able
to get a management plugin, etc.

This prevents problems associated with the behaviors mentioned above:
e.g. if there's an app in the global cache matching any prefix, and then
AppStream tries to create one from the AppStream data, it would reuse
the cached one instead; then it would be refined but would never get an
icon because the icons plugin does not implement refine_wildcard.

Instead of using the simple id when creating a GsApp from an AsApp, we
should use its unique id instead because it may have extra information
that the simple id won't, e.g. the bundle kind, app kind, etc.

This leads to a GsApp that is closer to the AsApp that it represents.

The list of apps that was looped over for calling the refine in each app
was also being passed to the refine functions. This could lead to
problems if the function affected the list (removed or added apps).

This patch fixes that issue by using a copy of the list in the loop.

(cherry picked from commit 5e9f5e5d052820034e8cb2410e202bf3cd1bbe62)

(cherry picked from commit 14d8ae4e2ecfbf8ba29ee912a98374784480c42a)

(cherry picked from commit 650d9128334b27b47374cbec3fdec83a9cab7d33)

We had pointers to realloced buffers. If the buffer was moved in a realloc then
they would point to invalid memory.