merge r6060 from head. THIS MAY CHANGE TH BEHAVIOR OF PEOPLE'S CONFIG FILES. It is...
authorDana Jansens <danakj@orodu.net>
Sat, 5 May 2007 02:45:37 +0000 (02:45 +0000)
committerDana Jansens <danakj@orodu.net>
Sat, 5 May 2007 02:45:37 +0000 (02:45 +0000)
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.

openbox/action.c

index c91ea3c727275355da4b1c21d1ddaf52dee66531..1af396a495a42c9cdff9d53e85496acf268b202f 100644 (file)
@@ -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