Tk Source Code

Most modern mouses report horizontal scroll events as buttons 6 and 7 under X11.  Tk does not allow specifying an event handler directly for them:

::bind all <Button-6> {puts "Pressed button 6"}
specified keysym "6" for non-key event

Even more, using the usual short-hand notation for button events unexpectedly binds the keyboard instead:
::bind all <6> {puts "Pressed button 6"}
# Scroll does nothing, but pressing "6" key prints the above message.

Tk should support horizontal scroll buttons on X11.  Ideally, the button number should not have any restriction, although the more conservative option of supporting up to button 7 would be welcome.  The patch below implements the latter:

diff --git i/generic/tkBind.c w/generic/tkBind.c
index 9cd3b7b..7e489b6 100644
--- i/src/tk8.6.4/generic/tkBind.c
+++ w/src/tk8.6.4/generic/tkBind.c
@@ -3937,7 +3937,7 @@ ParseEventDescription(
        p = GetField(p, field, FIELD_SIZE);
     }
     if (*field != '\0') {
-       if ((*field >= '1') && (*field <= '5') && (field[1] == '\0')) {
+       if ((*field >= '1') && (*field <= '7') && (field[1] == '\0')) {
            if (eventFlags == 0) {
                patPtr->eventType = ButtonPress;
                eventMask = ButtonPressMask;

@chrstphrchvz: Thanks for the correction: Yes, you are right. It's indeed expected.

For 8.6 the importance is that scripts don't need to be modified, that's not expected in a patch-release. In 8.7, there are more possibilities to change things.

…unless binding to <Button> and test for the right %b value

I'm not sure this is the case given how the translation is implemented. Even when using <Button>, %b and (%s & 1) appear to use the post-translation values, which I think is expected.

In Tk 8.6, a simple translation from Button6/7 to Shift-Button4/5 was added, but still scripts cannot bind to those buttons (unless binding to <Button> and test for the right %b value).

So, in Tk 8.6, I consider it only partially fixed, in the sense that the Buttons work but cannot be accessed from scripts like the other buttons. In Tk 8.7 that should be fully fixed now: We can now create bindings for buttons up to 9, in the same way as Buttons 1-5 in Tk 8.6

More changes are in preparation (e.g. Interchanging Buttons 2 and 3 on Mac, and translating buttons 4-7 on X11 to MouseWheel events), but that's out-of-scope for this Ticket. TIP #474 is in preparation for that (implementation almost finished, but not complete yet)

So, closing this one.

Thanks!

I believe this issue is fixed in Tk 8.6.10; see [b353987a]. As part of addressing [5da1d76e], buttons 6 and 7 will be translated to <Shift-4> and <Shift-5> respectively on X11, so that those bindings handle both emulated (shift+vertical scrolling) and non-emulated horizontal scrolling. The approach for later Tk versions might be different, though.

Jan, thank you for your quick effort on this in response to [1fb7af62]. I am taking a look at the branch, but have not tested it (I have yet to try 8.7 at all), nor do I have any real feedback as to how the approach might change other than having it also address [6ff8f7b0]. I would not call myself a seasoned C expert, so were I to try offering any nitpicks, this is what I would think of so far:

• Should mask/state variables, functions, etc. consistently be of type unsigned int? If so, possible instances to adjust (there are many more instances in the existing code):
  • int mask in CanvasBindProc() (tkCanvas.c)
  • int TkGetButtonMask() and int buttonMasks[] (tkEvent.c)
  • the int mouseButtonState field in struct TkDisplay (tkInt.h)
  • the int state field in struct TkCanvas (tkCanvas.h)
  • might not need to cast result of TkGetButtonMask() in TkPointerEvent() (tkGrab.c)
  • int state, mask, changes in Tk_UpdatePointer() (tkPointer.c)
• Should AnyButtonMask be redefined/reintroduced as meaning the mask corresponding to AnyButton (X.h)? If so, should it be used instead of literal 0 in places where Button1Mask etc. appear? Instances of this:

  buttonMasks[] = {0, Button1Mask, …}

  and

  return (button > Button9) ? 0 : buttonMasks[button];

  in TkGetButtonMask().

• In tkProcessMouseEvent() and in ButtonModifiers2State() (tkMacOSXMouseEvent.c), I wonder if there is a better way to express this:

  state |= (buttons & 0x1F) * Button1Mask;

  One option might be to just expand it out (as done for TkWinGetModifierState() in tkWinPointer.c), since there's only 5 buttons to handle, and it would probably be easier to accommodate buttons 2 and 3 being swapped ([6ff8f7b0])—whereas the currently compact bitshift approach might become complicated:

  if (buttonState & 0x01)
    state |= Button1Mask;
if (buttonState & 0x02)
    state |= Button2Mask; /* change to Button3Mask to match Windows and X11 */
if (buttonState & 0x04)
    state |= Button3Mask; /* change to Button2Mask to match Windows and X11 */
if (buttonState & 0x08)
    state |= Button4Mask;
if (buttonState & 0x10)
    state |= Button5Mask;


Fully implemented now in the [bug-38dc27bd1d] branch. Please test (who-ever can)!

Cc'ing myself in case of updates.

Note that the xdotool click utility can be used for testing, should anyone not have access to capable hardware.

There is discussion about this currently on Tcl-Core list.

Thanks François, guess you are right that the solution is not complete yet.

Shouldn't modArray be updated as well when fixing this bug?

Fixed in trunk. Will be available in Tk 8.7

Sorry for the delay.

Jan, I have tested the changes.  The functionality works: the horizontal scroll buttons are now recognized.  One of the changed tests is failing, though:

==== bind-27.2 button names FAILED
==== Contents of test case:

    bind .t <Button-@> foo

---- Result was:
bad event type or keysym "@"
---- Result should have been (exact matching):
specified keysym "@" for non-key event
==== bind-27.2 FAILED

A number of unrelated tests are failing as well.  Is that somehow expected?

...
Tests ended at Tue Mar 22 09:03:47 CET 2016
all.tcl:        Total   9353    Passed  8243    Skipped 1049    Failed  61
Sourced 91 Test Files.
Files with failing tests: bind.test canvText.test focus.test font.test grid.test scrollbar.test textDisp.test textWind.test unixFont.test unixWm.test winfo.test


Harald, I feel honored by your words, thank you very much!  I would definitely be interested in getting more involved in Tk, although, as with BWidgets, I would most definitely need guidance at the start.  Do you have any idea how should I proceed?

Thank you!

Adrián, please try [56355af1f8411fff]. I see no problem supporting buttons up to '9', as long as the test-suite shows that it doesn't cause regressions. It looks fine to me. New (trivial) test-cases added and documentation modified as well.

Please provide feedback if this works for you, then I'll merge to trunk.

I have no particular opinion on this suggestion, only that I have no power to grant any rights.

Perhaps it is wise to grand commit rights to Adriàn.

He is actively committing to BWidget and I can recomment him.

-Harald

The patch looks very simple, but I cannot try it since I don't have a mouse with enough buttons!

Would you mind to create a few new test cases that we could insert in the existing test suite, so that we cover the new functionality?

Also the documentation should be updated by the patch. Currently the man page for bind explicitely states that mouse buttons are 1-5.

Can you take care of all this and provide an updated patch? Thanks!