GNOME Bugzilla – Bug 74950
Menu improvements
Last modified: 2011-02-04 16:11:52 UTC
Here is a patch that - makes the delay before submenus appear below menu bars a GtkSetting - makes the delay before submenus pops out from other menus a GtkSetting
!@#$ mozilla text field Here is a patch that - makes the delay before submenus appear below menu bars GtkSetting - makes the delay before submenus pops out from other menus a GtkSetting - makes the stay up triangle slightly larger - removes a feature that made the delay essentially a minimum period between two submenu popouts. - changes the default delay for popouts to 250 for menus and 0 for menubars. I tested a functionally equivalent version of the patch with carol from #gimp with positive reactions. She tried out various popout delays and ended on 250 ms, which was also my first choice. Yosh also said he liked the new behavior.
Created attachment 7203 [details] [review] Patch that improves menus
Notes on the patch - The descriptions for the GtkSettings need to be rewritten - I left #if 0'ed debugging code that draws red color over the stay-up triangle. I think this code is too useful to throw away.
*** Bug 73305 has been marked as a duplicate of this bug. ***
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Created attachment 7921 [details] uname and xdpyinfo
eh, ignore that attachment.
Putting on 2.2, since I think it should only go in HEAD and not on the 2-0 branch. Will try to remember to look at it soon. Bug me if I don't.
> Putting on 2.2, since I think it should only go in HEAD and > not on the 2-0 branch. Will try to remember to look at it > soon. Bug me if I don't. Don't hurry :-) I think the patch is definitely an improvement, and something to a similar effect should go in, but There are two problems with the way the patch makes menus behave: - when a menu is popped out, it can be difficult to get rid of it again. If the user wants to select the next menu item and moves diagonally, the menu stays up, which makes it feel heavy. (The patch is a big improvement on this problem as compared to current menu code, but there is still room for improvement). - It is possible to move in such a way that all menus will pop out for a very short while. I'd like to investigate what happens if we lose the stay-up triangle and instead base the stay up decision on the current velocity of the mouse cursor. It could be something like "stay up as long as the current velocity is such that the user can actually reach the menu within t milliseconds" and "pop out if the cursor slows down sufficiently for a sufficiently long time over a menu item".
I don't think I'll get around to doing the velocity based thing in the near future, so the above patch is probably going to be my best offer for 2.2.
We used a similar solution for xul menus in mozilla, making the submenu delay settable (ui.submenuDelay). It made a big difference in accessibility for people who have trouble moving the mouse accurately. The velocity-based solution might not be as helpful for someone with problems moving the mouse. You can always unpost a menu by clicking somewhere else, so setting a very long delay emulates the behavior of Motif or BeOs menus, where a click posts a submenu and it stays posted even if the mouse wanders somewhere else.
Created attachment 11592 [details] [review] new patch
I just attached a new patch that applies cleanly. In addition to applying clean, this patch makes the delay before popping a submenu down a GtkSetting with a default of 1000 instead of the hardcoded value of 333. Also, the descriptions for the GtkSettings are better.
Hmm, trying this out some. In general, I like the feel of it; it comes across as more stable than the current behavior, though a little clumsier/slower. I think it makes sense to go ahead and add something like this, but there is one thing in the implementation that is going to take some work... we've been trying really hard make all settings update properly on the fly, and it looks like in your patch that the values only update at menu creation time. I think it should be fine to just look it up every time from the appropriate settings (You could add a _gtk_menu_shell_get_popout_delay() function of some sort) rather than trying to cache the value... we only need to get it at "user speed" after all and settings lookup shouldn't be that slow.
Created attachment 11694 [details] [review] New attempt with instant apply
This new patch should do instant apply; it should also get the right settings objects. I agree that the menus might feel a bit slow, so in this patch I have changed the default popout delay from 250 to 225 ms. This make a surprisingly big difference, and is an improvement, I think.
(I wasn't necessarily saying that it was _too_ slow, just noticeably slower.) Detailed comments on the patch: - "gtk-menu-popout-delay" - don't menus pop *up* not *out*? - I think "gtk-menu-submenu-hysteresis" isn't a great name; it sounds like the amount of hysteresis (even if you know what hysteresis is :-). I'd call it something like "gtk-menu-submenu-timeout" or "gtk-menu-submenu-popdown-delay" - _("The time before closing a submenu when the pointer is moving towards the submenu") I think I'd say "hiding" not "closing". - draw_ugly_color() needs a rename, and it would be better to do: #undef DRAW_STAY_UP_TRIANGLE #ifdef DRAW_STAY_UP_TRIANGLE #endif Rather than #if 0. - + gint submenu_hysteresis; should be renamed to match however gtk-menu-submenu-hysteresis is renamed. - + enum { + OVERSHOOT = 50 + }; We use #defines for things like this Other than that, looks reasonable.
Sun Oct 20 23:58:03 2002 Soeren Sandmann <sandmann@daimi.au.dk> * gtkmenu.c, gtkmenubar.c, gtkmenuitem.c, gtkmenushell.c, gtkmenushell.h, gtkmenushell.h - make the delay before submenus appear below menu bars a GtkSetting - make the delay before submenus pops up a GtkSetting - make the stay up triangle slightly larger - don't pop up the first submenu immediately. - make the default delay for submenus 225 ms, and 0 for menubars. - make the default delay before popping down inside the stay-up triangle 1000 ms Fixes #74950
Created attachment 11862 [details] [review] Patch that flips regions
I did the region flipping thing we talked about on IRC, and the result is much better. The sluggish feeling moving out of an item with a popped up submenu is gone, it is difficult to get caught in the triangle, and there are no problems with missing the triangle. Can I commit this?
Created attachment 11863 [details] [review] Fixed region flipping patch
There were a combined off-by-one and sign error in the previous patch. This one should fix it. (I'll #undef the DRAW_STAY_UP_TRIANGLE before committing, of course)
I committed this.