After setting a keyboard shortcut to the command "xfdesktop -menu", the shortcut does not work. Have tried with Control+Escape and Control+Alt+M
I can reproduce this with 'xfdesktop -windowlist' also. However, for me, the shortcut works occasionally.
yep, i'm seeing this too. i set the shortcut, and hit it, and the menu pops up. click elsewhere to close the menu, hit the shortcut again, and so on. it works for the first 5 or so times, and then stops working. my other shortcuts (one of them to bring up a terminal) work fine. running 'xfdesktop -menu' repeatedly from a terminal works fine.
Well, the launcher didn't work for me, and running it from a console gives a segfault. This didn't happen in RC2.
(In reply to comment #3) > Well, the launcher didn't work for me, and running it from a console gives a > segfault. This didn't happen in RC2. This is a completely separate issue, please report a new bug. Try to get a backtrace from the crash in gdb.
Some debugging clearly shows the problem is with xfdesktop and not with xfwm4 because the shortcut is spawned by xfwm4 correctly, xfdesktop send the client message and the message is received by the running process.
As Olivier found, this was caused by the gtk_menu_popup() code not being able to get a keyboard grab before trying to pop up the menu, causing it to give up. Solution was to steal a bit of xfwm4's code to wait for a grab (with timeout) before trying to pop up the window. Fixed in trunk and xfce_4_2. Finally!
Created attachment 322 Proposed solution for the windowlist menu Sorry to wake up a closed bug... The same problem applies to the windowlist menu, and the fix is only for the desktop menu (as of svn revision 18313). Attaching a patch to address the problem for the windowlist as well.
Applied, and stuff.
This bug was reintroduced with the new xfce4-menu. I'm unable to reopen it.
(In reply to comment #9) > This bug was reintroduced with the new xfce4-menu. I'm unable to reopen it. >
Sorry guys, works fine for me here using 4.4 and SVN trunk. Try killing xfdesktop, then run it from a terminal, and try 'xfdesktop -menu' from another terminal. See what output you get, and post it here.
With SVN built after your post I get this: [pasi@arch ~]$ xfdesktop & disown [1] 6289 [pasi@arch ~]$ ** (xfdesktop:6289): CRITICAL **: Unable to get keyboard/mouse grab. Unable to popup desktop menu ** (xfdesktop:6289): CRITICAL **: Unable to get keyboard/mouse grab. Unable to popup desktop menu Every time Ctrl+Esc is hit, and after 20 or so tries the menu finally pops up. `xfdesktop -menu` from command line works fine.
To be accurate, it's one error line per key press.
The problem seems to be related to the speed at which the button combination is pressed. i.e. While Ctrl is kept down, hit and release Esc very quickly -> the menu pops up. If Esc is kept down for a short moment, error is printed.
I think there's a separate bug open somewhere about this. This is actually a gtk 2.12 problem, but we can work around it, I think. Can you try current svn? I increased the time it tries to grab the mouse/kbd by 3x.
I'm not quite sure if there's change in it. It is possible that it doesn't require as fast tap-and-release as before, but the change is quite small. I'm running gtk2 2.10.14.
Pasi, can you look in xfdesktop/trunk/common/xfdesktop-common.c, line 248? You can mess with the (i++ < 300) value - increasing 300 to something higher will make it try longer. If you can figure out a decent value that gives you close to 100% success, let me know what it is. I personally can't reproduce this, so...
Okay, after a quite a few tests I'd say a value of 2000 makes a pretty safe worksforme value. Do you have any thoughts on what kind of things in X configuration, for example, might affect this? I'm curious to understand why I'm (so heavily (as in 0.03 vs. 0.2 seconds)) affected by the problem and you're not.
(In reply to comment #18) > Okay, after a quite a few tests I'd say a value of 2000 makes a pretty safe > worksforme value. > > Do you have any thoughts on what kind of things in X configuration, for > example, might affect this? I'm curious to understand why I'm (so heavily (as > in 0.03 vs. 0.2 seconds)) affected by the problem and you're not. Nope, no idea. Do you have a blazing-fast computer with lots of RAM? It occurs to me that 0.03 seconds isn't much time to release a key. My assumption is that the time to load xfdesktop and get to the point where it's doing the grab test dominates, and the 0.03 seconds is just enough for most people. But if you have a really fast computer, the xfdesktop load is really quick? I dunno - just pulling stuff out of my ass here, really. (Actually, the original value was 100; I upped it to 300 before I asked you to test; so 0.01 seconds was the original timeout.) Olivier, any ideas? I can change the value to 2000; I don't think 0.2 seconds in a busy-loop is too terrible, but it would be nice to know *why* this is necessary for some people but not others.
Can anyone explain to a newbie how to change the timing so this works? I follow the basic idea described here, but have no idea what file I'm supposed to edit or how, for xfdesktop. Thanks.
Ok, I'm going to set this to 2500 in both 4.4 branch and trunk. After the release this weekend we can see if anyone who only follows stable still has this problem. I think we can live with xfdesktop potentially freezing for 1/4 of a second. We'll close this later if this solution seems workable for everyone.
(In reply to comment #20) > Can anyone explain to a newbie how to change the timing so this works? I follow > the basic idea described here, but have no idea what file I'm supposed to edit > or how, for xfdesktop. Thanks. > See comment #17.
*** Bug 3234 has been marked as a duplicate of this bug. ***
This was fixed in http://git.xfce.org/xfce/xfdesktop/commit/?id=82b385d0e243dc26429b8cc647630f18107ebe6a