GNOME Bugzilla – Bug 683340
3.5.90 - Nine dot application ICON drops off Dash
Last modified: 2012-09-12 14:34:13 UTC
After opening a reasonable number of applications (in my case 8), The new nine dot application icon drops off the bottom of the dash and is no longer accessible. It appears that the dash is restricted to displaying a particular number of icons at the smallest size and provides now way to navigate them once this limit is exceeded. Also, from a usability perspective, the nine dot grid icon would be better placed at the top of the dash above all other icons.... at least that way it would always be available!
Marking as 3.6 blocker...this seems important.
Created attachment 223689 [details] Screenshot with the problem
Firefox - Terminal were already in my dash as favourites.
Can we make the dash as scrollable? instead of allowing the dash (and icons) to become so small and virtually unusable, it will be better if we can restrict number of icons and make the icons scrollable. Also it will be better, if we could have some kind of visual separation between the 'nine dots' and other dash entries. This also allows us to keep nine dots as non scrollable, if we are making the dash icons scrollable. In such scenario, it makes more sense to keep the nine dots at top, more close to the hot corner (with a visual separation from other icons) and without scrolling. I prefer that approach to the current one.
Created attachment 224024 [details] [review] dash: Don't underallocate show-apps button When the dash contains more icons than fit at the minimum icon size, icons are cut off at the end. This means that the show-apps button will be the first to disappear, which is problematic given it's the sole access point for other applications (for those that refuse to use search at least). Fix by using a dedicated widget for the dash actor, so that in case of underallocation only icons above the show-apps button end up being cut off.
(In reply to comment #0) > After opening a reasonable number of applications (in my case 8), The new nine > dot application icon drops off the bottom of the dash and is no longer > accessible. Is this with a very small monitor or do we fail to shrink the icon size correctly (which would be a separate bug)? Even with a vertical resolution of 600 pixels the dash should fit 8+1 items ... > Also, from a usability perspective, the nine dot grid icon would be better > placed at the top of the dash above all other icons.... at least that way it > would always be available! That's something the designers would need to comment on (also see bug 683637) - for now, I'm attaching a solution that does not break the UI freeze.
Review of attachment 224024 [details] [review]: Looks good. ::: js/ui/dash.js @@ +330,3 @@ + + let children = this.get_children(); + }, availWidth @@ +336,3 @@ + childBox.x2 = availWidth; + childBox.y1 = 0; + let contentBox = this.get_theme_node().get_content_box(box); There's a potential issue in here where we'll warn if we have less height than the show apps icon, but I guess we should warn in that case. @@ +337,3 @@ + childBox.y1 = 0; + childBox.y2 = availHeight - natHeight; + let contentBox = this.get_theme_node().get_content_box(box); let [appIcons, showAllApps] = children; @@ -328,3 @@ - this._container = new St.BoxLayout({ name: 'dash', - vertical: true, - clip_to_allocation: true }); We don't use 'spacing' or any BoxLayout CSS properties here? Very surprised.
@Florian - Quick work. I have not tested the patch yet, but I trust it will perform as you have described and the application icon will remain accessible whilst other icons drop off the dash... result! But, there remains the problem that application icons will still drop off the dash. I personally have a reasonable number of favourites...so running apps quickly disappear and its not at all obvious what is going on to the normal user.. For clarity - I have 11 favourites in the dash so they start to drop off when I open 7 different applications. i.e. 18 icons in total... others may have different configurations..but for arguments sake if I had 15 favourites and open 3 non-favourite applications the icons would start to disappear. From a design perspective, we need a solution that enables the display and access to more icons than fit at minimum icon size... I don't think its acceptable to drop them because they don't fit in the space we have allocated to them. Thanks
Created attachment 224048 [details] Patched dash
I have applied the patch and can confirm that it achieves its objective of keeping the nine dot application icon on the dash,,, however the icon immediately above it appears to be cut off. i.e. not fully displayed. Whilst it still works it looks clunky and detracts from the overall polish of the dash and gnome-shell experience..
Created attachment 224052 [details] [review] dash: Don't underallocate show-apps button (In reply to comment #7) > ::: js/ui/dash.js > @@ +330,3 @@ > + > + let children = this.get_children(); > + }, > > availWidth Splinter output got messed up, I have no idea what this comment referred to. > @@ +336,3 @@ > + childBox.x2 = availWidth; > + childBox.y1 = 0; > + let contentBox = this.get_theme_node().get_content_box(box); > > There's a potential issue in here where we'll warn if we have less height than > the show apps icon, but I guess we should warn in that case. In that case we have other problems than a warning - if the dash is too small for a single 38px item, the entire overview will be completely useless. > @@ -328,3 @@ > - this._container = new St.BoxLayout({ name: 'dash', > - vertical: true, > - clip_to_allocation: true }); > > We don't use 'spacing' or any BoxLayout CSS properties here? Very surprised. Yup, spacing (and most padding) is done in the children, not the container.
(In reply to comment #11) > Created an attachment (id=224052) [details] [review] > dash: Don't underallocate show-apps button > > (In reply to comment #7) > > ::: js/ui/dash.js > > @@ +330,3 @@ > > + > > + let children = this.get_children(); > > + }, > > > > availWidth > > Splinter output got messed up, I have no idea what this comment referred to. It was supposed to refer to the -1 in get_preferred_height.
(In reply to comment #10) > I have applied the patch and can confirm that it achieves its objective of > keeping the nine dot application icon on the dash,,, however the icon > immediately above it appears to be cut off. i.e. not fully displayed. Whilst it > still works it looks clunky and detracts from the overall polish of the dash > and gnome-shell experience.. Yes, that's how it has worked since 3.0, and we are not going to rush in major UI changes a fortnight before a major release. I know that designers are aware that the dash is not scaling too well and there are some rough ideas about addressing it (basically making the window picker better for picking applications, so the dash can be made solely about favorites), but it's definitively post-3.6 material at this point.
(In reply to comment #12) > It was supposed to refer to the -1 in get_preferred_height. Ah, OK. It doesn't matter in practice, but changed locally.
(In reply to comment #14) > (In reply to comment #12) > > It was supposed to refer to the -1 in get_preferred_height. > > Ah, OK. It doesn't matter in practice, but changed locally. I'd just prefer to knock all "-1"s out of our codebase. There's still a bug somewhere in the PopupMenu codebase where we don't respect text width/height. I know you don't care about extensions, but I do. (In reply to comment #11) > Splinter output got messed up, I have no idea what this comment referred to. If you're curious, checking the Splinter review page shows the correct location of the line as it was entered into the database. I'm not sure why the comment output got messed up (file a bug?).
Review of attachment 224052 [details] [review]: Looks fine to me.
Attachment 224052 [details] pushed as 2db029b - dash: Don't underallocate show-apps button