If I compile xfdesktop without monitoring support[1], I can only activate the menu items inside a sub-menu by hitting Enter. It works hardly never with the mouse (it worked like one or two times, weird). All the items in the root menu are working fine with the mouse however. [1] --disable-desktop-menu-dir-monitor I followed your advice and looked inside libxfcegui4, but I couldn't get the lib to print its debugging output even that I compiled with --enable-debug=full.
Err, actually it does that with or without monitoring.
I can confirm that
Sorry guys, but it works fine here. Unless you can do some debugging on your own, I don't think I can help.
maybe it's gtk related ? (I'm using 2.12.1)
I have GTK 2.12.1 as well, and I have found a funny trick. Open the menu with a keybind or from command line (xfdesktop --menu), and tada the mouse clicks are always working. I had like to try another window manager, but right now is not the moment :)
I comment here in case I forget about it… The menu in the panel works without problem with the left mouse clicks. The problem is only in the desktop applications menu, and as said only the items inside sub-menus. As an update, I have found out that I can activate these items by right click furthermore of <enter>, and that left and middle clicks don't (should be MOUSE0 and 1 in gtk).
Sorry, still works fine for me here. All mouse buttons work, keyboard control works. You can try adding some printfs to lbixfcegui4/xfce-appmenuitem.c, _command_activate_cb() to see if it's getting called. Otherwise I dunno...
(In reply to comment #6) > As an update, I have found out that I can activate these > items by right click furthermore of <enter>, and that left and middle clicks > don't (should be MOUSE0 and 1 in gtk). And I forgot about another thing, if I run xfdesktop --menu the left click works just perfect. So there is a weirdness hidden in some byte, the right click is keeping some hostages. I will comment again after some printf in libxfcegui4.
Do you see a similar problem with the windowlist? This is a hack, but try: xfce-desktop.c, line 1089 -- change 'button' to '0'. See if that works. If it does, something funky is going on. In that case, put a printf() right before that line that prints out the value of 'button' and let me know what it prints out, and which button you actually pressed.
(In reply to comment #9) > Do you see a similar problem with the windowlist? No. > This is a hack, but try: xfce-desktop.c, line 1089 -- change 'button' to '0'. > See if that works. If it does, something funky is going on. > > In that case, put a printf() right before that line that prints out the value > of 'button' and let me know what it prints out, and which button you actually > pressed. button is 3 when I click the desktop, and 0 if I call xfdesktop --menu. By replacing button with 0 it just works <tm>.
So it works if you change 'button' to be '0' all the time in the function call? Damn, that's retarded. The idea is that if you want to pop up a menu that isn't in direct response to a mouse event, you pass '0'. Otherwise, if you have an actual event structure, you pass GdkEventButton::button (which is what I'm doing -- button 3 == right mouse button, so that's correct). Something is broken, though, and I don't know what. Mike, you're using the same version of gtk as I am... so weird. I committed this hack, so I guess this is closed for now, tho I'm not happy about it.