Hello,
Gladly I will do my best to explain the patch for xsane. You (JB) write
that "it doesn't do much" but the problem was (as I pointed out in the
Ubuntu bug discussion in Launchpad) that the "GdkEventMotion.state"
value originally was masked (AND-ed) with values such as GDK_Num_Lock
(0xff7f) or GDK_Caps_Lock (0xffe5). These values are */not/* bit masks,
they are enumerated values for key codes. So it makes no sense to use
them for bitwise operations. That they worked certainly was not pure
coincidence but maybe a result of trial and error.
The problem on my platform (Ubuntu 10.04 on a fairly new notebook
computer with a second screen) was that GTK delivered the mouse events
with the *0x2000* bit set. (This bit is not defined in "gdktypes.h".) On
my computer, when I try to mark a scan rectangle in the xsane preview
window this bit is always set. And it was not filtered by the strange
GDK key codes. It could not be; they all have the 0xf000 nibble set.
They just are not bit masks.
What I did in my patch was masking away all bits except those xsane is
interested it: the three first mouse buttons. So instead of masking the
"state" bit vector with key codes I mask it with the combination of
(GDK_BUTTON1_MASK | GDK_BUTTON2_MASK | GDK_BUTTON3_MASK) = *0x700*. That
is the essential change. You are right, the other three lines are just
cosmetics (desirable though).
Interestingly, the gdk/gdktypes.h header file says in a comment:
GDK_BUTTON5_MASK = 1 << 12,
/* The next few modifiers are* used by XKB*, so we skip to the end.
* Bits 15 - 25 are currently unused. Bit 29 is used internally.
*/
The 0x2000 bit that caused me (and probably others) trouble is (1 <<
13). So it belongs to those "used by XKB" (X keyboard specification). I
just looked up this specification; it says "Bits 13 and 14 are
interpreted as a two-bit unsigned numeric value and report the state
keyboard group." I humbly admit that I do not understand what the "state
keyboard group" is but to me it seems a good idea to mask these bits
when we are not interested in the keyboard state. And since xsane is
interested only in the first three mouse buttons it seems reasonable to
mask everything else. That is what bit masks are used for. Each bit
counts for itself.
Maybe gdktypes.h ought to define a bit mask to filter those two bits
"used by XKB". At present it does not, it defines only single bits, and
my patch combines such bits to do what is needed. I suppose it was the
original author's idea to ignore any pressed or locked SHIFT, CTRL, ALT
etc modifiers. My patch does this. And it ignores those bits "used by
XKB", which the original code did not.
Please feel free to contact me for further questions.
RF ("Aisano")
