DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature Okay, so upon further investigation, it seems X11 sets XButtonEvent::state to 1 << 13 when an alternative keymap is set. As for why, I don't know, however as far as I'm aware this is actually an illegal value for the state member (the current manpage at http://www.xfree86.org/current/XButtonEvent.3.html suggests the bitwise OR of all the allowed Masks is 2^13 - 1). As such, there are actually two fixes for STR #2493: 1) Bitwise AND xevent.xbutton.state with 0x1FFF (2^13 - 1) when setting e_state. This will set all bits above the 12th to 0, completely fixing the bug, and fairly cheaply, too. I don't quite see X changing it's API at this point, so this could be a safe fix. It will need to be fairly heftily documented within the (FLTK2) code though, otherwise it will just look like a magic number. 2) Change the way 2.x handles its RELEASE event - upon digging, I noticed that FLTK1.x suffers the same fate with its use of fl_xevent->xbutton.xstate (which only proves that this "bug" is consistent between FLTK version), however the default RELEASE event seems to handle things in a different way, which seems to sidestep this bug and provide the desired result. I can provide a patch for both versions, depending on what the best solution may be. At this point, I'm tentatitve to use the first approach; whilst it will solve the problem I don't know how safe it is for future use, and will get onto a few X mailing lists (or IRC channels) to find out why the heck X is sending an illegal (at the moment) value for XButtonEvent::state All comments and thoughts, from both 1.x and 2.x points of view are welcome at this stage..... Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
