Adding support to single tap gestures to QRawWebView.
Created attachment 160075 [details] patch
Comment on attachment 160075 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=160075&action=review > Source/WebKit2/ChangeLog:8 > + The new class QRawWebViewGestureEvent contains the event information. The method How about QRawWebGestureEvent? > Source/WebKit2/UIProcess/API/qt/raw/qrawwebview_p.h:64 > + Extra line?
Comment on attachment 160075 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=160075&action=review Let me see if I get this right: Conceptually you don't want the raw web view to do any event interpretation, right? All send*Event functions are supposed to send the event straight to the web process and any gesture interpretation, etc. should be done in the layer above the raw web view? > Source/WebKit2/UIProcess/API/qt/raw/qrawwebview_p.h:52 > +class QRawWebViewGestureEvent { It sounds like that this could be a sub-class of QInputEvent and all the event types the QRawWebView needs could be defined after QEvent::User perhaps.
(In reply to comment #3) > (From update of attachment 160075 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=160075&action=review > > Let me see if I get this right: Conceptually you don't want the raw web view to do any event interpretation, right? All send*Event functions are supposed to send the event straight to the web process and any gesture interpretation, etc. should be done in the layer above the raw b view? Yes, that is the idea, all gesture interpretation should be done in the layer above. The next patches will handle the scroll position and the mapping of coordinates to and from screen. Those patches are in the queue. > > > Source/WebKit2/UIProcess/API/qt/raw/qrawwebview_p.h:52 > > +class QRawWebViewGestureEvent { > > It sounds like that this could be a sub-class of QInputEvent and all the event types the QRawWebView needs could be defined after QEvent::User perhaps. It could indeed. As it is just about converting it to an WebKit event type inside of raw web view I considered that it was not needed. I am trying to keep it as simple as possible, that is why I am not inheriting anything, but I may change it if you think it would be better.
(In reply to comment #2) > (From update of attachment 160075 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=160075&action=review > > > Source/WebKit2/ChangeLog:8 > > + The new class QRawWebViewGestureEvent contains the event information. The method > > How about QRawWebGestureEvent? I like it.
Comment on attachment 160075 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=160075&action=review >>> Source/WebKit2/UIProcess/API/qt/raw/qrawwebview_p.h:52 >>> +class QRawWebViewGestureEvent { >> >> It sounds like that this could be a sub-class of QInputEvent and all the event types the QRawWebView needs could be defined after QEvent::User perhaps. > > It could indeed. As it is just about converting it to an WebKit event type inside of raw web view I considered that it was not needed. I am trying to keep it as simple as possible, that is why I am not inheriting anything, but I may change it if you think it would be better. I think it would be cleaner, if we at some point want to make it a semi-public API and also in the light of potential future events. > Source/WebKit2/UIProcess/API/qt/raw/qrawwebview_p.h:63 > + QPointF delta; I think a comment would help here, to make it clearer that the delta has no meaning here currently, unless we add the scroll gesture types. Or perhaps it should be left out for now?
Comment on attachment 160075 [details] patch Cleared review? from attachment 160075 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).