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 358816 - [suggestion] Open submenus consistently in the same direction
[suggestion] Open submenus consistently in the same direction
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
unspecified
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-10-01 17:31 UTC by gg
Modified: 2018-05-02 14:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description gg 2006-10-01 17:31:02 UTC
whether a submenu comes up to the left or right of a main menu is determined by space to edge of screen.

width of a submenu is determined by its text.

result is that, depenant on the text, some submenus may come on a different side to the current or last one.

this is very disrouting at first and even once you know what is happeding it is destruptive.

A better solution would for this to be determined globally for the main menu so that all submenus fall consistantly one side or the other.

Other information:
ex. gimp colours menu . Place an image window about 2cm from RH screen edge. Select Colours menu and roll down the menu.

Auto and Components come to the right, Map jumps left, Info goes back to the right 

Similar effect with filters menu if my image is about mid screen. I try to browse the various filers and I get about half and half:

L
R
L
L
R
L
L
R
... etc.

my head is spinning by the time I get to see Decor at the bottom (right).
Comment 1 Michael Schumacher 2006-10-01 17:43:05 UTC
This is probably something that has to be done within GTK+. 

What's up with the "Batman!" in the summary, btw?
Comment 2 gg 2006-10-01 18:02:43 UTC
I thought it maybe deeper in a lib somewhere but figured someone here would be better placed to reclass it than me guessing.

(the title is just a bit of fun, as well as indicating the issue. Robin always used to come out really odd, polite exclaimations like that instead of saying "holy shit Batman!" Thought it may raise a smile.)
Comment 3 Michael Natterer 2006-10-01 21:18:14 UTC
Reassigning to GTK+, even tho I'm sure it will be closed as WONTFIX
right away...
Comment 4 gg 2006-10-01 21:52:02 UTC
well let's not pre-empt thier responce. I hope you're wrong.

You can not deny this is hard for the eye to follow. I find it very distruptive.

Comment 5 Marc Lehmann 2006-10-02 11:10:50 UTC
I agree that it is a problem (I hate that behaviour myself), but the proposed solution does not solve the problem. It might work better in a lot of common cases, though, so might be worth investigating.
Comment 6 gg 2006-10-05 10:17:38 UTC
Default position is to the right (poss LTR switching here) each submenu is checked before display to see it is too wide to RHS. 

This test seems to be run just before display of each submenu.

I suggest running the same test for all submenus when the menu is displayed. If any menu is too large the choise is fixed to display to the left the result is stored for the life of the menu.

What cases do you see this as not being a solution to?
Comment 7 Daniel Boles 2017-08-28 16:43:10 UTC
Just making one choice based on the entire tree of submenus doesn't seem like it would work; if you think it would, I'd appreciate a demonstration of how that would work.

An idea I had (which may be what you were really thinking of?) is that menus could switch side (only) when hitting a screen edge, then carry on in that direction until they hit the other side, and so on ad infinitum. I don't know if that's really better though; I don't think menus are made to be opened leftwards, except if forced (hence what we currently have).
Comment 8 GNOME Infrastructure Team 2018-05-02 14:20:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/266.