GNOME Bugzilla – Bug 128968
Open submenus on click
Last modified: 2018-02-10 04:39:50 UTC
I would like to suggest a "sticky menu" option in GTK+ 2.4. You probably know the nightmare where you have to navigate though your bookmarks, and one wrong move will course that you loss the submenu, and you have to start all over. Sticky menus are when you press the left mouse button once in the menubar and on the menu item, and the (sub)menu is kept open until the left mouse button is pressed on a new (sub)menu or menu item. Sticky menus makes navigating through many submenus easy, as you don't have to move the arrow exactly in the menus. You can simply press the mouse button once and move the mouse whereever you want without lossing the (sub)menu. This is also very helpful for people with handicaps. You can try out sticy menus in action in Window Maker, Acrobat Reader, and XEmacs (Emacs doesn't have sticky menus).
IMO this is probably a WONTFIX, since the submenu behavior is already really complex, and adding this is just going to make it more confusing... having the submenu stuck there could be quite confusing. But I'll let Soeren make the final call on the issue, since he's done most of the tweaking of menu behavior recently. (Doing it for menubars is certainly not possible. The current behavior of being able to go to another menu needs to be be preserved there.)
Could you ask him to try it out in fx. Acrobat Reader before making the decision? Using sticky menus is a very relaxing experience, and I think many would make it default. I would=) Thanks for your reply.
One thing that should be done under any circumstances is to pop out the submenu when you click. Currently you have to wait for a timeout to expire before you'll see the submenu (even if the timeout is quite short, much shorter than the windows one e.g.) Given that behavior, you can get something close to "sticky menus" by setting the timeout to something huge, like 10 min. The effect is that submenus will not appear until you click. It is not an *exact* match for sticky menus, though, because if you move the mouse cursor out of the stay up triangle, you will still lose the menu.
One could add a second timeout for delaying the popping down after the pointer left the triangle. Setting it to 0 would give the current behaviour, but setting it to 10min as well would give you an even closer approximation of sticky.
my friend, a hero and quadriplegic who turns his nose up to people with full arm motion left who use motorized chairs seems to think this is an obvious improvement for a whole bunch of people. i agree, i am an old lady who loses these menus very easily and often.
Created attachment 27630 [details] [review] a patch Here is an attempt to implement click-preempts-timeout.
First of all thank you very much for your patch! It was really kind of you=) I have just installed Fedore Core 2 and downloaded and patched gtk 2.4.1 with your patch, but I can't feel any difference... This is what I did: cd gtk+-2.4.1/gtk patch < open_submenus_on_click.patch cd ../.. ./configure --prefix=/usr make make install reboot Is that correct?
The procedure is correct as far as it goes, although rebooting isn't necessary. Just restart the relevant programs, for example by logging out and logging in. To actually get a noticable effect, you should also add "gtk-menu-popup-delay = 300000" to your .gtkrc-2.0.
Now it works=) As I see it, the difference from normal behaviour is: 1. When moving mouse then highlight, but don't open submenus. 2. Click to open submenus. 3. Hold submenu untill next click. And you have already done part 2=) I haven't tried hacking in a large project like this before, but if there is something I can do to help, please say when.
2004-11-24 Matthias Clasen <mclasen@redhat.com> Open submenus on click. (#128968, Martin Jeppesen) * gtk/gtkmenushell.c (gtk_menu_shell_button_release): Don't activate items with submenus after the timeout, just select them. * gtk/gtkmenuitem.c (gtk_real_menu_item_select): Make submenus popup immediately on click, regardless of popup delay.
Behavior 1 and 3 from the list at <a href="http://bugzilla.gnome.org/show_bug.cgi?id=128968#c9">Comment #9</a> are still missing in order to be functional.
Created attachment 86282 [details] [review] Patch implementing popup-on-click that works on touchscreens This patch is a heavily modified version of a change from maemo-gtk. It makes menus work nicely on touchscreen devices which have no motion events. The following things are changed: - submenus open *and* close on click on their parent menu item. - click+drag allows browsing submenus just as hovering does normally. - returning from the submenu by keynav closes the submenu (to be consistent with what the stylus does) - opening a submenu selects its first item, making keynav more intuitive together with the explicit opening/closing or submenus. The patch is not perfect yet, I see the following issues: - It introduces GtkSettings:gtk-menu-popup-on-click. It could maybe use gtk-touchscreen-mode, but it feels as if the new mode is very suited for people with certain disabilities (need to get the opinion of the accessibility guys), so it should IMHO be activatable separately from touchscreen mode. - The changes to GtkMenuItem are not all really needed, but I think they clean up the thing and make the code more understandable. - The patch is the result of lots of editing, so there are quite some whitespace changes that make it less readable. Reviewers should probably apply it and then diff -b - It's a mix of bugfix and feature. Something like this is needed to make menus usable at all on touchscreen devices, but the patch does a bit more than the bare minimum.
(In reply to comment #12) > - submenus open *and* close on click on their parent menu item. > - click+drag allows browsing submenus just as hovering does normally. > - returning from the submenu by keynav closes the submenu (to be consistent > with what the stylus does) > - opening a submenu selects its first item, making keynav more intuitive > together with the explicit opening/closing or submenus. > - It introduces GtkSettings:gtk-menu-popup-on-click. It could maybe > use gtk-touchscreen-mode, but it feels as if the new mode is very the above sounds like only improvements so far, so what is the reason for not enabling this per default? > - The patch is the result of lots of editing, so there are quite some > whitespace changes that make it less readable. Reviewers should probably > apply it and then diff -b instead of having n reviewers re-apply, merge & diff your patch, can you please attach a -b variant as well then?
Created attachment 86285 [details] [review] -b version of the patch, much more readable
The "improvements" you mention are no improvements at all when the menus work in default mode and open submenus on hovering, whereas they are IMHO all neccessary to get consistent explicit open/close behavior for both stylus and keyboard.
(In reply to comment #15) > The "improvements" you mention are no improvements at all when the menus > work in default mode and open submenus on hovering, whereas they are > IMHO all neccessary to get consistent explicit open/close behavior > for both stylus and keyboard. but they don't need to conflict so they could be enabled by default and don't need a setting, or? i.e.: - possibly hover, open up submenu when this happens - first click: open up submenu if not already open (due to previous hover) - second click: close submenu, can work regardless of hover.
> - possibly hover, open up submenu when this happens Strong disagreement here, since it breaks the fix for constantly throwing submenus at users which have certain disabilities (pending comments from the accessibility guys of course). > - first click: open up submenu if not already open (due to previous hover) This already happens anyway. > - second click: close submenu, can work regardless of hover. I think this would be inconsistent. The expextation in "normal" mode is that a selected menuitem always has its submenu open. I don't think we should break this "invariant".
(In reply to comment #17) > > - possibly hover, open up submenu when this happens > Strong disagreement here, since it breaks the fix for constantly throwing > submenus at users which have certain disabilities (pending comments from > the accessibility guys of course). erm, i was referring to *existing* behavior here. anyway, let's start over, my thoughts on your changes are: - submenus should be opened on clicks onto their corresponding menu items for touchscreen mode. i think this change is pretty clearly needed, for devices which do not reliably generate move-events/however to enable submenu operation. - submenus should close on clicks onto their corresponding menu items for touchscreen mode. uncontroversial, like opening. - submenus can conceivably also be opened on clicks onto their corresponding menu items for normal navigation mode. that'll naturally integrate with the normal menuitem-activates-on-click behavior that gtk menus usually have. and this behavior is useful despite hover-opens-submenu, because a submenu may not be open due to keyboard navigation events or the submenu-open-timeout still running. - similarly, submenu closing on click for normal navigation mode can make sense, but i'd say with the notable exception that the submenu was opened previously by means other than hover (i.e. keyboard or click). that's to avoid confusing the user when he intentionally navigates to a menu-item and clicks on it to open the submenu, but sees an actually closing submenu flicker because the previous hover caused it to "auto"-open. - we really should NOT introduce another menu behavior mode unless it is overwhelmingly clear that this is needed. i say that because the code already deals with a dirty mass of special cases and is hard to maintain. what you describe sounds like it could generally be integrated into the normal menu navigation and touchscreen modes and doesn't need to have an extra mode or switch, so i object to adding that. - you've not made a clear statement on what the accesibility issue is that you're trying to solve. if you talk about close-current-submenu-open-other on hover of a new menu item, we already have measures to deal with that, i.e. adjustable timeouts. so this is nothing that *clearly* needs fixing. also, given that the other changes are rather unquesitonable (click for touchscreen), do we really need to mix these discussions?
I have just applied the patch, but I can't see any difference. Do I need to edit a config file or something to activate it?
You need to add: gtk-menu-popup-on-click = 1 to your ~./gtkrc-2.0
I think it looks very promising. I like the hover effect on the menus =) Are you going for the XEmacs behavior? I think it might satisfy all parties. Power users that can move faster than the "open submenu delay", touch screens, and accessability.
Created attachment 86849 [details] [review] Updated and cleaned up patch Updated patch makes the open/close on click behavior dependent on gtk-touchscreen-mode and cleans up the changed code in gtkmenuitem.c a bit. I tried getting the open/close on click behavior for normal mode too but it was making the patch even more complicated since it needs to take care of the case where the popup timeout has just opened the submenu (we don't want to immediately hide it again in this case).
Created attachment 86850 [details] [review] -b version of updated patch
I tend to agree with Tims description in comment 18 of how to merge click-to-open-and-close with the current hover-to-open behaviour without a new mode by discriminating between explicitly and automatically opened submenus.
Created attachment 87057 [details] [review] Next version, enabling open/close on click unconditionally as asked for
Created attachment 87059 [details] [review] -b version of updated patch
Created attachment 87063 [details] [review] Next version after some input from tim
Created attachment 87064 [details] [review] -b version of updated patch
Created attachment 87076 [details] [review] Patch fixing an unrelated issue that hurts badly in touchscreen mode The new fix included is for the following: - open menu, hover item with submenu, wait until submenu opens - keyboard navigate the focus away from the mouse pointer - click the mouse expected: submenu opens again actual: entire menu tree closes the fix for that is in gtk_menu_shell_button_press() with an extensive comment.
Created attachment 87077 [details] [review] -b version of updated patch
Works much better now, thanks. The one thing I find irritating with the new behaviour is that even if a submenu has been opened by hovering, clicking on the parent menuitem twice will make it disappear again. Wrt to the code, maybe it would be good to add some comments, or maybe that is a lost cause as far as the menu code is concerned.
(In reply to comment #31) > Works much better now, thanks. > > The one thing I find irritating with the new behaviour is that even if a > submenu > has been opened by hovering, clicking on the parent menuitem twice will make it > disappear again. that is exactly what i requested above, i.e. the "merging" of the click-for-submenu with hover-shows-submenu modes. did you mean to suggest anything else here? > Wrt to the code, maybe it would be good to add some comments, or maybe that is > a lost cause as far as the menu code is concerned. that is a good idea, allthough there already were some new comments in mitch's patch, more probably wouldn't hurt as long as they are acurate.
A submenu opened by hovering even closes on first click *after* gtk-menu-popdown-delay milliseconds. The timeout is there to avoid closing menus that have hust timeout-opened when the user actually wanted to open the menu (because the open timeout was not over yet). I can't really think of another behavior that makes sense other than the currently implemented one. I'm open for suggestions though :-)
Created attachment 87131 [details] [review] And another iteration - adds some comments - makes submenus open if any button is down in enter_notify() - fixes menubar behavior (stale grab without any menu open)
Created attachment 87132 [details] [review] -b version of last patch
Created attachment 87139 [details] [review] version n+1, approaching infinity Fixes minor glitch with menubar menus closing in touchscreen mode
Created attachment 87140 [details] [review] -b version of last patch
> that is exactly what i requested above, i.e. the "merging" of the > click-for-submenu with hover-shows-submenu modes. > > did you mean to suggest anything else here? Not really, I was just surprised that the first click apparently turned the automatically opened submenu into an explicitly opened one. But I think the current behaviour is acceptable
Comtted the latest patch. Dunno if this bug counts as fixed now, it asks for slightly more. 2007-04-27 Michael Natterer <mitch@imendio.com> Merged heavily modified patch from maemo-gtk which enables opening and closing submenus on click, and introduces some usability changes when gtk-touchscreen-mode is enabled (bug #128968): * gtk/gtkmenushell.c (struct GtkMenuShellPrivate): added boolean "activated_submenu" to indicate that the current mouse operation (click or drag) has opened a submenu. (gtk_menu_shell_button_press): pop up submenus without delay and record the fact in "activated_submenu". (gtk_menu_shell_button_release): if a submenu was explicitely opened, or not opened by this release's button_press, or enough time has passed since timeout-opening it, close the submenu here. (gtk_menu_shell_enter_notify): when entering a menu item with any mouse button pressed, open its submenu. (gtk_real_menu_shell_move_current): in touchsreen mode, close the submenu when moving the focus away from it via keyboard-navigation. * gtk/gtkmenuitem.[ch] (_gtk_menu_item_popup_submenu): added parameter "gboolean with_delay" so GtkMenuShell can control this for the different scenarios of submenu showing. (_gtk_menu_item_popdown_submenu): new function. also needed by GtkMenuShell for closing submenus on click. Renamed internal function gtk_menu_item_select_timeout() to gtk_menu_item_popup_timeout(). (gtk_menu_item_real_popup_submenu): new utility function which does the actual popup and records the exact time of the popup when the menu was timeout-opened (using g_get_current_time()). (gtk_real_menu_item_select): don't add the popup timeout when in touchscreen mode. * gtk/gtkmenu.c (gtk_menu_popup): in touchscreen mode, select the first item of every opened menu.
> Comtted the latest patch. Dunno if this bug counts as fixed now, it asks > for slightly more. I think the changes are more touchscreen related than giving XEmacs behavior, which is what I am seeking in this bug.
This patch has broken drag selection. Now submenus pop up without waiting for the popup-delay.
What is drag selection?
It's when you press the button and keep it down while dragging to the menu item, then releasing to select. When you do that now after the patch, submenus pop up immediately, not after 225 ms as they used to.
Ah yes I see it. And I was so sure I tested all cases :-) The problem is that in gtk_menu_shell_enter_notify() it selects the item *and* calls _gtk_menu_item_popup_submenu (menu_item, TRUE), and trying to pop up with timeout twice gets rid of the timeout and pops up immediately. Easy to fix, will commit a fix later today.
Fixed in trunk: 2007-04-30 Michael Natterer <mitch@imendio.com> * gtk/gtkmenushell.c (gtk_menu_shell_enter_notify): pop up the submenu explicitely only in touchscreen mode since otherwise selecting the item already pops up the submenu. Restores the drag-selection timeout (spotted by Søren Sandmann, #128968).
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.