After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 640966 - Favorite applications should have priority when searching
Favorite applications should have priority when searching
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: search
2.91.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-01-30 19:53 UTC by Cosimo Cecchi
Modified: 2013-08-18 12:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
appDisplay: Sort app search by core->default->favorited->normal (5.36 KB, patch)
2012-06-15 04:56 UTC, Tanner Doshier
needs-work Details | Review
appDisplay: Sort app search by core->default->favorited->normal (5.29 KB, patch)
2012-06-15 19:10 UTC, Tanner Doshier
none Details | Review
appDisplay: Sort app search by core->default->favorited->normal (4.44 KB, patch)
2012-06-18 16:36 UTC, Tanner Doshier
none Details | Review

Description Cosimo Cecchi 2011-01-30 19:53:17 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
Comment 1 Tanner Doshier 2012-06-15 04:56:24 UTC
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
Comment 2 Jasper St. Pierre (not reading bugmail) 2012-06-15 05:15:05 UTC
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.
Comment 3 Milan Bouchet-Valat 2012-06-15 12:17:22 UTC
(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.
Comment 4 Rui Matos 2012-06-15 13:06:39 UTC
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.
Comment 5 Florian Müllner 2012-06-15 13:37:24 UTC
(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)
Comment 6 Tanner Doshier 2012-06-15 19:10:18 UTC
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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-06-15 19:45:04 UTC
(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>.
Comment 8 Jasper St. Pierre (not reading bugmail) 2012-06-15 19:48:25 UTC
(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);
    });
Comment 9 Tanner Doshier 2012-06-18 16:36:39 UTC
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.
Comment 10 Jasper St. Pierre (not reading bugmail) 2012-08-20 05:03:14 UTC
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.
Comment 11 James 2012-08-20 18:51:45 UTC
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
Comment 12 Jasper St. Pierre (not reading bugmail) 2012-08-20 18:57:30 UTC
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.
Comment 13 Florian Müllner 2013-06-14 14:16:51 UTC
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)
Comment 14 Allan Day 2013-08-18 12:05:25 UTC
(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.