Tk Source Code

As reported by rz in the Tclers' chat, using the mouse wheel over the scrollbar
in the following demo has no effect:

grid [text .t -yscrollcommand {.y set}] -row 1 -column 1 -sticky nesw
grid [ttk::scrollbar .y -command {.t yview}] -row 1 -column 2 -sticky ns
.t insert end [string repeat 1\n2\n 100]

This seems to serve as a workaround:

foreach e {Button-4 Button-5 MouseWheel} {     
    bind TScrollbar <$e> [bind Scrollbar <$e>] 
}

Not related, but also in ttk::scrollbar bindings is [d1d4286ddaa].

TIP 563 is voted yes and merged to trunk with checkin [2fd8b8cc]

The horizontal scrolling without shift is proposed by TIP563

[https://core.tcl-lang.org/tips/doc/trunk/tip/563.md]

Committed to core-8-6-branch by commit [ec79505e] and trunk (with button-6/7) by commit [5cc8fffe].

I hope, this resolves the bug.

Thank you all and specially Csabah,
Harald

Thank you for your remarks.
Implementation is updated to the redirection solution.
Thank you, that works great !

The following is a marginal isse and I don't pretend on it at all.
The upper solution is great and works for me.

<h1>Personal opinion on the requirement of shift on horizontal scrollbars</h1>

I can understand that you need the shift button to make a difference, if there are two possibilities.
But the bindings of a (ttk::)scrollbar are AFAIK only active, if the mouse is over it. I find it annoying, that you require shift, if you are over a horizontal scrollbar.

So some code to test:

<verbatim>
set eventList [list <MouseWheel> <Shift-MouseWheel>]
switch [tk windowingsystem] {
	aqua {
		lappend eventList <Option-MouseWheel> <Shift-Option-MouseWheel>
	}
	x11 {
		lappend eventList <Button-4> <Button-5> \
				<Shift-Button-4> <Shift-Button-5>
	}
}
foreach event $eventList {
	bind TScrollbar $event [bind Scrollbar $event]
}
grid [text .t -wrap none -yscrollcommand {.y set} -xscrollcommand {.x set}] -row 1 -column 1 -sticky nesw
grid [ttk::scrollbar .y -command {.t yview}] -row 1 -column 2 -sticky ns
grid [ttk::scrollbar .x -orient horizontal -command {.t xview}] -row 2 -column 1 -sticky ew
grid rowconfigure . 1 -weight 1
grid columnconfigure . 1 -weight 1
.t insert end [string repeat [string repeat 1 100]\n 100]
</verbatim>

If you use the scrollwheel within the text widget, shift activates vertical scroll. This is good, as there is a choice.

But the same is true for the scrollbars, which is IMHO not really practical.
The scrollwheel should scroll in its direction independent on shift.

This is IMHO what most user expects. Just go on the scrollbar and move the scrollwheel to scroll this scrollbar.

Thank you,
Harald

On X11, the XFCE scrollbars work both without and with shift.
As implemented.

Though firefox on X11 is different -- but they're implementing their own.

Windows seems to always scroll vertically unless there is only a 
horizontal scrollbar.   Mac only seems to attach the mousewheel
to the vertical scrollbar.  I guess both of those can be ignored,
as they're not implementable.

I would normally say to match the window manager, but Windows and 
Mac are both odd.

Once again to the difference between <MouseWheel> and <Shift-MouseWheel>:

If you have a horizontally scrollable widget $w with a Tk core horizontal scrollbar and the mouse is over the scrollbar then <Shift-MouseWheel> will scroll the widget horizontally, while <MouseWheel> (w/o the Shift) has no effect over the horizontal scrollbar.  Your proposed implementation for the ttk::scrollbar behaves differently: Over the ttk::scrollbar both <Shift-MouseWheel> and <MouseWheel> (w/o the Shift) will trigger a horizontal scrolling (althogh over the widget $w only <Shift-MouseWheel> will give rise to horizontal scrolling).

In my opinion, the mouse wheel should work in connection with a ttk::scrollbar in EXACTLY the same way as with a Tk core scrollbar.

Ah, I understand. You redirect to Scrollbar.
That works, I have tested it.

But I have no idea, if this is ok for tk core.

Thank you,
Harald

Thank you, Csaba.
I can only say that:

   -   I don't understand when shift is active. I tried it with scrollbar, no difference between shift and non-shift.
   -   I don't understand at all your code.

Sorry,
Harald

I am not sure removing the shift-versions was a good decision.  If a widget is horizontally scrollable and the mouse is over the widget then the (class) bindings for <Shift-MouseWheel> will scroll the widget horizontally.  On the other hand, if the mouse is over the widget's horizontal scrollbar then in your implementation the same scrolling effect will be triggered by both <Shift-MouseWheel> AND <MouseWheel>, although the latter is commonly used for vertical scrolling.

IMHO, the mouse wheel bindings for TScrollbar should work EXACTLY the same as those for Scrollbar.  This can be achieved with an appropriately modified version of your proposed implementation or with the following code:

    set eventList [list <MouseWheel> <Shift-MouseWheel>]
    switch [tk windowingsystem] {
        aqua {
            lappend eventList <Option-MouseWheel> <Shift-Option-MouseWheel>
        }
        x11 {
            lappend eventList <Button-4> <Button-5> \
                              <Shift-Button-4> <Shift-Button-5>

        }
    }
    foreach event $eventList {
        bind TScrollbar $event [bind Scrollbar $event]
    }
    unset eventList event

For Tk 8.7a3 and later, the x11 case above should be extended by <Button-6> and
<Button-7>.

It is now checkin [d99b1940] of branch [bug-2b8fa6fd].

Checkin [082200db] works for me.

It is basically copied from 'scrlbar.tcl'.

The shift-versions are removed. For me, if I am over a scrollbar, I always want to scroll this scrollbar, independent if it is vertical or horizontal.
And I did not find out what the shift-version does in practice.
For me, it scrolled the same, with or without shift.

Any comments ?

Thank you,
Harald

I would appreciate, if ttk::scrollbar would also have scrollwheel bindings in the core, like "scrollbar".

Specially with great package "scrollutils", you may now scroll "everywhere", but on the scrollbar itself.

Was there any outcome in the discussion below?
Are there any rationals not to include it ?

Or is there a volunteer needed or do we wait for TIP474?

Thank you,
Harald

There is currently a discussion on Tcl-Core list about this kind of event.

See also [681692] perhaps.