GNOME Bugzilla – Bug 640966
Favorite applications should have priority when searching
Last modified: 2013-08-18 12:05:25 UTC
My use case is the following: - I use the keyboard a lot, rather than the mouse, so I find hitting 'Super' and typing the first few letters of the application I want to launch is a great feature (I used to use GNOME-Do in 2.x, for the same thing) - I have Firefox as a favorite application in the shell dash, and I also have Filezilla installed, which is not a favorite though - If I hit 'Super' and type 'fi', I expect Firefox to be launched, as that's a favorite, and it's also launched way more times than Filezilla - Filezilla is launched instead
Created attachment 216492 [details] [review] appDisplay: Sort app search by core->default->favorited->normal App usage alone may not tell the whole story about how important a user feels an app is. Using other information -- such as if the app is favorited or set as default -- we can get a better idea of where the user expects to see the app when searching for it. Briefly, _processResults looks up each result id in three different hash tables (corresponding to core, default, and favorited apps). If the id exists in one of them, save it in an array for that type of result, slice it from the results, and put them back together in the proper order after we have gone through all the results. The TODOs point to specific issues that need addressed, mainly: (1) ids corresponding to the core apps we want (if they exist) (2) better interoperability with the control center on getting the defaults
Review of attachment 216492 [details] [review]: So first, is there any design on preferring core / default apps over favorited ones? That seems a little strange to me. If I liked the apps so much, I'd favorite them myself. Forcing core/default apps above ones the user explicitly said he liked seems strange to me, and we'd run into the same set of issues. ::: js/ui/appDisplay.js @@ +355,3 @@ + } + + for (let i = 0; i < results.length; i++) { You should be able to write by calling .sort with a good comparator function, rather than building a few lists. @@ +412,3 @@ }); +const AppCore = new Lang.Class({ I really don't think this should be a class. Just a regular function. @@ +430,3 @@ + + ids.forEach(function(id) { + let appInfo = Gio.DesktopAppInfo.new(id); You really should be using the ShellAppSystem here.
(In reply to comment #2) > Review of attachment 216492 [details] [review]: > > So first, is there any design on preferring core / default apps over favorited > ones? That seems a little strange to me. If I liked the apps so much, I'd > favorite them myself. Forcing core/default apps above ones the user explicitly > said he liked seems strange to me, and we'd run into the same set of issues. Favorite apps are in shown in the dash, right? Would anybody try to start them using search? If two results are shown, better select first the one the user likely needs to start via the search, not the one it could have started from the dash.
This is supposed to get us a bit closer to https://live.gnome.org/GnomeShell/Design/Whiteboards/Search, quoting: " Search returns application launchers Match against application name and keywords Do not match against generic name or comments (comments should be converted to keywords) Order results according to: If a default or core app, then If the app has been favourited (ie. added to the dash), then Frequency of search result returns, then Exact matches " Not sure how up-to-date this is though.
(In reply to comment #4) > Not sure how up-to-date this is though. I don't think we have anything more recent than that, yeah. (FWIW, I'm still not convinced it is a good idea - our results have gotten a lot better when we *removed* most of the fanciness, so I'm skeptical that adding different fanciness will improve them)
Created attachment 216537 [details] [review] appDisplay: Sort app search by core->default->favorited->normal App usage alone may not tell the whole story about how important a user feels an app is. Using other information -- such as if the app is favorited or set as default -- we can get a better idea of where the user expects to see the app when searching for it. Made the changes suggested by Jasper, although I'm not sure the way I use .sort is exactly what he had in mind.
(In reply to comment #3) > (In reply to comment #2) > > Review of attachment 216492 [details] [review] [details]: > > > Favorite apps are in shown in the dash, right? Would anybody try to start them > using search? If two results are shown, better select first the one the user > likely needs to start via the search, not the one it could have started from > the dash. Faster to do from the keyboard. Yes, I know I can Ctrl+Alt+Tab to the dash, fumble around, and then hit arrows. I want <Super>ter<Enter>.
(In reply to comment #6) > Created an attachment (id=216537) [details] [review] > appDisplay: Sort app search by core->default->favorited->normal > > App usage alone may not tell the whole story about how important a user feels > an app is. Using other information -- such as if the app is favorited or set > as default -- we can get a better idea of where the user expects to see the > app when searching for it. > > > Made the changes suggested by Jasper, although I'm not sure the way I use > .sort is exactly what he had in mind. No, it's not, but close: function getPriority(app) { if (isFavorite(app)) return 0; if (isCore(app)) return 1; if (isHandler(app)) return 2; return 3; } results.sort(function(a, b) { return getPriority(a) - getPriority(b); });
Created attachment 216688 [details] [review] appDisplay: Sort app search by core->default->favorited->normal App usage alone may not tell the whole story about how important a user feels an app is. Using other information -- such as if the app is favorited or set as default -- we can get a better idea of where the user expects to see the app when searching for it. Use sort() more like Jasper suggests. I feel that three one line methods that aren't used elsewhere is kind of wasteful, so the lookups for priority happen in _getPriority.
Review of attachment 216688 [details] [review]: Sorry. I haven't reviewed this lately because I'm not sure it's the best idea. Not the end of the world if we don't get this one in.
As a previous gnome-do user in the gnome 2.x era, I was very grateful that gnome-do learned my favourite applications (based on how often i launched them) and after a day of typing "ter" i usually only had to type 't' to get a terminal to launch. So I hope this gets some love and gets in, in some shape or form. Without it, using gnome3 feels like a huge regression. I'm sick of accidentally launching 'totem'. Many thanks, James
We already sort applications based on application frequency, and have done since 3.2. Since I have a terminal open all the time, typing "t" gets me a terminal. Maybe we should count frequency for specific search terms, though.
Is this something we still want? (Personally I'm happy that <super>t<enter> gives me the terminal (not a core app afaik) and not Videos (which is a core app), based on my usage rather than a predefined order)
(In reply to comment #13) > Is this something we still want? > (Personally I'm happy that <super>t<enter> gives me the terminal (not a core > app afaik) and not Videos (which is a core app), based on my usage rather than > a predefined order) I'm inclined to say not. The current behaviour works well for me too, and bumping favourite apps might not work well for people who never change the defaults.