GNOME Bugzilla – Bug 634755
menus bounce when moving between top level items
Last modified: 2010-12-21 22:13:20 UTC
When mousing between sound and universal access menus two things happen that aren't ideal: * The menu animates as if it was just dropping down for the first time and this causes a bouncing effect. It would be better to know one is already down and slide over or just fade out/in quickly. * Focus is lost and regained. This causes focus to return to the last application for a very short time. This is undesirable because in some cases the focused change results in a color change of the widget. This is pretty distracting when only moving between shell menus.
(In reply to comment #0) > * Focus is lost and regained. The patch in bug 618885 comment 23 fixes this
Created attachment 174807 [details] [review] popupMenu: fix up grab/ungrab handling stolen from bug 618885; this reorganizes popupMenu in a way that's useful for the other fix anyway
Created attachment 174808 [details] [review] popupMenu: don't animate menus when switching from one to another Don't do the "slide" effect when moving from one menu to another; only do it when opening the first menu, or closing a menu without opening another one.
Created attachment 174872 [details] [review] panel: fix up calendar-vs-menu handling on clock Give the clock's right-click menu its own PopupMenuManager so that if you drop down another menu and then mouseover the clock it doesn't pop up the right-click menu.
Created attachment 174873 [details] [review] popupMenu: fix up grab/ungrab handling Fix the panel menus to avoid unnecessarily bouncing out of modal (bug 634194) and to do a better job of keeping the keyboard focus in the right place
Created attachment 174874 [details] [review] popupMenu: don't animate menus when switching from one to another Don't do the "slide" effect when moving from one menu to another; only do it when opening the first menu, or closing a menu without opening another one.
Owen pointed out a problem on IRC, which is that if you dropped down a status menu, and then moved over and clicked the clock, you got a stuck grab. The first patch here fixes the longstanding oddity that the clock's right-click menu showed up as part of the main menu group, and then the new version of the second patch avoids causing any new grab problems with it.
Comment on attachment 174873 [details] [review] popupMenu: fix up grab/ungrab handling this patch is now part of bug 618885
Created attachment 176557 [details] [review] panel: fix up calendar-vs-menu handling on clock rebased on top of 618885
Created attachment 176558 [details] [review] popupMenu: don't animate menus when switching from one to another rebased on top of 618885
Created attachment 176799 [details] [review] panel: fix up calendar-vs-menu handling on clock rebase
Created attachment 176800 [details] [review] popupMenu: don't animate menus when switching from one to another rebase, especially for the new submenu stuff
Review of attachment 176799 [details] [review]: Looks good
Review of attachment 176800 [details] [review]: Looks fine. Sure wish JS had named parameters.... ::: js/ui/popupMenu.js @@ +855,3 @@ this.isOpen = true; + // this never gets called with animate=false, so... A little too elliptical and hard to figure out - better to just say that you didn't implement animate=false, or even do a : if (!animate) // animate always true currently throw new Error("not implemented");
updated the comment; didn't add the throw, because it ought to be pretty obvious that it's not working if someone tries to do an open(false) on it Attachment 176799 [details] pushed as 7d0eeef - panel: fix up calendar-vs-menu handling on clock Attachment 176800 [details] pushed as 1694148 - popupMenu: don't animate menus when switching from one to another