GNOME Bugzilla – Bug 685824
GNOME shell search does not return results when searching for "Install"
Last modified: 2013-04-11 02:56:22 UTC
On the Fedora 18 Beta, running gnome 3.6, finding the package kit application via search proved somewhat difficult. I tried the search terms, "install", "packages", "add", "remove", all returned no results. However, a search for "Software" and "application" did result in the package kit application did appear. It appears that gnome-shell search returns results from the commandname (in this case, "gpk-application") and from the name in the desktop file (in this case, "Software"). It does not return any results from the application description from the desktop file (in this case, "Add or remove software installed on the system") Another example of this issue presents when searching for "Browser", neither firefox, nautalis or epiphany are displayed.
(In reply to comment #0) > It appears that gnome-shell search returns results from the commandname (in > this case, "gpk-application") and from the name in the desktop file (in this > case, "Software"). We also match on the "Keywords" field, which has been added to the desktop entry spec to explicitly support the search use case. > It does not return any results from the application description from the > desktop file (in this case, "Add or remove software installed on the system") Yes. We used to do this, but it was never ideal - the purpose of the "Comment" field was always to provide more details while browsing through applications, not to provide a good list of related terms used for search. For instance for gpk-application, the description does not match "uninstall" or "programs", although those are perfectly reasonable search terms (much more than "or", "on" and "the"). > Another example of this issue presents when searching for "Browser", neither > firefox, nautalis or epiphany are displayed. I agree that "Browser" should match all three of them, but this is actually a good example for Keywords being better than Comment - even using an English locale, "Browser" did not return any of those applications when we still used the description :-) So TL;DR: applications should add the "Keywords" field to their desktop file to improve matches. Reassigning to gnome-packagekit, which provides gpk-application.
(In reply to comment #1) > (In reply to comment #0) > > It appears that gnome-shell search returns results from the commandname (in > > this case, "gpk-application") and from the name in the desktop file (in this > > case, "Software"). > > We also match on the "Keywords" field, which has been added to the desktop > entry spec to explicitly support the search use case. > > > > It does not return any results from the application description from the > > desktop file (in this case, "Add or remove software installed on the system") > > Yes. We used to do this, but it was never ideal - the purpose of the "Comment" > field was always to provide more details while browsing through applications, > not to provide a good list of related terms used for search. For instance for > gpk-application, the description does not match "uninstall" or "programs", > although those are perfectly reasonable search terms (much more than "or", "on" > and "the"). Although not being ideal, the state the keywords are currently in make the user experience horrible and even though not matching on the comment field is an improvement, to the user, it feels like a regression. there are many examples of where basic keywords that previously worked no longer do. typing "chat" does not even bring up empathy.
I think the shell should match against comments and GenericName fields until all core GNOME apps get proper keywords in their desktop files. (also, it'd be nice if it'd also match against English when my locale is not English, or just match on all avil. languages in the desktop file)
If each of us spends half an hour testing searches, we can have the bulk of the problem fixed. Lets work on the solution here, rather than perpetuate the workaround. Here is a fix for the 'install' part already: bug 682696
...and here's the GnomeGoal for this: https://live.gnome.org/GnomeGoals/DesktopFileKeywords
(In reply to comment #4) > If each of us spends half an hour testing searches, we can have the bulk of the > problem fixed. Lets work on the solution here, rather than perpetuate the > workaround. I agree, but I still think the shell needs to also look at the GenericName field, because it makes sense to use it for searching as much as using Name does.
I agree, looking at generic name may make sense. One additional goal I have here is that I want the gnome-shell search to return the same results as the search in the control-center shell, as far as settings panels are concerned.
(In reply to comment #7) > I agree, looking at generic name may make sense. Filed Bug #687121 for this
Bug 682696 and bug 687121 have both been fixed, and the relevant GNOME goal is ongoing. I'd say we can close this now. Thanks for the report, Ryan!
Install brings up gpk-application now