Povilas Kanapickas (40743c90) at 06 Aug 17:13
Povilas Kanapickas (86799f87) at 06 Aug 16:25
Povilas Kanapickas (f27beed9) at 19 Jul 12:35
app: Implement zooming via touchpad gestures on GimpContainerTreeView
... and 54 more commits
Resolving thread as a comment below answers the questions - in short - I think the MR should be merged as is.
Povilas Kanapickas (3d0940cc) at 01 Jul 19:59
Povilas Kanapickas (24f81fc4) at 01 Jul 19:59
app: Implement zooming via touchpad gestures on GimpContainerTreeView
... and 328 more commits
Povilas Kanapickas (3d0940cc) at 01 Jul 19:59
widgets: Fix out of bounds zoom in gradient editor
... and 331 more commits
@Jehan I wrote a long comment on !599 (comment 1491488) which also applies to this MR. I think it makes sense to merge it as is.
Are you saying that touchscreens don't use
libinput
? These are input devices too.
They do, but touchpads and touchscreens are fundamentally different as far as input events are concerned. Touchpad gestures are always associated to the pointer, so it's always clear which exact window (and widget) the events should be reported to. Touchscreens report each touch as a separate touch point, each of which may affect a separate GUI application. This makes touch events much harder to handle, because Gtk and other widget toolkits must interpret touches itself and decide when they mean a pinch gesture, or swipe gesture, or just a drag and so on. Apparently in this case it's exactly what doesn't work and we can't do anything.
@Jehan Apologies for a long delay, I finally fixed touchscreen on my test laptop (turned out to be driver issue in a test kernel
I have tested how both !599 (merged) and !615 (merged) PRs work. The behavior is indeed pretty unusable on a touchscreen, I agree. At However, I think we can't do much about it, because the touchscreen gestures are recognized by Gtk itself, we are only interpreting data such as "there was a pinch gesture, distance between fingers has been reduced by 25%". The touchpad however works fine as in my initial testing.
The main problem it seems that the recognizer starts the gesture recognition, but then drops it for some reason after couple hundreds of milliseconds or so.
To answer your other questions left in comments:
If so, I'm wondering if the physical size of the screen matters (for whatever returns
gtk_gesture_zoom_get_scale_delta()
)
gtk_gesture_zoom_get_scale_delta
returns relative scale, so we don't care about the
My second question is that it looks like the code already uses a pixel size. If so, shouldn't our scroll/gesture zooming just work continuously as well?
This would make integration with changing the preview size via mouse more complex, because we would need to indicate that custom preview size is active and so on. It's much simplier to have fixed preview sizes. If the tree views had a separate slider to control preview sizes then I think it would make sense to remove this restriction and offer continuous zooming for all input methods.
But it would be very useful when it is viewed as grid too.
Agreed. It probably wouldn't be too hard to implement.
TL&DR; I think it makes sense to merge the MR as is and we can look into improvements later.
I see that sometimes pinch gesture is not recognized and then the gradient is violently panned to one of the sides. If it turns out that this is the problem then we can't do anything - it's the libinput pinch gesture recognizer that needs improvements.
It's weird that you're seeing the problem on a touchscreen, I will look into it too.
when zooming out with the scroll, it is actually possible to zoom further out than the actual gradient range.
Indeed, I fixed this now in the "widgets: Fix out of bounds zoom in gradient editor" commit. Thanks for precise reproduction steps.
Fixed, sorry for wasting your time for such trivial stuff.
Fixed.
Povilas Kanapickas (0a582dc2) at 06 Apr 21:18
widgets: Fix out of bounds zoom in gradient editor
... and 11 more commits
I was testing on a touchpad, will test everything using a touchscreen.
Fixed now.
The constant values are actually pixel values, aren't they?
Correct.
why not just have continuous view size as well?
Problem is how to map this back to menu items because menus are implemented as radio items. We do this e.g. in dockable_actions_update()
maybe elsewhere.
The code was starting to be too complex so I've decided to adapt to the current way of doing things. I think your idea makes sense long term as a separate improvement.
Another thing is when I tested just now, it was very hard to control the size
Interesting, I haven't reproduced this. However, there was an issue that due to signal order GtkGestureZoom didn't initialize its state properly and the very first zoom in a application run would quickly cycle to the smallest preview. Other gestures afterwards would work fine.
This is now fixed, could you please re-test, maybe it's the same issue? Otherwise I'll need to dig deeper.
Just saw on your other comment, you're testing on a touchscreen. I was testing on a touchpad, will look into how touchscreens behave.
Fixed. Seems like only some of the platforms need the include (mine didn't) :-)
Fixed.
Povilas Kanapickas (875d6242) at 06 Apr 20:48
app: Implement zooming via touchpad gestures on GimpContainerTreeView
... and 1 more commit