Fix smooth scrolling in compact view using mouse wheel.

[yagi-tan]

In Debian Trixie with X11, PCManFM 1.4.0 is not able to scroll in compact view using mouse wheel. Apparently, with both GDK_SCROLL_MASK and GDK_SMOOTH_SCROLL_MASK set, only smooth scroll events are generated, and gdk_event_get_scroll_deltas() only sets Y delta value while X delta is set to 0 for such event. I've changed that to consider Y delta when X delta is small enough so that it won't change previous behaviour while fixing the problem.

For testing, I only tested this on mouse as I don't have touchpad so I don't know what's valid deltas' value range coming from the latter. There're 2 variations for the mouse wheel (X delta is always 0):

1. Normal usage of rolling the wheel. The delta value is either -1 or 1.
2. With "libinput Scroll Method Enabled" is set to "0, 0, 1" so that user can scroll by dragging mouse while holding wheel (middle) button down. For left-right drag, delta value is either -2 or 2. For up-down drag, it's either -1 or 1.

I don't know the best scroll delta value (previously it's fixed to 33.3, changed to match what GDK_SCROLL_MASK use since it's too small for my usage), with those variations might make scrolling 'jumpy' too much. I'm tempted to clamp the delta value to [-1,1], though wanting to confirm touchpad delta value first (seems to be fractional like 0.4).

[ib]

For left-right drag, delta value is either -2 or 2.

delta_y?

[ib]

I have a few more questions because I only have smooth scrolling with the touchpad, not with the mouse.

Do you have smooth scrolling with the mouse in the other views? If so, is smooth scrolling in compact view with your patch just as fast as in the other views?

With my touchpad, I need a factor of about 33.3 to achieve roughly the same speed as in the other views where smooth scrolling is handled by GtkScrolledWindow itself. I'm wondering if the mouse's +/- 1 is simply informative or if it's actually a (configurable?) value.

[yagi-tan]

For left-right drag, delta value is either -2 or 2.

delta_y?

Yes, even for left-right drag, the value is for delta_y.

Do you have smooth scrolling with the mouse in the other views? If so, is smooth scrolling in compact view with your patch just as fast as in the other views?

If just as fast means how much distance in pixels per wheel roll/drag, then:

• For wheel roll, exactly the same for all views.
• For wheel drag, because it's too sensitive/fast (small mouse movement = large distance) for any view, I can't tell exactly how much. But since it's the same for all views, I assume it's due to my computer/VM setup.

With my touchpad, I need a factor of about 33.3 to achieve roughly the same speed as in the other views where smooth scrolling is handled by GtkScrolledWindow itself.

Oh, so at your side there's distance difference between views? Just in case, if we put this at line 2821 (after new adjustment value):

printf("scroll delta[x:%.3f,y:%.3f,=:%.3f] value:%.3f\n", delta_x, delta_y, delta, value);

mine have this (dragging down from far-left, then drag right, delta[0,0,0] is when starting movement):

scroll delta[x:0.000,y:0.000,=:0.000] value:0.000
scroll delta[x:0.000,y:1.000,=:62.828] value:62.828
scroll delta[x:0.000,y:1.000,=:62.828] value:125.656
scroll delta[x:0.000,y:1.000,=:62.828] value:188.484
scroll delta[x:0.000,y:1.000,=:62.828] value:251.312
scroll delta[x:0.000,y:1.000,=:62.828] value:314.140
scroll delta[x:0.000,y:1.000,=:62.828] value:376.968
scroll delta[x:0.000,y:1.000,=:62.828] value:439.796
scroll delta[x:0.000,y:1.000,=:62.828] value:502.624
scroll delta[x:0.000,y:1.000,=:62.828] value:565.452
scroll delta[x:0.000,y:1.000,=:62.828] value:628.280
scroll delta[x:0.000,y:1.000,=:62.828] value:691.107
scroll delta[x:0.000,y:0.000,=:0.000] value:691.107
scroll delta[x:0.000,y:-2.000,=:-125.656] value:565.452
scroll delta[x:0.000,y:-2.000,=:-125.656] value:439.796
scroll delta[x:0.000,y:-2.000,=:-125.656] value:314.140
scroll delta[x:0.000,y:-2.000,=:-125.656] value:188.484
scroll delta[x:0.000,y:-2.000,=:-125.656] value:62.828
scroll delta[x:0.000,y:-2.000,=:-125.656] value:0.000

I'm wondering if the mouse's +/- 1 is simply informative or if it's actually a (configurable?) value.

I've used imwheel to increase wheel scroll size on host, no effect to delta value in list view, but the speed (distance) itself increased for all views. I don't know how to externally set that delta (simply got from gdk_event_get_scroll_deltas()); should we just add option in preference to set the factor/sensitivity?

[ib]

Thanks for the detailed and helpful reply. Taking all the information into account, and because your original patch does not allow horizontal left scrolling (delta_x < 0), I have modified it slightly. Once you have tested it and are happy with it, I will apply it.

[yagi-tan]

because your original patch does not allow horizontal left scrolling (delta_x < 0), I have modified it slightly.

What the heck, even though I keep talking about delta_y can be +/- 1/2, I totally missed to consider negative delta_x.

OK, tested on my side to be working fine for both wheel rolling and dragging. Though 2 questions:

1. You said your side needs 33.3 factor, but current factor will be clamped to +/-1, is this fine?
2. My intention of abs(delta_x) >= 0.001 is so that if touchpad up-down movement is not clean (kinda diagonal so delta_x have some value) it will still use delta_y as major movement is on that axis, else user will need to have perfect up-down or only use left-right. If your side that use touchpad don't have that problem or is fine with the latter, then never mind.

[yagi-tan]

Instead of #37, it's lxde/pcmanfm#37. Fixed with commit below.

[ib]

33.3 factor

I previously increased delta_x, but now I'm decreasing delta (touchpad deltas are < 1), which also seems more plausible. The new scrolling speed is okay for me, and I got rid of the hard-coded factor.

if touchpad up-down movement is not clean (kinda diagonal so delta_x have some value)

I didn't notice any of that during my tests — but indeed, you can force diagonal movement. So, let's give delta_y the preference. Fixed with commit below.

Instead of #37, it's lxde/pcmanfm#37. Fixed with commit below.

Thanks for noticing!

[yagi-tan]

I didn't notice any of that during my tests — but indeed, you can force diagonal movement. So, let's give delta_y the preference. Fixed with commit below.

Just in case there's misunderstanding, I'm not talking/claiming user mostly use up-down movement compared to left-right. It's in case when user uses up-down movement and the movement is not clean, previous commit would keep using delta_x that probably has small value, which results in small scrolling speed even though delta_y is large (user makes movement in that axis/direction after all). Latest commit has delta_y != 0.0, prioritising up-down movement, though this time unclean left-right will be affected instead. Sorry for not being clear.

I can make it to use largest delta so that no priority is given to any axis. As long it detects scrolling/dragging, it'll move. Is that acceptable?

//cannot use MAX(ABS(x), ABS(y)) since result sign/direction will be missing
value = (ABS(delta_x) >= ABS(delta_y)) ? delta_x : delta_y;
delta *= CLAMP(value, -1, 1);

[ib]

Just in case there's misunderstanding, I'm not talking/claiming user mostly use up-down movement compared to left-right.

No, I think I understand. During my tests, I never experienced diagonal scroll deltas. You have to scroll at an extremely steep angle to achieve this, and as you said, the movement is in the y-axis/y-direction after all. So, it seems reasonable to prefer delta_y.

It's in case when user uses up-down movement and the movement is not clean

It seems that the touchpad smooths the movement unless you move at an extremely steep angle.

Below a cosmetic change.

[yagi-tan]

It seems that the touchpad smooths the movement unless you move at an extremely steep angle.

Oh, I see, didn't know that.

OK then, at this point LGTM.

[ib]

Thank you very much for your contribution.