Merging from Develop branch

[FedericoSpada]

Version 5.3.0

[qwertyzen]

This branch has some good features and bug fixes. I only have issue with one. The new feature where mouse-wheel affects CTkSlider value is undesirable behavior. A parent widget or root may bind mouse-wheel for other functions. So changing the new slider value with mouse-wheel also performs the other action.

In my app, I have used bind mouse-wheel to the root window to change a specific slider in the GUI. So I can change this slider with the pointer being anywhere in the window. This feature was requested by users.

[FedericoSpada]

Hi,
Yours is a very specific case that we can't consider while implementing a new feature.
Moreover, the MouseWheel was already used for the scrollbars, so your design would break already if you ever need to add a CTkScrollbar, CTkTextbox, or CTkScrollableFrame.

I would suggest improving your callback so that it doesn't perform its action if it detects that the mouse wheel was moved over a CTkSlider or CTkScrollbar. Something similar to the following:

def mousewheel_event(self, event: tk.Event) -> None:
    skip = False
    widget = event.widget
    while widget is not None:
        if isinstance(widget, (CTkSlider, CTkScrollbar)):
            skip = True
            break
        widget = widget.master

    if not skip:
        #your actual operation here

In this way, you would benefit from the new change: if the user scrolls the wheel over a Slider or Scrollbar, its value gets updated. If, instead, he/she scrolls elsewhere, a specific Slider would move as before.

[qwertyzen]

Since you mentioned other widgets that bind to mouse-wheel, I tried out an experiment to see how the slider scrolling behaves in a general context. Please have a look at the following example code. This could be an EQ panel in a music app. This will demonstrate the point I was trying to make about this not being a good feature.

import customtkinter as ctk

root = ctk.CTk()
root.geometry('300x400')

sfr = ctk.CTkScrollableFrame(root)
sfr.pack(fill='both', expand='True')
sfr.grid_columnconfigure(0, weight=1)
for i in range(20):
    sl = ctk.CTkSlider(sfr)
    sl.grid(row=i, column=0, sticky='ew', padx=10, pady=10)

root.mainloop()

Scrolling on a specific slider does not reliably modify that slider. Instead, the frame also scrolls and modifies other sliders. If I intend to scroll the window, it also modifies the sliders. Do you think this is reliable behavior?

As a GUI framework you cannot say what is or is not standard GUI practice. As a basic feature, tkinter gives me the ability to bind <mouse-wheel> to the root widget to implement any feature. So I am doing very standard stuff here. Every app have their own unique features and requirements. As an app developer I don't want to hack/fight against the framework (as your solution suggests). A slider is a slider, not a scroller. If an app wants it to scroll, the app developer will add the scroll to it.

If you want the feature, add a new widget called CTkScrollingSlider, so it's explicit. Messing with the default slider will break apps and cause pain to your users.

[FedericoSpada]

You are right: this is unwarranted behavior that I didn't anticipate. But the problem is and was already present, if you add any scrollable object inside CTkScrollableFrame, like CTkTextbox, CTkScrollbar, and another instance of CTkScrollableFrame itself.
I will improve the MouseWheel callback for CTkScrollableFrame so that it works properly.

The change on the Slider was requested in #2777, and I agree with the proposer that it is expected to use the MouseWheel on a slider to change its value. As a library user, I don't want to implement the Scroll behavior each time I use the widget.

tk.Text itself uses by default the MouseWheel event to scroll its view. Binding a callback to the MouseWheel for the entire window will cause problems in any case and with both frameworks. As a developer, it should be our job to find the best solution given the tools we have available.

[qwertyzen]

Hi @FedericoSpada please check the example program I provided in the above comment against your latest commit Improved scroll behavior for CTkScrollableFrame.

This behavior is also unreliable. Now what happens is that the sliders consume the mouse scroll and the scrollable frame stops scrolling as soon as a slider arrives under the mouse pointer and the slider value changes. In this example the ScrollableFrame mouse scrolling is completely untenable. The expectation is that the ScrollableFrame should have priority of the scrolling action.

Please think deeply about this feature and I would like to know what @TomSchimansky thinks about this. I personally think

• Yes, a library developer should intentionally bind mouse-wheel to each Slider they want to scroll.
• Otherwise, provide a separate widget called CTkScrollingSlider to add this as a feature. Optionally, make it opt-in/opt-out, example CTkSlider(parent, update_on_scroll=False, ...).
• This feature does not align with the philosophy of customtkinter and tkinter.
• Don't add a feature for 1000s based on an issue by 1 user. There needs to be community agreement. Please have a committee. Lot's of users rely on customtkinter being stable and deterministic.

P.S: I am aware that cross-platform mouse-scroll is an issue in tkinter with <mouse-wheel>, <Button-4>, <Button-5>, and the event values and attributes being different for each platform. So a user has to implement scrolling for each platform separately. You can provide a custom event <<CTkMouseWheel>> that abstracts away these differences. Then the user or the library just has to bind to this event to get cross-platform scrolling behavior. This would much better align with customtkinter's philosophy.