Review Request 125847: Change pages in presentation mode by swiping on touch screen

[Albert Astals Cid]

> On Feb. 17, 2017, 7:43 p.m., Martin Tobias Holmedahl Sandsmark wrote:
> > it looks good to me, but I don't have a touch screen to test on unfortunately
> 
> Albert Astals Cid wrote:
>     I recently got a laptop with a touchscreen, it's not my main devel machine but i'll try to find time to setup stuff there and give it a try.
> 
> Albert Astals Cid wrote:
>     tested, don't think it's a good idea to add a feature and remove others, for example without your patch i can use the drawing stuff to draw on screen, with it i can not.
> 
> Oliver Sander wrote:
>     I am aware of this problem, but I don't know what the solution is.  Here are a few thoughts:
>     
>     The current behavior has to change at least a little bit if you want gesture support.  For example, currently, for each single-finger touch, Qt synthesizes a MouseEvent, which makes the presentation proceed to the next page.  This will always interfere with swipe gestures, because when you put three fingers onto the screen for a swipe, usually one finger touches the screen before the others, and you are off to the next page before Qt could notice that you are planning to do a three finger swipe.  Therefore this single-finger-synthesizes-a-mouse-click has to be switched off.
>     
>     Same with the drawing stuff you mention.  I haven't tried it, but I am pretty sure that if you implement single-finger drawing together with page-changing-by-swiping, then you will always get a small line drawing every time you try to swipe.  For the same reason: it is very difficult to put three fingers onto the screen at the same time.
>     
>     I don't really know how this would be solved ideally.  Disabling swipe gestures when drawing mode is disabled?  Doesn't sound good. I am afraid there is not one single behavior that can make everybody happy.  For you, drawing with the finger is the natural thing to do (and I agree!).  However, my machine comes with a stylus, which creates TabletEvents.  I would never want to draw with my finger anyways, because I have that stylus.  Therefore, the lost ability to draw with my fingers hasn't bothered me.  Do we need to add configuration options for the touch/gesture behavior?  What would those be?
>     
>     I'd be happy to change my patch, but I don't know what direction to take.  Suggestions would be helpful.

As far as I can see, the easiest solution is move the slotNextPage/slotPrevPage from mousePressEvent to mouseReleaseEvent. This shouldn't be a problem for the typical "click to go to next page", but allows you to put the three fingers on the screen and to a swipe before the next page code is triggered.

Do I make sense?


- Albert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125847/#review102537
-----------------------------------------------------------


On Feb. 17, 2017, 8:06 p.m., Oliver Sander wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125847/
> -----------------------------------------------------------
> 
> (Updated Feb. 17, 2017, 8:06 p.m.)
> 
> 
> Review request for Okular.
> 
> 
> Bugs: 354012
>     http://bugs.kde.org/show_bug.cgi?id=354012
> 
> 
> Repository: okular
> 
> 
> Description
> -------
> 
> This patch adds support for swipe gestures to the presentation mode of okular. Swiping right-to-left goes to the previous page, swiping left-to-right goes to the next page.
> 
> Notes:
> 
> 1) The swipe gesture used here is a three-finger swipe, which is what the Qt QSwipeGesture class implements.  I am not convinced that using three fingers is optimal here, but it is the easiest to implement.  Other swiping gestures are possible, but you would need to implement a custom QGestureRecognizer.  That would make the patch larger and more error-prone.
> 
> 2) Swiping from left to right(!) makes the presentation mode go to the next(!) slide.  This is the opposite direction compared to what you do when you flip pages in a physical book, so it may feel strange.  It is, however, the direction used in the qt5 gesture example at http://doc.qt.io/qt-5/gestures-overview.html Let me know if you want the directions reversed.
> 
> 3) By default, Qt5 synthesizes a mouse event for each unhandled touch event.  In particular, a left mouse click is synthesized for each finger tap to the screen (which usually makes the presentation go to the next slide). This mechanism gets in the way of gesture recognition, because the first finger touch of your swipe gesture will already create a mouse-click and make your presentation go to the next page, irrespective of the swipe direction.
> 
> The patch solves this problem but switching off mouse event synthesis in presentation mode.  That's the line
> 
>     QCoreApplication::setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents,false);
> 
> in the constructor of PresentationWidget.  This has short-term side effects.  For example, with this, you cannot finger-touch on a movie to start it anymore.  The fix for this would be to implement proper handling of QTouchEvents, which should not be difficult.
> 
> An alternative would be to leave mouse event synthesis turned on, but implement a dummy touch event handler.  This will need only a few lines of code, but it will not avoid the side effects mentioned above.
> 
> 4) This patch applies to the 'frameworks' branch.  I failed at backporting it to 'master'.  There, the event loop would never receive any touchscreen events at all.  This may be a Qt bug, but it may as well be my lack of experience.
> 
> 
> Diffs
> -----
> 
>   ui/presentationwidget.h 69574d22 
>   ui/presentationwidget.cpp 526c235e 
> 
> Diff: https://git.reviewboard.kde.org/r/125847/diff/
> 
> 
> Testing
> -------
> 
> Tested on a Thinkpad Yoga running Debian testing.
> 
> 
> Thanks,
> 
> Oliver Sander
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20170306/c6b3985a/attachment-0001.html>