GNOME Bugzilla – Bug 701387
dash: Stop including running apps
Last modified: 2020-10-15 19:42:01 UTC
Putting this up for discussion, see patches. Might depend on some appification of the window picker to minimize the draw-backs ...
Created attachment 245775 [details] [review] dash: Only show favorites, not running apps Space in the dash is precious - as items are added, the dash's size shrinks until it reaches a minimum, from which point on we just cut off at the bottom. This means that unless we change completely how we deal with many items in the dash (for instance by making it scrollable à la Unity, which would have its own set of disadvantages), the number of items in the dash is limited. By dropping running applications from the dash, we (1) maximize the number of slots available for user configuration (2) make it possible to fix the broken cut-off behavior by rejecting drops after running out of space On the downside, we take away one way to (1) activate a (non-favorite) application (leaving alt-tab and the window picker) (2) add a new favorite (leaving search results and the app picker) Still, I think the benefits outweigh the costs ...
Created attachment 245776 [details] [review] dash: Reject drops when out of space As the number of items in the dash grows, we shrink icons to accommodate more items until we reach a minimum icon size, at which point the dash will be cut off at the bottom, which is clearly broken. Instead, start rejecting drops when we can no longer accommodate more items.
I use the dash as an app switcher, a la the Windows 7 "SuperBar". I'm against it.
How about doing the opposite, and limiting the Dash to recently opened apps, like the iOS tray, or the left sidebars in Android (on tablets) and Windows 8? That creates a nice distinction between the user-organized app pages and the (now) fully automatic Dash, which would be more focused on short-term mouse-driven app switching. Then you might want to consider handling alt-tab app switching through the Dash...
(In reply to comment #3) > I use the dash as an app switcher, a la the Windows 7 "SuperBar". There were some vague ideas about app-grouping in the window picker floating around, which I was hinting at in comment #0. > I'm against it. Any alternative suggestions how to address the problem, or should I read this as "let's keep it broken"? (In reply to comment #4) > How about doing the opposite, and limiting the Dash to recently opened apps, > like the iOS tray, or the left sidebars in Android (on tablets) and Windows 8? Off-hand I think that user preference should beat automagic, e.g. favorites should be more easily accessible than any frequently/recently used lists. I can't speak about iOS, but this is indeed the case for Android (which has favorites at the bottom - not sure which sidebar you're speaking of btw, there is none on my spouse's Nexus 7) and Windows 8 (where the start screen is more prominent than the sidebar) > That creates a nice distinction between the user-organized app pages and the > (now) fully automatic Dash, which would be more focused on short-term > mouse-driven app switching. Of course for the time being, there are no user-organized app pages :-) The designers do want pages instead of scrolling for the "All" view, and it has indeed been discussed to allow users to change the ordering, but (if at all) as a "power user" feature, not something we'd expect virtually every user to do. IMHO there's a huge difference between picking a set of favorite apps, and having to sort a potentially[0] large list. If your suggestion boils down to swapping the "Frequent" view with the dash, that sounds like a better option to me, though not without problems of its own: we'd need new ways for adding/removing favorites, and it's unclear to me what to do with the dash when usage tracking is disabled (just hiding the most accessible option for accessing applications seems wasteful). And then of course there's the aforementioned issue of configuration vs. magic :-) > Then you might want to consider handling alt-tab app switching through the > Dash... I don't understand that part of your comment. [0] considering the default installs of many distros, this is unfortunately not a theoretical consideration
Oops! I didn't realize that the paging app view was still just a design. :) My suggestion was based on the way I happen to use both iOS and Windows 8 (and once used Android v.3 on a larger tablet, where the "Recents" button displayed a sidebar of sorts). But I don't have any good reason to recommend my method, especially since it's certainly true that most distros bundle enough apps to make organizing the app pages overwhelming. All I meant by the last suggestion was that if the Dash was organized by recency, then Alt-Tabbing could display it, and it could show which app you're switching to, allowing the removal of the current Alt-Tab switcher.
(In reply to comment #3) > I use the dash as an app switcher, a la the Windows 7 "SuperBar". I'm against > it. I second that. I also use the right click -> select window feature a lot.
(In reply to comment #5) > (In reply to comment #3) > > I use the dash as an app switcher, a la the Windows 7 "SuperBar". > > There were some vague ideas about app-grouping in the window picker floating > around, which I was hinting at in comment #0. > > > > I'm against it. > > Any alternative suggestions how to address the problem, or should I read this > as "let's keep it broken"? We could / should just scroll. Instead of scaling down that much. I don't see anything fundamentally wrong with scrolling. It is an UI concept that we use all over the place for "stuff does not fit". I wouldn't use a scrollbar though but the same type of scrolling we have alt tab.
(In reply to comment #8) > We could / should just scroll. Instead of scaling down that much. I don't see > anything fundamentally wrong with scrolling. It is an UI concept that we use > all over the place for "stuff does not fit". We do try to avoid it if possible, but that's not really my main concern here. I agree that adding a scrollbar to the dash would be just weird[0]. But there is an important difference between alt-tab and the dash IMHO - the former is mostly (almost exclusively?) keyboard driven, so I don't think it's a big issue that pointing devices need to support scrolling to be usable with the (scrolled) popup. This does not apply to the dash, which should still be usable with mice without wheel, touchpads without scrolling support and touch devices. The most natural solution of course would be swipe scrolling then, but given that click, click+drag and long-press are all already used by existing functionality, I don't see how it could possibly work without removing some of those features. [0] to not say "utter crap", which is why to my knowledge no one has ever done something similar - which of course makes this a perfect candidate for bug 701403 :-)
(In reply to comment #9) > (In reply to comment #8) > > We could / should just scroll. Instead of scaling down that much. I don't see > > anything fundamentally wrong with scrolling. It is an UI concept that we use > > all over the place for "stuff does not fit". > > We do try to avoid it if possible, but that's not really my main concern here. > I agree that adding a scrollbar to the dash would be just weird[0]. But there > is an important difference between alt-tab and the dash IMHO - the former is > mostly (almost exclusively?) keyboard driven, so I don't think it's a big issue > that pointing devices need to support scrolling to be usable with the > (scrolled) popup. This does not apply to the dash, which should still be usable > with mice without wheel, touchpads without scrolling support and touch devices. > The most natural solution of course would be swipe scrolling then, but given > that click, click+drag and long-press are all already used by existing > functionality, I don't see how it could possibly work without removing some of > those features. Well click, long press and swipe scrolling are not mutually exclusive. The Android "window/app switcher" uses all of this gestures and it works really well. So that leaves the drag ... we would either use a modifier key for that (wont work on touch) or require to drag sideway (out of the dash) so that it does not conflict with the vertical scrolling. > [0] to not say "utter crap", which is why to my knowledge no one has ever done > something similar - which of course makes this a perfect candidate for bug > 701403 :-) ;)
Hello, I have a proposition for you: Activities Overview: - Use dash for running applications + icon to view applications and favorites. In view of applications: - The Dash displays favorites (applications rely forward) Watch the video to Understand http://www.dailymotion.com/lesconfducoq#video=x13nx14 What do you think about that ? Jerome
*** Bug 696351 has been marked as a duplicate of this bug. ***
> Space in the dash is precious - as items are added, the dash's > size shrinks until it reaches a minimum, from which point on > we just cut off at the bottom. In 3.22 I started 19 applications and apart from the icons in the dash getting smaller and smaller I did not see any issues like icons being cut off. Does this task still cover an existing problem?
Ubuntu Gnome 16.04, on Gnome 3.18.5 the issue does exists. I have made screenshot of it: http://i.imgur.com/35FVtN3.png Eclipse icon is cutted half. There are also other programs icons under it which did not fit into the dash - when I did close Eclipse, other software icon did show up and so on. I know I am not running 3.22. In 3.22, is Dash showing only favorites as mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=696351#c13 ?
In 3.22 the Dash shows favorites & running apps. We don't care about 3.18. :)
(In reply to Dariusz Deoniziak from comment #14) > Ubuntu Gnome 16.04, on Gnome 3.18.5 the issue does exists. I have made > screenshot of it: http://i.imgur.com/35FVtN3.png No, this actually looks somewhat different - the icons in the screenshot are correctly shrunk to a smaller size, but for some reason the dash itself doesn't shrink, so the smaller icons just increase the whitespace instead of the number of icons the dash can hold. But as André said, you are using a quite old version that is no longer supported upstream, so unless you can reproduce the issue on the last stable version, we won't spend time investigating it.
(In reply to Florian Müllner from comment #16) > you are using a quite old version that is no longer > supported upstream, so unless you can reproduce the issue on the last stable > version, we won't spend time investigating it. No reply for three years. Assuming this does not happen anymore. If this still happens in a recent version (3.38 or 3.36), then please file a ticket in https://gitlab.gnome.org/ - thanks!