[ looks like you're not subscribed to rox-devel, so it was rejected ]
---------- Forwarded message ----------
Date: Wed, 8 Aug 2012 09:33:30 -0400 (EDT)
From: Norm Pierce
Subject: ROX-Filer ungrab bug
Here is another bug related to the GTK/GDK 2.18 introduction of
"client-side windows". And I've attached a patch to fix this.
Some symptoms are the occasional need for extra clicks to launch an
application or the inability to bring up the ROX-Filer menu without first
left-clicking on the backdrop. This happens after using a window manager
A worst-case scenario would be when used with a window manager that has a
menu for each mouse button. In that case, once the user has brought up
any of those menus, it is impossible to launch applications or bring up
the ROX-Filer menu by clicking on an icon.
The following procedure will test for this bug. The procedure assumes
that the system is running a window manager that puts up a menu when the
user presses the right mouse button on the backdrop (such as JWM). It also
assumes that the following ROX-Filer options are checked:
x Single-click navigation
x Single click to open
x Override window manager control of the pinboard and panels
x Pass all backdrop mouse clicks to window manager
1. Click the right mouse button on the desktop to bring up the window
manager's root menu.
2. Click any mouse button on the desktop to dismiss the menu.
3. Click the left mouse button once on an icon. The application should
launch. If it does not launch until you click a second time, you have this
Also, you can go through steps 1 and 2 again, then try this for step 3:
3. Click the right mouse button once on an icon. The ROX-Filer menu should
come up. If the window manager's root menu comes up, you have this bug.
Note that, in both flavors of step 3, the bug will appear even if you
click an icon in a ROX-Filer window instead of the desktop.
Here is what I think is happening:
When ROX passes the button-press event to the window manager, it ungrabs
the pointer using the Xlib function XUngrabPointer(). When the window
manager is done the next button-press-event will go to whatever X window
is under the pointer. This worked fine when the pinboard and all of the
icons on the pinboard were real X windows.
But now, the pinboard has only the one X window, so if the pinboard or any
of its icons is under the pointer, the event will go to the pinboard's X
window, but not necessarily to the correct client-side child window of the
pinboard. It will go to the client-side window that grabbed the pointer in
the first place -- either the pinboard client-side window itself, or one
of its client-side children. If the user has just used the window
manager's menu, the pinboard client-side window is the one that grabbed
the pointer, so the next click will act as if it was on the backdrop, even
if the pointer is currently over an icon.
I replaced the call to the Xlib function, XUngrabPointer(), with a call to
the GDK function, gdk_display_pointer_ungrab(). This function will also
tell X to release the grab, but it additionally tells GDK to release the
grab so that the next button-press event will go to whatever client-side
window is under the pointer, not the window that made the grab.
At least that is my best guess -- I've not looked at the GDK source to
This patch has been tested and is in use in the Puppy Linux Wary 5.3 and
Puppy Linux Racy 5.3 distros and works well. I have also tried running
with an ancient version of Blackbox to ensure compatibility with
ROX-Filer's "Blackbox root menus hack" option. For more details see the
diff -u old/pinboard.c new/pinboard.c
--- old/pinboard.c 2011-10-22 13:48:50.000000000 -0400
+++ new/pinboard.c 2012-03-13 08:00:47.000000000 -0400
@@ -1363,7 +1363,8 @@
xev.type = ButtonPress;
- XUngrabPointer(gdk_display, event->time);
+ gdk_display_pointer_ungrab( gdk_x11_lookup_xdisplay( gdk_display ),
+ event->time ) ;
xev.type = ButtonRelease;