GNOME Bugzilla – Bug 699608
Desktop menu from the Shell uses an arrow that points to nothing.
Last modified: 2014-02-18 15:25:53 UTC
Created attachment 243221 [details] Screenshot of the issue. When the file manager isn't handling the desktop, the menu from the shell –to change the background / settings– is styled with an arrow that points to nothing. Logically, it might be better without an arrow.
It does not point to "nothing" but to the background image.
Still, those usually point to an icon on the panel, a toolbar icon, etc ... pointing to the background image looks really unusual.
I agree that the arrow looks a bit odd.
What should the design here be, then?
Just like the current menu without the arrow? P.S. I am no gnome designer to take this decision, that's just a suggestion.
We can have what Sam and George said(menu without arrow) as a temporary fix till we get a better design. At least it doesn't look that odd this way as it looks with arrow.
Created attachment 248469 [details] [review] backgroundMenu: Removes the arrow pointer of backgroundMenu This adds a style_class on the actor which hides the arrow. Additionally, I changed arrow's position which was St.Side.TOP to St.Side.LEFT so that the menu opens on right side of the pointer as it used to in Gnome 2.
Created attachment 248470 [details] [review] theme: adds a class to hide arrow of boxpointer This adds the required class needed for the previous patch.
(In reply to comment #3) > I agree that the arrow looks a bit odd. Any comment on the suggested change?
For what is worth, sound OK to me. =)
The only code change needed here is adding: -arrow-rise: 0px; to the background-menu class. Changing backgroundMenu.js to popup on St.Side.LEFT is awkward. But leaving it as St.Side.TOP is nice. I actually like that the mouse it tabbed in a little bit when the menu appears, instead of in the corner as is usual on most systems. It is nice being able to just move down the menu while not have to move into the menu. I like this change, but I say just set -arrow-rise:0px in background-menu class and that is all. PS: I made this: https://extensions.gnome.org/extension/721/gnome-shell-open-terminal/ and I hope to turn its prefs panel into an obmenu for GNOME Shell, a la WindowMaker Applications menu! ;)
(In reply to comment #11) I think I'm used to menus opening on the right. Changing it from St.Side.TOP to St.Side.LEFT looked natural to me but thats just what I feel. Let someone from design team review it. There has been no response from them on suggested change. Maybe they are designing something more cooler :).
I've added your CSS class to my extension! But I'll wait to see implications on versions before making a new submission to the extensions site. Do you know whether it will be too late for these simple CSS changes to make it into 3.10? Maybe "-boxpointer-gap: 4px;" in background-menu class could also use some adjustment since the arrow is being squashed. (I like there being some gap to easily dismiss the popup on accidental activation by just clicking again.) I saw this on "Every Detail Matters" and liked the sound of it. I want to extend backgroundMenu quite a bit for my own purposes (and backport it to previous versions), so I thought I'd come in here and help you bump this thread, maybe get the attention of someone on the design team.
Some distro out there is already squashing the arrow themselves. See this screenshot from a user who has modified my extension to add more .desktop files: https://scontent-b.xx.fbcdn.net/hphotos-prn2/1239627_10201990426793180_322136109_n.jpg
Created attachment 255859 [details] some distro is already squashing backgroundMenu arrow on their own attaching the image I hyperlinked to in a previous comment
Oh, ha, nevermind on the 3.10 question. It was released today!
(In reply to comment #16) > Oh, ha, nevermind on the 3.10 question. It was released today! There is still 3.10.1
OK so got feedback from the Allan he is fine with just not showing the arrow. Unfortunately your patches do not work in testing though. They have no effect here.
I. Behavior of the Background Menu is inconsistent when the mouse is near the edge of the screen. See the screenshots I'll attach. Basically, if the mouse is near the edge but not too close, the popup is flush with the edge unexpectedly, and all corners are round as expected. If the mouse is a little closer to the edge, the popup appears where expected, but the corner nearest to the mouse is squared off unexpectedly. II. You can see the patch to my extension which brings in Tarun's CSS class, removing the arrow on 3.8 and 3.10. I renamed Tarun's class to "popup-menu-box" because in terms of widget inheritance, a box should become a boxpointer, not the other way around. It is redundant to say "boxpointer with no arrow" when it is now just a "box". The St widget or whatever it is should be refactored, and the box should be pulled out of the boxpointer and the box should be extended to form the boxpointer.
Created attachment 255968 [details] box menu "near" edge of screen
Created attachment 255969 [details] box menu "nearer" to edge of screen
Created attachment 256157 [details] [review] theme: set arrow rise property of backgroundMenu to 0
Created attachment 256160 [details] [review] boxpointer: add condition checks for -arrow-rise: 0px This fixes that right angled corner problem which Derek told.
(In reply to comment #23) > Created an attachment (id=256160) [details] [review] > boxpointer: add condition checks for -arrow-rise: 0px > > This fixes that right angled corner problem which Derek told. Nice! Great work!
Oops, I change the version of this bug instead of another bug, sorry.
Review of attachment 256160 [details] [review]: OK.
Review of attachment 256157 [details] [review]: OK.
I just commited the patches. Thanks Tarun for the work!
(In reply to comment #28) > I just commited the patches. Thanks Tarun for the work! Carlos, what release is/was this patch a part of? I'll like to backport this fix to earlier Gnomes using my extension here: https://extensions.gnome.org/extension/721/gnome-shell-open-terminal/ but I need to know the version number of Gnome where this patch is introduced so I can conditionally attach Jasper's CSS class to the widget. Thanks!
(In reply to comment #29) > so I can conditionally attach Jasper's CSS class to the widget. Sorry, I mean Tarun's CSS class (Jasper was the peer reviewer)