GNOME Bugzilla – Bug 786522
Activity search doesn't work as expected
Last modified: 2017-09-13 11:59:55 UTC
I'm not able to search for things in an intuitive way with the gnome-shell search. I press Super, and then start typing, but get unusual results. For example, I'm trying to launch the GNOME power settings, or the app called "Power," so I press Super and type "power," but the first item that appears is "LibreOffice Impress," and "power" is only the second item. As another example, I'm looking for a PDF file I've been reading called Computing Machinery, so I press Super and start typing "computing," but the first thing that comes up is the app for R (the statistical programming language). If I'm looking for a PDF file called "computer as communication device," I type "computer" but the first result I get is an app called "desktop search." On the other hand, if I'm actually trying to launch R, I press Super, type "R," but the first result is "Sound Recorder." R is there, but it's the fourth result. If I press a space after "R," it doesn't help me to select the R app. Another example: I'm trying to launch the settings app called Sound. I press Super, type "sound," but the first result is "sound recorder," an app I've never actually used. Search should really rank results by how well they're matched ("sound" matches "sound" 100%, whereas "sound" only matches "sound recorder" about 40%. Additionally, search should probably rank items based on how often they're accessed, so that the first search results are the ones I'm most likely to want, instead of obscure apps I never use.
(In reply to Jonathan Reeve from comment #0) > As another example, I'm looking for a PDF file ... gnome-shell doesn't search files at all. For applications, the actual search implementation lives in GIO, so reassigning there.
(In reply to Florian Müllner from comment #1) > (In reply to Jonathan Reeve from comment #0) > > As another example, I'm looking for a PDF file ... > > gnome-shell doesn't search files at all. For applications, the actual search > implementation lives in GIO, so reassigning there. This also covers file search (‘Computing Machinery’). Which GIO APIs does gnome-shell use for its application search, and where’s the code which calls them?
(In reply to Philip Withnall from comment #2) > Which GIO APIs does gnome-shell use for its application search, g_desktop_app_info_search: https://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c#n4198 > and where’s the code which calls them? It's called by a small wrapper[0] that is then used from javascript[1] [0] https://git.gnome.org//browse/gnome-shell/tree/src/shell-app-system.c#n430 [1] https://git.gnome.org//browse/gnome-shell/tree/js/ui/appDisplay.js#n1127
(In reply to Florian Müllner from comment #3) > It's called by a small wrapper[0] that is then used from javascript[1] > > [0] > https://git.gnome.org//browse/gnome-shell/tree/src/shell-app-system.c#n430 > [1] https://git.gnome.org//browse/gnome-shell/tree/js/ui/appDisplay.js#n1127 Thanks. Shouldn’t the UTF-8 validation done by that wrapper be moved into g_desktop_app_info_search()? --- The problems with app searching in this report can be reproduced using the test utility glib.git/gio/tests/apps. For example: $ ./apps search power > libreoffice-impress.desktop gnome-power-panel.desktop It looks like the problem is that the code does a prefix search for each search token against each desktop file, but doesn’t then let the similarity between the search string and the match affect the overall score of that result. It’s a bit tricky to fix heuristic algorithms like this piecemeal (one person’s fix breaks another person’s use case), so I’m going to mark this as a duplicate of bug #764417, which is about fuzzy string matching for g_desktop_app_info_search(). I’ll mention these example searches in that bug. Thanks for the detailed bug report. *** This bug has been marked as a duplicate of bug 764417 ***