If I use a Command Shortcut to execute the xfce4-popup-menu command, then it regularly fails to respond. An error message appears in VT1, saying: ** (xfce4-menu-plugin:9601): CRITICAL **: Unable to get keyboard/mouse grab. The Command Shortcut fails very regularly (at least 50% of the time) and sporadically. However, if I run xfce4-popup-menu from the command-line it does seem to work consistently.
I don't think there's a 'fix' for this. It's behaving exactly as it should: if it can't get a keyboard/mouse grab, it bails. If your X server isn't allowing a grab in the allotted time, that's likely because it's busy doing something else, or you have another menu popped up, or some other application is grabbing the keyboard/mouse. Olivier, any ideas? I believe that code is yours that I copied and pasted into xfdesktop. It's always worked fine for me.
Agreed. The keyboard grab is still active when the menu tries to grab the keyboard. That's a race condition between the caller and the menu. Maybe you could try to increase the timeout time, ie the time the menu "waits" before bailing out.
I suppose, but I think it's currently 5 seconds... seems like a long time already. I'll look at this again later. Need to sleep now :-P
I can confirm this bug to exist with 'xfdesktop --menu' and 'xfdeskop --menulist'. Both did work for me quite well until I switched to Kernel 2.6.21. Since the keybord shortcuts faile most of the time. But if I execute the commands in a terminal, everything seems to work at first time. It appears, no errors, no waiting, etc. With kernel 2.6.20 and earlier everything works fine for me. I don't know much about it, but maybe it is a problem with dynticks intrdoduced in kernel 2.6.21? Frank
Another remark, I forgot earlier: A right click, resp. a middle click will pop up the menus without errors and in time. So, popping up these xfdesktop menues should be possible with keystrokes too, shouldn't it?
I'll reply even if I'm not the assignee, since I know that peice of code pretty well, being copied from xfwm4 code I wrote. Brian, feel free to disagree, of course ;) (In reply to comment #4) > It appears, no > errors, no waiting, etc. With kernel 2.6.20 and earlier > everything works fine for me. I don't know much about it, but maybe it is a > problem with dynticks introduced in kernel 2.6.21? This is possible indeed. The problem is because the keyboard is still grabbed when the menu popups. Grabs are managed by timestamps, given by the X server. The code that pops up the menu first check to see if the keyboard is available. If so, it will open the menu ant let gtk+ grab the keyboard. But if the grab is not released, then it will start a loop waiting for the grab to become available, until some point (to avoid being stick waiting). If for some reason the timestamp is not updated, then the timeout will always trigger. > Another remark, I forgot earlier: A right click, resp. a middle click will pop > up the menus without errors and in time. So, popping up these xfdesktop menues > should be possible with keystrokes too, shouldn't it? It works because there is no grab active then, since the click and the menu are managed from the same application (xfdesktop in that case). The problem arises only when launched from the shortcuts, which is another separate application.
(In reply to comment #6) > I'll reply even if I'm not the assignee, since I know that peice of code pretty > well, being copied from xfwm4 code I wrote. Brian, feel free to disagree, of > course ;) Haha, nope, you're the expert ^_^. > (In reply to comment #4) > > > Another remark, I forgot earlier: A right click, resp. a middle click will pop > > up the menus without errors and in time. So, popping up these xfdesktop menues > > should be possible with keystrokes too, shouldn't it? > > It works because there is no grab active then, since the click and the menu are > managed from the same application (xfdesktop in that case). The problem arises > only when launched from the shortcuts, which is another separate application. Also, just as pertinent: when you use the mouse to pop up the menu, assuming you aren't typing at the same time, there's no one to have a grab on the keyboard (usually), so there's no need to wait for it to be possible to grab it -- that is, the test in xfdesktop to try to grab should return successfully the first run through.
Create a script called ctrlesc.sh (contents below) and bind ctrl-esc keys to it as a temp workaround. Works for me... #!/bin/sh sleep 0.1 exec xfce4-popup-menu
*** This bug has been marked as a duplicate of bug 441 ***