This duplicates a lot of code from FolderViewContextManagerItem, so you might think about putting this into a separate function taking the viewport as a parameter (in app, but see lib/*utils* for some examples).

Why is there so much code? Is there no support in Qt to detect that kind of gestures, e.g. any of QGesture's children like QTapAndHoldGesture, QPanGesture etc.? Would it make sense to subclass QGestureRecognizer if not?

Some parts could use more comments to make the purpose of some of the code easier to understand.

I know, I have the same or equal code on more than one position, I was thinking about moving the code in a own class. But I'm afraid I don't know enough in Qt and C++ to make it. I will try it, but please bear with me, if I make a complete mess out of this.

Unfortunately, Qt does not differentiate well between individuals gesture typs. For example, if you make a two finger pan gesture, to scroll the viewport, you will get a QGesture Event with a pan gesture, zoom gesture, rotation gesture and so on in the same time. So this is the reason for the many code in the TouchBegin, TouchUpdate and TouchEnd Event handler, I need this to differentiate between the individuals gesture.
You have linked some example, but all have the same problem, you can not make a pure two finger pan gesture without zoom or rotate effekts.
I will try to make my own QGesture Class, but as I said above, I hope I don't make a mess.

The next behavior from Qt, which sometimes causes me problems, is that Qt synthesizing a mouseclick from a touch event. This is the reason for the check on "mouseEvent->source() == Qt::MouseEventNotSynthesized)", I need to suppress this. Without the check I will start a DragandDrop action.

Yes I have some magic numbers in the code, should I insert a comment to explain the number or make a const variable with a meaningful name or both?

I know it is a little bit crude, the aim was, to lower the sensitivity of the zoom. I wanted to use only every second gesture event to zoom the size of the thumbnail. Because the thumbnail size is an integer, I cannot modify the size in 0.5 steps.
Maybe I need to save the start size of the thumbnail in the zoom begin, and use this to calculate the next size, I need to test this.

Yes I have some magic numbers in the code, should I insert a comment to explain the number or make a const variable with a meaningful name or both?

I think a meaningful constant is enough in most places where an explanation is needed, especially if the value is used more than once. A comment is good to have a clue what's the sense of the following code. I would not comment on a single constant in the normal code (if needed maybe at the constant definition).

I am not sure, that I agree with you in this matter, because I move both fingers if I want to rotate the image.

Hmm, in that case, it will be important to improve rotation detection, because I repeatedly rotated images by accident while pinch-zooming. Coupled with the lack of animation, it was very jarring and unexpected.

I'm seeing a weird effect when double-tapping to enter Full screen mode from View mode:

I can not reproduce this at the moment, perhaps you can post your linux distribution, KDE and Qt version, so I can install it on a USB stick and look at this.

Some of these gesture recognizers would be very helpful in other KDE programs as well (Okular is what I have in mind). Can they be moved to some central place where both Gwenview and Okular can use them?

Thanks @steffenh. I went back and re-tested everything and it all works *flawlessly* for me. Very impressive work. I really hope we can get it in for KDE Applications 19.04. I'll start on the code review:

From a high level perspective, I share @rkflx's concern with the amount of duplicate code. ThumbnailView::viewportEvent() is almost entirely duplicate code from DocumentView::event(), for example. Can we refactor this into re-usable functions in touch or touch_helper or something?

Also, can you help me understand why we need to implement our own finger gesture recognizers in all the files you've added under lib/touch? Can we not use Qt's built-in touch handling functionality for some reason?

From a high level perspective, I share @rkflx's concern with the amount of duplicate code. ThumbnailView::viewportEvent() is almost entirely duplicate code from DocumentView::event(), for example. Can we refactor this into re-usable functions in touch or touch_helper or something?

I will have a look at this, perhaps I can move same code around.

Also, can you help me understand why we need to implement our own finger gesture recognizers in all the files you've added under lib/touch? Can we not use Qt's built-in touch handling functionality for some reason?

QT gestures do not have the functionality we need:

Qt::SwipeGesture is two or more fingers, but we need one or two fingers

Qt::PanGesture is two fingers, but we need one or two fingers

Qt did not have double tap gesture (for toggle full screen)

Qt did not have two finger tap gesture (for context menu)

Qt did not have tap hold and moving gesture (for drag and drop action)

Thanks, that makes sense. However, it might also make sense to add generic support for all of this into Qt itself, or at least into a KDE Framework (KWidgetsAddons maybe?). There are lots of other QWidgets-based KDE apps that could benefit from this stuff too! Dolphin and Okular immediately come to mind.

Regardless, we need to remove the extreme code duplication here somehow, even if it's just using re-usable functions in Gwenview itself. Of course once that's done, it might not be too much work to get that code into a KDE Framework... :)

I agree. @steffenh, any chance you'd be interested in that? Then, we could use these very nice gestures in Okular and Dolphin too. Since you've already done the hard work of de-duplicating the code and putting it into helper files, hopefully that shouldn't be too much effort, right?

I agree. @steffenh, any chance you'd be interested in that? Then, we could use these very nice gestures in Okular and Dolphin too. Since you've already done the hard work of de-duplicating the code and putting it into helper files, hopefully that shouldn't be too much effort, right?

I was thinking over this in the last days, but I'm not sure my coding is up to the task. Perhaps after I have finished this patch I can try it.
But with this idea in the background, I'm beginning to complete remove the event and gestureEvent function in dokumentview.cpp and thumbnailview.cpp, and use the Signal / Slot mechanics from Qt .

I agree. @steffenh, any chance you'd be interested in that? Then, we could use these very nice gestures in Okular and Dolphin too. Since you've already done the hard work of de-duplicating the code and putting it into helper files, hopefully that shouldn't be too much effort, right?

I was thinking over this in the last days, but I'm not sure my coding is up to the task. Perhaps after I have finished this patch I can try it.
But with this idea in the background, I'm beginning to complete remove the event and gestureEvent function in dokumentview.cpp and thumbnailview.cpp, and use the Signal / Slot mechanics from Qt .

OK, so are you still working on some changes for this patch then? I ask because if so, I'll wait until you're done to land it. :)