bauhaus.c: Tune delta sensitivity for trackpad in Quartz

[MStraeten]

Adjust trackpad/magic mouse sensitivity for Quartz according to former solution in gtk.c

fixes: #20698

@dtorop: any side effects to be expected?

[dtorop]

@MStraeten: Do we want to do this in _widget_scroll() rather than in _slider_add_step()? As the latter is called in a number of places besides scroll events, and scroll events presumably should also be damped for comboboxes.

The change could be:

modified   src/bauhaus/bauhaus.c
@@ -3102,6 +3102,11 @@ static void _widget_scroll(GtkEventControllerScroll *controller,
       dt_bauhaus_widget_t *w = (dt_bauhaus_widget_t *)widget;
       _request_focus(w);
 
+      #ifdef GDK_WINDOWING_QUARTZ
+      // Reduce raw continuous trackpad/magic mouse delta to match discrete step behavior
+      delta *= 0.02f;  // tune: lower = less sensitive
+      #endif
+
       if(w->type == DT_BAUHAUS_SLIDER)
       {
         const gboolean force = darktable.control->element == DT_ACTION_ELEMENT_FORCE

Thank you for flagging this. I don't have MacOS, so can't test from here. I was worried about that commit re-breaking MacOS scrolling, but had some fantasy that event controllers would have solved this problem. But looking at the code there is no special handling for MacOS.

[MStraeten]

the result is strange - it seems to be dependent on speed: on slider slow movements doesn't change anything, just fast movements.
other scroll elements are quite ok

I have to check other widgets without the fix …

[dtorop]

Yes, I think that the fix still isn't quite right. What I know from here (non-MacOS hardware):

• dt_gui_get_scroll_unit_deltas() has been the longstanding way to handle unit scrolling in darktable. It handles unit scroll GdkEvents (mouse wheel spinning up/down) of type GDK_SCROLL_UP/DOWN/LEFT/RIGHT. It also handles trackpad/touch scrolling, which produces a GDK_SCROLL_SMOOTH. It accumulates these smooth scroll events, which are generally < 1 unit, and returns a unit delta once they accumulate to >= 1. If the code is compiled for MacOS, it downscales smooth scroll events by DT_UI_SCROLL_SMOOTH_DELTA_SCALE before accumulating them.
• The new GTK EventController way to do this is via the GTK_EVENT_CONTROLLER_SCROLL_DISCRETE flag. In that code, gtk_event_controller_scroll_handle_event() does pretty much the same work as dt_gui_get_scroll_unit_deltas(). It does not downscale scroll events.
• To transition to GTK4, darktable needs to use GtkEventControllerScroll style scroll events instead of handling scroll-event. The problem is that we then lose the scroll event downscaling.
• My suggestion was wrong to, in _widget_scroll(), divide the deltas returned by GtkEventControllerScroll by 50. In the case of scroll wheel events, we want these to be +/-1, not +/-0.02. Even in the case of smooth scroll events, the code is expecting an accumulated +/-1, not +/-0.02.
• Your solution of adding the modifier in _slider_add_step() probably does produce the right results in the case of smooth scroll events. But most likely will break some other cases (e.g. adjusting slider by up/down/left/right keypress). As _slider_add_step() is too far away from the bauhaus event handling code, it currently doesn't know the difference between the event sources.
• This isn't the only place in darktable where we're starting to use GtkEventControllerScroll, so we need a general fix. Since c8017a9, scrolling in histogram/waveform to change exposure uses GtkEventControllerScroll and that is presumably also broken on MacOS.

It may make sense to write a dt_gui_get_scroll_event_discrete() helper function which handles this. In the case of non-MacOS, it would transparently return the deltas from the scroll event. In the case of MacOS and smooth scroll events, it would accumulate the scroll events and return a unit step every time they reached 50.

Even here, it seems like there are wrinkles:

1. It could accumulate the deltas returned from the scroll event, but then we have two layers of accumulators, one in gtk_event_controller_scroll_handle_event() and one in the darktable helper function. This seems a bit weird. If the user rapidly scrolls up/down, will the double layer of accumulators miss the motion?
2. It could bypass the deltas returned by the scroll event and make its own accumulator from the GdkEvent. But the scroll callback is only called when the scrolls accumulate unit deltas, so we would still miss most of the GDK scroll events.
3. It could catch the new scroll-begin event and then somehow start accumulating GdkEvents? I'm not sure how this works.

Maybe it's best just to try option 1 and see if it works.

I can try to code this as a proof of concept, but can't test!

[dtorop]

Thinking about this a bit more:

Perhaps the nicest GTK4-friendly way to do this is, in the case of MacOS, to catch the scroll-begin and scroll-end events and in that case set a scaling factor for the deltas returned by scroll. The scroll handlers would still need a helper to accumulate the < 1 deltas (as well as do the scaling).

But can think/research more (much later today), and write this if it seems wise.

But curious for thoughts there. And also I'm still puzzled by MacOS smooth scroll is so different.

[dtorop]

Even fancier idea: dt_gui_connect_scroll() could, in case of MacOS, handle a proxy event handler which attenuates trackpad events. This could be transparent to other systems. Worth a try!

[MStraeten]

• Your solution of adding the modifier in _slider_add_step() probably does produce the right results in the case of smooth scroll events. But most likely will break some other cases (e.g. adjusting slider by up/down/left/right keypress). As _slider_add_step() is too far away from the bauhaus event handling code, it currently doesn't know the difference between the event sources.

using keys isn't an issue in this case also not using modifier+scroll in case of masks.

• This isn't the only place in darktable where we're starting to use GtkEventControllerScroll, so we need a general fix. Since c8017a9, scrolling in histogram/waveform to change exposure uses GtkEventControllerScroll and that is presumably also broken on MacOS.

oh yes, tried this, and it's like a fan for color harmonies ;)

I can try to code this as a proof of concept, but can't test!

feel free to code, i'll test ;)

[dtorop]

oh yes, tried this, and it's like a fan for color harmonies ;)

Alas!

feel free to code, i'll test ;)

There's code in #20710 which should fix this. Very curious how it works from there.