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 694349 - App view - always show frequent apps first
App view - always show frequent apps first
Status: RESOLVED NOTABUG
Product: gnome-shell
Classification: Core
Component: overview
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
3.8?
Depends on:
Blocks:
 
 
Reported: 2013-02-21 11:11 UTC by Allan Day
Modified: 2013-02-25 14:59 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8



Description Allan Day 2013-02-21 11:11:33 UTC
Right now we remember the state of the frequent / all switcher. I think we want to be showing frequent first each time. There are two options here:

 1. Show frequent first every time you open the app view
 2. Show frequent first for each visit to the overview

I'm leaning slightly towards the second option - it seems likely that if someone goes from all apps to the windows view, it is likely that they will want to return to all apps (rather than frequent apps) when revisiting the apps view.
Comment 1 Giovanni Campagna 2013-02-21 14:52:11 UTC
I think I disagree with this proposal.
Indeed, the very first reaction to the addition of a frequent view was "I hope it can be disabled", so having the state persistent (at least for the session, if not forever) is a great advantage for those who don't like it.
And I believe a good number of people will only use the all view anyway, having their frequent apps in the dash and using the app view for everything else.
Comment 2 Hashem Nasarat 2013-02-21 15:58:11 UTC
I would prefer to have gnome-shell save the most recently selected tab.

Ditto on what Giovanni said regarding having the dash be the place for frequent apps.

Perhaps even get rid of the frequent view and just add another button on the dash for frequently used.
Comment 3 Florian Müllner 2013-02-21 15:59:20 UTC
I like how the current design creates different levels of app-reachability (in contrast to presenting all apps equally as done in earlier iterations or gnome2):

(1) Dash as user managed set of favorites [0]
(2) The "Frequent" view for apps the user is likely to launch
(3) The "All" view for (almost) every app installed
(4) Folders for applications that are probably only rarely used

While this is a point in favor of returning to the "Frequent" view, those levels are probably more fine-grained than what most users need, so I can see how users would want to pick one and stay with that.

For what it's worth, the current design document explicitly mentions this[1]:
"Ability to switch to 'All applications' view through a toggle next to the search entry. This setting is persistant."

All considered, I can see merit in the proposal, but I tend more towards the opposite direction of storing the switch state in GSettings to make it truly persistent.


[0] I think we should at least consider removing running applications
    from there - space is pretty limited there
[1] https://live.gnome.org/GnomeShell/Design/AppPickerRefresh
Comment 4 Jakub Steiner 2013-02-25 11:34:13 UTC
Not being persistent on the toggle brings turns this back to the 'view all' button (so a two stage process to get to the grouped view every time).

I would stick to a persistent toggle we have now. 

I do not doubt the frecent view will deliver on the promise of giving back the relevant apps (major case -- installing new apps will put them to the top). But making the toggle persistent will get the OCD filers off our back.
Comment 5 Florian Müllner 2013-02-25 12:18:31 UTC
(In reply to comment #4)
> I would stick to a persistent toggle we have now. 


Just for clarification - semi-persistent as now or actually persistent across sessions?
Comment 6 Jakub Steiner 2013-02-25 14:37:10 UTC
per session seems good enough.
Comment 7 Florian Müllner 2013-02-25 14:59:28 UTC
(In reply to comment #6)
> per session seems good enough.

OK, nothing to do here then ...