See if fix_mouse_wheel2 branch is better suited as base for new work.
Cristian
Thanks.I've pushed a couple of patches and i believe that on linux and mac
should already be fine.Anyone that is willing to compile the latest code and
try the mousewheel behavior (especially on mac) can help
>
> placing library functions is very error prone. A new developer should not
> need to read all the code to contribute to the project and he should be
> able to assume that standard functions behave normally.
> We can call it scidBindMouseWheel or consistentBindMouseWheel or
> nofocusBindMouseWhe
Cristian Stoica wrote:
So instead of adding scroll to every canvas and then removing the
wrong ones, one by one, I prefer to know exactly what bindings there are.
I agree, this is certainly better.
Two ideas:
- ttk_bindMouseWheel (preferable ttk::bindMouseWheel
for transparency) could make
> Unfortunately there are still some small issues, for example:
> - Without the "break" in ttk_bindMouseWheel the message continues to be
> propagated (add a line "return" in gamelist.tcl:823 to try what I mean)
>
With disabled glist.ybar_, mouse wheel is handled by Treeview class but
in current ma
Hi Cristian,
thanks for your work.
Unfortunately there are still some small issues, for example:
- Without the "break" in ttk_bindMouseWheel the message continues to be
propagated (add a line "return" in gamelist.tcl:823 to try what I mean)
- Mousewheel no longer works over the board when browsin
