first scroll on inactive bauhaus widget doesn't register

[dtorop]

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

1. Start darktable, choose an image, and go to darkroom view.
2. Expand an iop with bauhaus widgets that is off, e.g. "crop and rotate" (in the case of an image without history).
3. Move pointer over a bauhaus widget (e.g. "angle" in crop and rotate) and scroll mouse wheel once.
4. The widget value doesn't change value on the first scroll. The iop remains off.
5. Scroll over the widget again.
6. The iop turns on, and the widget changes value.

Note that this behavior occurs with both slider and combobox widgets.

Alternate reproduction:

1. Go to darkroom view.
2. Expand an iop with bauhaus widgets, e.g. "crop and rotate".
3. Click on any other (non-darktable) application's window, so that darktable is not focused (but leave the darktable window visible).
4. Move mouse back over the darktable iop, and scroll once over a widget (e.g. "angle" in crop and rotate).
5. There is no effect on the widget. The darktable window remains unfocused.
6. Scroll one more time over the widget.
7. The widget now changes its value. If the iop was off, the iop turns on. The darktable window remains "unfocused".

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

• darktable version : 3.5.0+2422~g485b8375b
• OS : Linux - kernel 5.10.38
• Linux - Distro : Debian/testing
• Memory : 32GB
• Graphics card : Nvidia Quadro P4000 Mobile
• Graphics driver : Nvidia 460.80
• OpenCL installed : yes
• OpenCL activated : yes
• Xorg : 7.7
• Desktop : Gnome
• GTK+ : 3.24.24
• gcc : clang 11.0.1
• CMAKE_BUILD_TYPE : Release

Additional context Please provide any additional information you think may be useful, for example:

• Is the issue still present using an empty/new config-dir (e.g. start darktable with --configdir "/tmp")? yes
• I see this in Gnome whether in "Click to Focus", "Focus on Hover", or "Secondary-Click" mode
• In release-3.4.1 and release-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.
• I'm using a mouse with a wheel with "detents" to generate a single scroll event per scroll. Other mice (and trackpads with scrolling gestures) may vary.

[dtorop]

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.

[dtorop]

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

[aurelienpierre]

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.

[dtorop]

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"?