GNOME Bugzilla – Bug 676906
dash has inconsistent resizing: looks ugly, wastes space
Last modified: 2021-07-05 14:40:42 UTC
Created attachment 215081 [details] the bug at different sizes. I have done my homework. Here's an screenshot of the problem. The size does not scale smoothly, this is specially obvious when going from 9 to 10 items, this makes the panel jump to the size that corresponds to 13 items. Expected result: the panel/dash always fills the screen vertically showing big, clickable, beautiful icons.
Interesting. What version are you using?
(In reply to comment #0) > The size does not scale smoothly, this is specially obvious when going from 9 > to 10 items, this makes the panel jump to the size that corresponds to 13 > items. Yes. The dash does not use arbitrary icon sizes, but a set of standard sizes. I'll mark the bug for design review, but note that the current behavior has been explicitly requested by designers (probably because the drawbacks of scaling are worse than the "jumping" dash size) > Expected result: the panel/dash always fills the screen vertically showing big, > clickable, beautiful icons. Unfortunately, "scaled" and "beautiful" don't mix well - it's a drawback of inconsistent dash size versus fuzzy icons.
http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html
Not to be "that guy", but I wonder how OSX's dock does this. You can scale the panel to a somewhat wide range of sizes and all the stops will give you nice clear icons. Maybe they just ask for more icon resolutions in app bundles?
From http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/IconsImages/IconsImages.html To ensure that your app icon looks great in all the places that users see it, you need to create resources in the following sizes: 1024 x 1024 pixels 512 x 512 pixels 256 x 256 pixels 128 x 128 pixels 32 x 32 pixels 16 x 16 pixels So, are they just using a smarter scaling process?
Option: what if instead of scaling the icons, we remove some pixels of padding to accommodate for other icons as long as possible? Also, I just tried OSX dock on the left of the screen. The icons are way smaller than when on the bottom edge, so some start to look a tiny bit blurry, but only if you are looking closely. I noticed the dock is always vertically centred though, which indeed helps avoid the jumps. There was a very small size change, like no more than 10px, when adding or removing an icon (considering the 15 or so icons I have in that panel).
The Dash has a lot of space above and below. In the screenshot, there is room enough to keep the same icon size with 8, 9 and maybe even 10 items.
*** Bug 678544 has been marked as a duplicate of this bug. ***
If someone looks at this, they might want to check out bug 686344.
How about this algorithm: Starting from 1 icon, use the largest icon size and size the dash vertically accordingly, increase the size as more icons gets added (like currently). When the threashhold is passed, switch to one size smaller icons, but keep the dash size, pad out the icons. Now the icons will get more "packed" as more icons get added, until you reach the point where yet one step smaller icons are needed. Repeat. Or, in other words: for icon sizes other than the biggest one, dash size = max dash size for largest icon size and space out icons in the available space.
(In reply to comment #2) > Unfortunately, "scaled" and "beautiful" don't mix well - it's a drawback of > inconsistent dash size versus fuzzy icons. True; but if I have say 62*62 pixels space for icons in dash scaling down 64*64 bit icons would be far more beautiful than using 32*32 icons with a huge padding. Why can't we use the various icon sizes and scaling for a better implementation?
*** Bug 747010 has been marked as a duplicate of this bug. ***
Since version 3.16 of gnome, notifications have moved to the top of the desktop, so would it be possible to change the location of the dash to the bottom of the screen? No I speak turning it into a dock (for that there are extensions) but using the bottom of the screen, you can maximize space, as most of the screens and monitors have an aspect ratio of 16: 9 or 16: 10. With the dash at the bottom, you can have up to 12 application shortcuts (same current ratio) before having a change in the size of the icons. Also, extensions like "dash to dock," optimize the space between applications. With this option, the user experience can be greatly improved. With tweak tool could choose the place of the workspace panel (perhaps return to the navigation for workspaces panel horizontally),
Created attachment 303795 [details] dash in the bottom of the screen
Dock extensions can do that because they're not dependent on the Activities button. Putting the dash at the bottom (especially if it's allowed to fill its space) and leaving the Activities button where it is would lead to an impractical amount of travel.
(In reply to Dirk Mcbratney from comment #15) > Dock extensions can do that because they're not dependent on the Activities > button. Putting the dash at the bottom (especially if it's allowed to fill > its space) and leaving the Activities button where it is would lead to an > impractical amount of travel. I don't understand the relation you really mention, since with the shell the path with the cursor is long to perform many actions. For example open activities and then open applications (lower on the dash), open activities and move/open another workspace, etc. Even if the dash is at the bottom the workflow with the workspaces panel would be more enjoyable. In addition there are keyboard shortcuts to open activities or applications directly (probably a gesture in the future)
(In reply to Bastián Díaz from comment #16) > I don't understand the relation you really mention, since with the shell the > path with the cursor is long to perform many actions. For example open > activities and then open applications (lower on the dash), open activities > and move/open another workspace, etc. Even if the dash is at the bottom the > workflow with the workspaces panel would be more enjoyable. Applications is still on the dash, though; it's also the last item after the user-selected favorites because it represents "everything else", all of the less-used applications. To me, that just illustrates that the most frequently accessed elements in the overview are already prioritized as those with the least travel from the activities button (and the movement from the activities button downward to a given icon is also "paging" along the dash, which feels very natural.) Workspaces are definitely a longer walk, though it's worth pointing out that they're also slightly larger click targets. Notice that conversely, the only thing that requires traveling toward the lower right corner of the screen is if the user has a large number of workspaces open. > In addition there are keyboard shortcuts to open activities or applications > directly (probably a gesture in the future) Sure, but I don't think those things are intended as replacements for the pointer interaction. Having the option of hitting Super instead doesn't mean it's okay for the button or hotcorner to be suboptimal. Or rather, it just doesn't have any bearing on what is or isn't optimal for the layout.
(In reply to Dirk Mcbratney from comment #17) > (In reply to Bastián Díaz from comment #16) > > I don't understand the relation you really mention, since with the shell the > > path with the cursor is long to perform many actions. For example open > > activities and then open applications (lower on the dash), open activities > > and move/open another workspace, etc. Even if the dash is at the bottom the > > workflow with the workspaces panel would be more enjoyable. > > Applications is still on the dash, though; it's also the last item after the > user-selected favorites because it represents "everything else", all of the > less-used applications. In fact, among the most favorite applications that the user has, below is the button to show all applications. In addition to pressing it doesn't show everything else, but a page with recent applications by default and you have to do an additional click to show all the applications (it's crazy). Finally what this thread is about: The dash and its icons shrink ... it is weird in everyday use. > To me, that just illustrates that the most > frequently accessed elements in the overview are already prioritized as > those with the least travel from the activities button (and the movement > from the activities button downward to a given icon is also "paging" along > the dash, which feels very natural.) From my point of view the concept can be understood, but it does not feel natural. For them extensions that change the button to show all applications on top are so popular. > Workspaces are definitely a longer > walk, though it's worth pointing out that they're also slightly larger click > targets. Notice that conversely, the only thing that requires traveling > toward the lower right corner of the screen is if the user has a large > number of workspaces open. > > > In addition there are keyboard shortcuts to open activities or applications > > directly (probably a gesture in the future) > > Sure, but I don't think those things are intended as replacements for the > pointer interaction. Having the option of hitting Super instead doesn't mean > it's okay for the button or hotcorner to be suboptimal. Or rather, it just > doesn't have any bearing on what is or isn't optimal for the layout. Come on, today's monitors are widescreen, just to go to the first workspace you have to go from one end of the screen to the other. Since I use gnome-shell the dash feels strange. As others use extensions to improve their functionality, but I always expect upgrades for the use of the dash out of the box.
(In reply to Bastián Díaz from comment #18) > Finally what this thread is about: The dash and its icons shrink ... it is > weird in everyday use. I agree with that entirely, and that's why I'm joining this discussion. I simply don't agree that breaking the overall layout of the shell to ameliorate the problem is the right solution. I think the problem can be solved, and that the change can be made within the dash and without changing the current model for the overview as a whole. > In fact, among the most favorite applications that the user has, below is > the button to show all applications. In addition to pressing it doesn't show > everything else, but a page with recent applications by default and you have > to do an additional click to show all the applications (it's crazy). I confess I'm running 3.20 and this behavior may be different from what I'm familiar with. In 3.20, the show applications view remembers which view (recents or all) was displayed last, so it is indeed one click of the show applications button for me to get to "everything else". Either view is nonetheless a larger set of applications including less-used ones. > Come on, today's monitors are widescreen, just to go to the first workspace > you have to go from one end of the screen to the other. I simply interpret that as a sign that the basic design intends for workspace switching to be a less frequent activity than application switching - that is, that switching windows within a task grouping is a more frequent activity than switching between tasks. > From my point of view the concept can be understood, but it does not feel > natural. For them extensions that change the button to show all applications > on top are so popular. The rough equivalent in other environments (Android app tray, Windows Start menu, Unity Dash button) tends to be placed "first" or otherwise emphasized. It's natural that some users will want to maintain that thought process into another environment, and extensions allow them to do precisely that. I do think GNOME Shell's treatment of the button as a "..." button is self-consistent and illustrates some of the thought behind the current design of the dash.
(In reply to Dirk Mcbratney from comment #19) > (In reply to Bastián Díaz from comment #18) > > Finally what this thread is about: The dash and its icons shrink ... it is > > weird in everyday use. > > I agree with that entirely, and that's why I'm joining this discussion. I > simply don't agree that breaking the overall layout of the shell to > ameliorate the problem is the right solution. I think the problem can be > solved, and that the change can be made within the dash and without changing > the current model for the overview as a whole. > Well, that will have to be decided by experts on the subject, but don't be surprised that many times have had to break the current design of the shell to create something better (place of notifications, notification center, system menu, etc.) > > In fact, among the most favorite applications that the user has, below is > > the button to show all applications. In addition to pressing it doesn't show > > everything else, but a page with recent applications by default and you have > > to do an additional click to show all the applications (it's crazy). > > I confess I'm running 3.20 and this behavior may be different from what I'm > familiar with. In 3.20, the show applications view remembers which view > (recents or all) was displayed last, so it is indeed one click of the show > applications button for me to get to "everything else". Either view is > nonetheless a larger set of applications including less-used ones. > .v > > Come on, today's monitors are widescreen, just to go to the first workspace > > you have to go from one end of the screen to the other. > > I simply interpret that as a sign that the basic design intends for > workspace switching to be a less frequent activity than application > switching - that is, that switching windows within a task grouping is a more > frequent activity than switching between tasks. > Do you assume that the workflow of all users is similar? ... If you don't use workspaces there is no problem and even the panel is semi-hidden, but even if you occupy two or more workspaces already it becomes a mess. Even if you use 5+ workspaces the activity view is the fastest route (keyboard shortcuts help, but it is not faster). Opening an application from the dash to a given workspace involves a long run. So if the dash was closer or even unified with the workspace panel would be a better option for me. (Automatic creation of workspaces is a functionality that can be better exploited). > > From my point of view the concept can be understood, but it does not feel > > natural. For them extensions that change the button to show all applications > > on top are so popular. > > The rough equivalent in other environments (Android app tray, Windows Start > menu, Unity Dash button) tends to be placed "first" or otherwise emphasized. > It's natural that some users will want to maintain that thought process into > another environment, and extensions allow them to do precisely that. I do > think GNOME Shell's treatment of the button as a "..." button is > self-consistent and illustrates some of the thought behind the current > design of the dash. But it doesn't work and that's why it doesn't feel natural.
It is good to resume this discussion. Now with Unity's death maybe the Canonical team -my hopes are on system76 team- can bring with useful things like message indicators or progress bars in the dash. The GNOME devs work is focused on other areas and the help is always welcome to retake sections that already work but need improvement. For my part, I always try to use gnome out-of-the-box, but I always need to improve dash functionality by putting the apps button on top and the dash is consistent in size. Dash-to-panel has an option that allows you to see applications on carousel view, so no matter how many applications you have open, you will always be consistent.
(In reply to Bastián Díaz from comment #20) > Do you assume that the workflow of all users is similar? ... If you don't > use workspaces there is no problem and even the panel is semi-hidden, but > even if you occupy two or more workspaces already it becomes a mess. Even if > you use 5+ workspaces the activity view is the fastest route (keyboard > shortcuts help, but it is not faster). I don't assume the workflow of all users is the same, no. I do assume that there's a workflow logic within the design of the Shell and some thought put into what the intended use case for any element is and how it interacts with all of the others, in the same sense that there is for any desktop environment and particularly its defaults. I don't want to take that too far - I agree that different users will use the same tool in different ways. But of course, beyond that, if users do want to use a radically different workflow that doesn't mesh well with the default environment, there is the option of extensions to modify it. > Well, that will have to be decided by experts on the subject, but don't be > surprised that many times have had to break the current design of the shell > to create something better (place of notifications, notification center, > system menu, etc.) Agreed, I think we've hashed out these abstractions enough that I'm comfortable feeling I've said my piece on them and leaving it to the experts to decide whether or not more radical changes are warranted or whether this can be resolved within the present model. Strictly on topic and in practical terms, it's still my opinion that the way to fix the dash is to let it occupy more of the screen, be thriftier with the padding, set a large minimum icon size or simply use a fixed one, and implement some kind of paging or scrolling behavior that doesn't require dragging on the dash or using the scroll wheel for the reasons already discussed. Stating the obvious, even a bottom dash will eventually fill up if the user pins a particular (probably unreasonable) number of applications, so there still has to be some other behavior at that stage. (In reply to haevalencia from comment #21) > For my part, I always try to use gnome out-of-the-box, but I always need to > improve dash functionality by putting the apps button on top and the dash is > consistent in size. Dash-to-panel has an option that allows you to see > applications on carousel view, so no matter how many applications you have > open, you will always be consistent. Trying it out now, this carousel behavior based on simply "nudging" one end of the dash with the cursor feels surprisingly natural, and the way that the icons fade at the ends of the space creates an obvious visual reminder that there's more dash hiding there. I think this is the kind of solution I'd want to see implemented.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.