Closed dtorop closed 3 years ago
This seems to be a GTK thing -- difference in behavior between smooth scrolling vs. "regular" scroll events.
Here's a comparison of bauhaus slider widgets events before commit 6ce15b21364e9011b7b990deb66bb1db79623a67 and current code. This looks at first scroll event on inactive widget/window, then subsequent scroll events:
value | prior | current |
---|---|---|
GDK_SMOOTH_SCROLL_MASK | not set | set |
scroll events direction |
GDK_SCROLL_UP /GDK_SCROLL_DOWN |
GDK_SCROLL_SMOOTH |
first scroll event is_stop |
0 | 1 |
first scroll event delta_y |
0.0 | 0.0 |
subsequent scroll events is_stop |
0 | 0 |
subsequent scroll events delta_y |
0.0 | 1.0 or -1.0 |
Note that the delta_y
is only set for smooth scroll events. For "regular" scroll events direction
determines the "delta". In all these cases delta_x
is 0.0.
Even if gtk_widget_grab_focus()
in dt_bauhaus_slider_scroll()
is removed, the smooth scroll behavior is unchanged.
There's probably a way to adjust GTK widget setup to make this work again...
Interestingly, I only see this behavior on darktable startup -- first scroll of an inactive bauhaus widget. Hence I've noticed when testing (lots of starting from scratch & scrolling a widget) but it may not be a big problem for day-to-day use.
This seems to be a documented and hard to fix bad interaction between GTK and xinput.
Some references:
https://bugzilla.gnome.org/show_bug.cgi?id=675959 "This is an inherent limitation of the XI2 protocol that has been acknowledged by its designers. Not much we can do about it." - Matthias Clasen
https://gitlab.gnome.org/GNOME/gtk/-/issues/558 aka https://bugzilla.gnome.org/show_bug.cgi?id=750994 "This is due to xi2 protocol deficiencies around valuators." - Matthias Clasen
Is that a bug, however ? Because scroll interactions are fluid and sloppy (and primarily intended to scroll the viewport), so it seems to me a good safety measure to disable them on inactive widgets. The "focus on hover" paradigm is brittle.
The use case when this is noticeable for me is when the first mouse wheel scroll on an iop is ignored on a newly opened darktable instance. But this is really not a common occurrence except in testing -- any successive scroll works.
It seems like GTK always figures out the scroll capabilities of an input device the first time it is used in a newly focused window. And to do this it needs to throw away the first input event. This behavior may be necessary to make smooth scrolling work, as it wasn't present before.
This is such a corner case, and isn't a dt bug so much as a bug in the relationship between at dt dependency (GTK) and one of its possible dependencies (XI2), that I don't think it's worth spending time on. Is there way to close this bug report and mark it "won't fix"?
Describe the bug/issue When a bauhaus widget is in an "off" iop or an inactive top-level window, the initial scroll when the mouse over it has no effect on its value. Successive scrolls do change its value.
To Reproduce
Note that this behavior occurs with both slider and combobox widgets.
Alternate reproduction:
Expected behavior First scroll on the widget should change its value.
Which commit introduced the error
6ce15b21364e9011b7b990deb66bb1db79623a67 Enable GDK_SMOOTH_SCROLL_MASK for all systems
Platform
Additional context Please provide any additional information you think may be useful, for example:
release-3.4.1
andrelease-3.5.0
, scrolling as above on an unfocused darktable window bauhaus widget adjusts the widget on first and successive scrolls, while not focusing the application window. Scrolling on an off iop changes its value on first and successive scrolls. This seems preferable behavior.