GNOME Bugzilla – Bug 661151
window-clone: Require a button-press before activating
Last modified: 2011-10-11 11:00:15 UTC
See attached patch. This has annoyed me for quite some time :-)
Created attachment 198504 [details] [review] window-clone: Require a button-press before activating Right-click menus in the dash can be dismissed by clicking anywhere outside the menu. However, if a window clone is located beneath the pointer when doing so, the window is activated and the overview closed. The cause of this unexpected behavior is that window previews are activated on button-release, which is delivered to the preview after the menu releases its grab on button-press. To fix, require that window previews receive a button-press event before activating.
Seems like making menus go away on button-release might be better? Yeah, yeah, it's inconsistent with GtkMenu... maybe hide the menu on press, undo the grab on release?
(In reply to comment #2) > Seems like making menus go away on button-release might be better? I don't agree - it doesn't make sense to me either that clicking on the panel and releasing on a window preview activates the window (I know that example is completely artificial, but I still think that requiring a "click" (== press+release) makes sense here). Maybe I should update the patch to require the same button though ... > Yeah, yeah, it's inconsistent with GtkMenu... No, it is *currently* inconsistent with GtkMenu ...
Review of attachment 198504 [details] [review]: Yeah this have annoyed me for a while as well, and the fix makes sense to me.
(In reply to comment #4) > Review of attachment 198504 [details] [review]: > > Yeah this have annoyed me for a while as well, and the fix makes sense to me. Would it make sense though to change the boolean _pressed to an integer _pressedButton?
Comment on attachment 198504 [details] [review] window-clone: Require a button-press before activating ClutterClickAction is supposed to solve this problem. We should use that everywhere rather than doing halfway measures. (Note that since your patch doesn't get a pointer grab, you can press the button on a clone, move outside the clone, release the button, press again, move back into the clone, and release, and it will be activated.)
(In reply to comment #6) > (Note that since your patch > doesn't get a pointer grab, you can press the button on a clone, move outside > the clone, release the button, press again, move back into the clone, and > release, and it will be activated.) No, because press+move starts a dragging action.
Created attachment 198537 [details] [review] window-clone: Use ClutterClickAction Right-click menus in the dash can be dismissed by clicking anywhere outside the menu. However, if a window clone is located beneath the pointer when doing so, the window is activated and the overview closed. The cause of this unexpected behavior is that window previews are activated on button-release, which is delivered to the preview after the menu releases its grab on button-press. Use a ClutterClickAction instead and let Clutter do the right thing, i.e. only trigger a 'clicked' signal when a button-release event is matched by a corresponding button-press event.
Review of attachment 198537 [details] [review]: Looks good. Thinking about it we should probably replace our custom event handling with clutter actions where appropriate (unrelated to this patch though).
Attachment 198537 [details] pushed as 7bc2573 - window-clone: Use ClutterClickAction (In reply to comment #9) > Thinking about it we should probably replace our custom event handling with > clutter actions where appropriate (unrelated to this patch though). Agreed.