Tk Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket UUID: 5da1d76e011f3bb30712e6c896d2a170abf3deeb
Title: X11: add default bindings for non-emulated horizontal scrolling to Tk 8.6
Type: RFE Version: 8.6.9.1
Submitter: chrstphrchvz Created on: 2019-08-18 07:00:52
Subsystem: 01. Bindings Assigned To: jan.nijtmans
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2019-08-22 14:36:05
Resolution: Fixed Closed By: chrstphrchvz
    Closed on: 2019-08-22 14:36:05
Description: (text/x-fossil-wiki)
In light of [7ff5f55b] and the recent efforts on the mousewheel-refactor branch, would it be desirable to add default bindings in Tk 8.6 for non-emulated horizontal scrolling on X11 (i.e. buttons 6 and 7), particularly where there are already bindings for emulated horizontal scrolling (i.e. using <code>&lt;Shift-4&gt;</code> and <code>&lt;Shift-5&gt;</code>) or <code>&lt;Shift-MouseWheel&gt;</code> (for non-X11 platforms)? (Currently the only bindings for emulated horizontal scrolling appear to be the listbox, scrollbar, and text widgets; TtkScrollable and the cscroll.tcl demo appear to be the only other instances with <code>&lt;Shift-MouseWheel&gt;</code>.)

This is different from [38dc27bd], as events for binding directly to buttons 6 and higher will likely not arrive until after 8.6, and might even be replaced with <code>&lt;MouseWheel&gt;</code> bindings.

The approach for adding these bindings would be to bind to <code>&lt;ButtonPress&gt;</code> and then check if <code>%b</code> is 6 or 7. (It might also be possible to have button 6 and 7 be translated to <code>&lt;Shift-4&gt;</code> and <code>&lt;Shift-5&gt;</code> on X11, similar to how non-emulated horizontal scrolling already looks to Tk programs on Windows and Aqua as <code>&lt;Shift-MouseWheel&gt;</code>; but I think that is a less desirable approach.)

For more aggressive refactoring of emulated and non-emulated horizontal scrolling into single binding scripts, bit 0 of <code>%s</code> (the event state field), i.e. <code>(%s & 1)</code>, can be used to tell if the shift key is pressed.
User Comments: chrstphrchvz added on 2019-08-22 14:36:05: (text/x-fossil-wiki)
It works! Thanks for addressing this, Jan. I do like how relatively simple the translation approach is.

I think the main reason I thought that approach might be less desirable is because it has a broader impact than making the default bindings more complex by checking <code>%b</code>. Even though I imagine Tk program developers are more likely to use <code>&lt;Shift-4&gt;</code>/<code>&lt;Shift-5&gt;</code> for horizontal scrolling than to use <code>%b</code> to detect buttons 6/7 in the absence of <code>&lt;6&gt;</code>/<code>&lt;7&gt;</code>, it might want to be noted that existing usage of <code>%b == 6</code> or <code>%b == 7</code> (without equivalent <code>&lt;Shift-4&gt;</code>/<code>&lt;Shift-5&gt;</code> bindings) will break, as well as usage where shift+6/shift+7 has a different effect than 6/7 (although such usage might not be a good idea, since <code>&lt;Shift-MouseWheel&gt;</code> on other platforms just indicates horizontal scrolling, not whether the shift key is actually pressed). I don't think I'm a sufficiently experienced Tk programmer to tell whether that is an acceptably unlikely inconvenience, but maybe the important thing is that 6/7 were not well-supported to begin with, and this change is welcome.

jan.nijtmans added on 2019-08-22 06:43:42:
Fixed in core-8-6-branch.

jan.nijtmans added on 2019-08-19 21:58:01: (text/x-fossil-wiki)
Added experimental [https://core.tcl-lang.org/tk/timeline?r=rfe-5da1d76e01-bis] branch, in which Buttons 6/7 are simply translated to Shift 4/5. As suggested. Surprisingly simple!

jan.nijtmans added on 2019-08-18 21:24:51:
Please test/review the [rfe-5da1d76e01] branch. Does this work, and does what this RFE suggests for you?

I think that it's no problem defining additional <ButtonPress> bindings. If user programs do that, the User program definition wil break the default Button 6/7 handling, but it doesn't work either way now so that's not a regression. But I would like to do more testing (help appreciated!) before definitely concluding that it doesn't do harm.

This branch should be "merge-mark"-ed to trunk, since trunk already has proper Button 6/7 handling.