From: Dana Jansens Date: Sat, 5 May 2007 02:45:37 +0000 (+0000) Subject: merge r6060 from head. THIS MAY CHANGE TH BEHAVIOR OF PEOPLE'S CONFIG FILES. It is... X-Git-Tag: openbox-3_3_991-RELEASE~169 X-Git-Url: http://git.openbox.org/?a=commitdiff_plain;h=97412d741eb074646ab508e50c9069c04ec1f580;p=dana%2Fopenbox.git merge r6060 from head. THIS MAY CHANGE TH BEHAVIOR OF PEOPLE'S CONFIG FILES. It is getting rid of a race, but the race usually fell in favour of the desktop application rather than openbox. so if they have show menu bindings in the desktop context, now they will be showing the menu when they may not have done so before. --- diff --git a/openbox/action.c b/openbox/action.c index c91ea3c7..1af396a4 100644 --- a/openbox/action.c +++ b/openbox/action.c @@ -1102,7 +1102,8 @@ void action_run_list(GSList *acts, ObClient *c, ObFrameContext context, (c && c->type == OB_CLIENT_TYPE_DESKTOP && context == OB_FRAME_CONTEXT_DESKTOP)) && (a->func == action_focus || - a->func == action_activate)) + a->func == action_activate || + a->func == action_showmenu)) { /* XXX MORE UGLY HACK actions from clicks on client windows are NOT queued. @@ -1120,6 +1121,13 @@ void action_run_list(GSList *acts, ObClient *c, ObFrameContext context, so, this is just for that bug, and it will only NOT queue it if it is a focusing action that can be used with the mouse pointer. ugh. + + also with the menus, there is a race going on. if the + desktop wants to pop up a menu, and we do to, we send them + the button before we pop up the menu, so they pop up their + menu first. but not always. if we pop up our menu before + sending them the button press, then the result is + deterministic. yay. */ a->func(&a->data); } else