Toggle for hover-scroll being able to affect sliders

[ahydronous]

I just nearly blew out my eardrums by an accidental laptop touchpad palm swipe. Perhaps also best to change the default to not have hover-scroll affect sliders.

[wwmm]

In the past I was not able to convince Gtk4 to disable scroll events on sliders. I have the feeling that this may have the same problem... Maybe it will be easier to handle this in the Qt branch that will eventually replace our Gtk code.

[ahydronous]

I found this StackOverflow answer for the GtkScale widget and this answer for GtkSpinButton. Code below is the GtkScale code. Although if it is viable for EasyEffects I do not know. And from other answers I gather that in time the QT branch is going to be the leading branch. Which would make the effort a little moot..

/* No-op to prevent @w from propagating "scroll" events it receives.
 */
void disable_scroll_cb( GtkWidget *w ) {}

/* Disable scroll on a widget by adding a capture phase event handler and
 * connecting a no-op callback to the "scroll" event.
 */
static GtkWidget *
disable_scroll( GtkWidget *w )
{
        GtkEventController *ec;

        ec = gtk_event_controller_scroll_new(
                        GTK_EVENT_CONTROLLER_SCROLL_VERTICAL );

        gtk_event_controller_set_propagation_phase( ec, GTK_PHASE_CAPTURE );
        g_signal_connect( ec, "scroll", G_CALLBACK( disable_scroll_cb ), w );
        gtk_widget_add_controller( w, ec );

        return w;
}

/* Create a spin button with range, default value, and optionally enabled
 * scrolling.
 */
GtkWidget *
create_scale( double min, double max, double step,
                double value, bool scroll )
{
        GtkWidget *s;

        s = gtk_scale_new_with_range( GTK_ORIENTATION_HORIZONTAL, min, max, step );
        gtk_range_set_value( GTK_RANGE( s ), value );

        return scroll ? s : disable_scroll( s );
}

[wwmm]

I found this StackOverflow answer for the GtkScale widget and this answer for GtkSpinButton

I tried something similar to this in the past #1211. The only difference is that I did not know about gtk_event_controller_set_propagation_phase. But unless it does some amazing magic at least for a GtkScale this approach is probably not going to be fully successful. The reason is that when I read GtkScale source code in the past I saw that Gtk developers had the "amazing idea" of forcing the creation of their own event controller inside the widget. What made what the example above tries to achieve pointless. In the end it ignores the event in the controller it created. The one Gtk developers forced inside the widget still changes the widget values anyway.

Maybe things are different for spinbuttons. I did not test them at the time.

Although if it is viable for EasyEffects I do not know.

Even if the solution now works I see two main problems. EasyEffects has a lot of spinbuttons and scales. Implementing this for all or even half of them would be painful. And on top of that most of our widgets are created and handled in xml code. But as far as I know the event controllers and their callbacks have to be handled through C code. So now some widgets that needed just some minimal interaction through C code would need more C code. Not the end of the world. But not pleasant either.

And from other answers I gather that in time the QT branch is going to be the leading branch. Which would make the effort a little moot..

Yes. Definitely it does not make sense to put all that effort in a branch that is going to be replaced. And even in the Qt branch it would probably be better to just add an option for this to the widgets where the problem you faced have more dangerous consequences. Like I said above we really have a lot of these controls. The only advantage Qt has is that we already have our own custom spinbutton in the Qt branch. So handling this there is easier. But not to the point where it is not a pain to do this for all controls.

[ahydronous]

the widgets where the problem you faced have more dangerous consequences

Once / if you do do this, it might be worth it to also add a modifiesVolume or danger tag or something to the things that maniplate dB directly. If you want to add more features to these in the future (like a max dB warning system or something), they'll be easier to track down.

[wwmm]

So much has changed that is probably better to close this issue