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><Shift-4></code> and <code><Shift-5></code>) or <code><Shift-MouseWheel></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><Shift-MouseWheel></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><MouseWheel></code> bindings. The approach for adding these bindings would be to bind to <code><ButtonPress></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><Shift-4></code> and <code><Shift-5></code> on X11, similar to how non-emulated horizontal scrolling already looks to Tk programs on Windows and Aqua as <code><Shift-MouseWheel></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><Shift-4></code>/<code><Shift-5></code> for horizontal scrolling than to use <code>%b</code> to detect buttons 6/7 in the absence of <code><6></code>/<code><7></code>, it might want to be noted that existing usage of <code>%b == 6</code> or <code>%b == 7</code> (without equivalent <code><Shift-4></code>/<code><Shift-5></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><Shift-MouseWheel></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. |