> 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 > >
