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 699608 - Desktop menu from the Shell uses an arrow that points to nothing.
Desktop menu from the Shell uses an arrow that points to nothing.
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.11.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-05-03 17:02 UTC by Sam Hewitt
Modified: 2014-02-18 15:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of the issue. (290.78 KB, image/png)
2013-05-03 17:02 UTC, Sam Hewitt
  Details
backgroundMenu: Removes the arrow pointer of backgroundMenu (1.34 KB, patch)
2013-07-05 16:44 UTC, Tarun Joshi
none Details | Review
theme: adds a class to hide arrow of boxpointer (846 bytes, patch)
2013-07-05 16:47 UTC, Tarun Joshi
none Details | Review
some distro is already squashing backgroundMenu arrow on their own (122.10 KB, image/jpeg)
2013-09-26 17:05 UTC, Derek Moore
  Details
box menu "near" edge of screen (335.21 KB, image/jpeg)
2013-09-28 02:40 UTC, Derek Moore
  Details
box menu "nearer" to edge of screen (329.68 KB, image/jpeg)
2013-09-28 02:40 UTC, Derek Moore
  Details
theme: set arrow rise property of backgroundMenu to 0 (832 bytes, patch)
2013-10-01 07:52 UTC, Tarun Joshi
committed Details | Review
boxpointer: add condition checks for -arrow-rise: 0px (4.46 KB, patch)
2013-10-01 08:01 UTC, Tarun Joshi
committed Details | Review

Description Sam Hewitt 2013-05-03 17:02:25 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.
Comment 1 drago01 2013-05-05 15:26:34 UTC
It does not point to "nothing" but to the background image.
Comment 2 George 2013-05-12 11:08:38 UTC
Still, those usually point to an icon on the panel, a toolbar icon, etc ... pointing to the background image looks really unusual.
Comment 3 Allan Day 2013-06-20 13:02:19 UTC
I agree that the arrow looks a bit odd.
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-06-21 18:20:54 UTC
What should the design here be, then?
Comment 5 George 2013-06-22 07:09:39 UTC
Just like the current menu without the arrow?
P.S. I am no gnome designer to take this decision, that's just a suggestion.
Comment 6 Tarun Joshi 2013-07-05 16:42:40 UTC
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.
Comment 7 Tarun Joshi 2013-07-05 16:44:38 UTC
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.
Comment 8 Tarun Joshi 2013-07-05 16:47:11 UTC
Created attachment 248470 [details] [review]
theme: adds a class to hide arrow of boxpointer

This adds the required class needed for the previous patch.
Comment 9 drago01 2013-08-18 12:13:07 UTC
(In reply to comment #3)
> I agree that the arrow looks a bit odd.

Any comment on the suggested change?
Comment 10 George 2013-08-18 12:21:18 UTC
For what is worth, sound OK to me. =)
Comment 11 Derek Moore 2013-09-26 03:15:26 UTC
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! ;)
Comment 12 Tarun Joshi 2013-09-26 07:37:24 UTC
(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 :).
Comment 13 Derek Moore 2013-09-26 16:59:34 UTC
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.
Comment 14 Derek Moore 2013-09-26 17:03:27 UTC
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
Comment 15 Derek Moore 2013-09-26 17:05:22 UTC
Created attachment 255859 [details]
some distro is already squashing backgroundMenu arrow on their own

attaching the image I hyperlinked to in a previous comment
Comment 16 Derek Moore 2013-09-26 17:48:25 UTC
Oh, ha, nevermind on the 3.10 question. It was released today!
Comment 17 drago01 2013-09-26 17:48:52 UTC
(In reply to comment #16)
> Oh, ha, nevermind on the 3.10 question. It was released today!

There is still 3.10.1
Comment 18 drago01 2013-09-26 17:59:13 UTC
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.
Comment 19 Derek Moore 2013-09-28 02:37:32 UTC
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.
Comment 20 Derek Moore 2013-09-28 02:40:10 UTC
Created attachment 255968 [details]
box menu "near" edge of screen
Comment 21 Derek Moore 2013-09-28 02:40:37 UTC
Created attachment 255969 [details]
box menu "nearer" to edge of screen
Comment 22 Tarun Joshi 2013-10-01 07:52:20 UTC
Created attachment 256157 [details] [review]
theme: set arrow rise property of backgroundMenu to 0
Comment 23 Tarun Joshi 2013-10-01 08:01:10 UTC
Created attachment 256160 [details] [review]
boxpointer: add condition checks for -arrow-rise: 0px

This fixes that right angled corner problem which Derek told.
Comment 24 Derek Moore 2013-10-01 13:15:59 UTC
(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!
Comment 25 Yosef Or Boczko 2013-11-20 12:26:39 UTC
Oops, I change the version of this bug instead of another bug,
sorry.
Comment 26 Jasper St. Pierre (not reading bugmail) 2013-11-20 14:00:01 UTC
Review of attachment 256160 [details] [review]:

OK.
Comment 27 Jasper St. Pierre (not reading bugmail) 2013-11-20 14:00:11 UTC
Review of attachment 256157 [details] [review]:

OK.
Comment 28 Carlos Soriano 2014-01-15 17:45:05 UTC
I just commited the patches. Thanks Tarun for the work!
Comment 29 Derek Moore 2014-02-18 15:24:10 UTC
(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!
Comment 30 Derek Moore 2014-02-18 15:25:53 UTC
(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)