GNOME Bugzilla – Bug 741155
Popover submenus are uncomfortable to use
Last modified: 2018-04-15 00:18:39 UTC
The current transition to a popover submenu has two steps: 1. Parent content slides out while submenu content slides in. If there are fewer menu items in the submenu, they are positioned at the bottom. 2. Popover height abruptly adjusts, and menu items are repositioned. The overall effect can be quite uncomfortable and jarring (see gedit's View submenu as an example). My personal feeling is that submenus that expand down (like the shell's submenus) are superior to a horizontal slide transition: * The parent menu stays in view, so there isn't as much visual transitioning involved, and the transitions that do occur have a visual anchor/reference point. * You don't have to reread the menu from the top - your eye is already at the top of the submenu, and you can continue reading down. * The pointer is initially positioned at the top of the submenu. In many cases this results in reduced pointer travel. It also means that the pointer only has one direction to travel in, which is more predictable. While this approach isn't as effective for nested submenus, that's not something we encourage anyway. Nested submenus could be made to work within such an approach, and that would be good enough. If expanding submenus aren't possible, we could probably iterate on the existing design (such as with bug 699301), but it would be good to explore expanding menus first.
as I said various times, I do like the stack-based, horizontal pan approach; it allows me to follow the path of an option — from A, to B, and then back — and reduces the distraction by limiting the amount of things I have to concentrate on. I kind of agree with the eye position argument, at least for consistency on how the classic menus already work. outside of the more mechanical arguments (eye position, pointer position and movement) there's also the argument about navigation and discovery in a new UI, as opposed to progressive disclosure in an established UI. the end result of an expanding submenu with an animation would require exactly the same kind of animation as expanding the height of the stack in bug 699301: we need to expand the popover vertically while fading in the contents of the sub-menu. my main issue for a change is that I think the expansion-in-place looks okay with one-level deep hierarchies, but breaks down pretty badly with more than one level, as you noticed. at least, I remember this being a fairly consistent issue in the shell menus. in the end, the unwritten rule in shell menus is to never allow more than one level deep hierarchies; given the sizing constraints of popovers I expect applications will need more than one level to express structured menus. I think we should try improving the animation in the toolkit, but we definitely need some experimentation with new layouts.
Created attachment 292389 [details] expanding popover menu mockup Here is a mockup for how expanding popover menus could look. One issue that I haven't been able to resolve so far is the placement of a scroll bar for when the menu grows larger than the popover can be. One way to address this would be to use overlaid semi-transparent scrollbars. (Being able to scroll a popover menu is probably desirable anyway, irrespective of this expanding design...)
Created attachment 293827 [details] updated mockup (In reply to comment #2) > ... One issue that I > haven't been able to resolve so far is the placement of a scroll bar for when > the menu grows larger than the popover can be. You'd do it like this, I suppose.
Comment on attachment 293827 [details] updated mockup Lapo gave me a hand with the visual treatment. Better mockups can be found here: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/experiments/expanding-popover-menus.png
https://bugzilla.gnome.org/show_bug.cgi?id=699301 - this bug had been dealing with this issue somewhat, but a) assumes that the intended behaviour is to slide horizontally rather than extend vertically, and b) has been inactive for some time. Needless to say, this would definitely be good to resolve in time for 3.16
nobody has been working on this, so it is unlikely
Emmanuele and I talked about this bug during the Cambridge developer experience hackfest. If memory serves me correctly, the main issue we identified was the ability to automatically position and size popovers depending on their position on screen. That said, I'm still in favour of the expanding approach.
I think all your points are pretty sound, but the logic works when menus are small and can fit on screen w/o overflowing (if a menu part gets overflowed it gets pretty unconfortable), I think we totally need to experiment here, but we should consider to have both approaches (expanding and sliding), generally speaking I think scrolling menus are pretty much bad design to me.
So, should we still try to improve the current situation then? I have local (hacky) patches to change the menu alignment based on the popover position and other stuff (which makes them more like gnome-shell menus, but that has been rejected in the past iirc). The only other thing left would be the animated GtkStack size change which was very problematic last time I checked, but I guess we can work on that(?).
> So, should we still try to improve the current situation then? We should _always_ try to do that, of course!
Created attachment 302760 [details] [review] gtkpopover: Update the menu's alignment ... when the popover position changes.
*** Bug 735508 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new