aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickwindow.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Clean up QSGRhiSupport wrt static functionsLaszlo Agocs2021-03-201-1/+1
| | | | | | | | | | | Make static everything that can be static. At the same time, make configure() non-static. Does not change behavior in any way, but this is the more logical approach. Also more future proof. Change-Id: I601d59a0547106802f330a7551a97186cde481e0 Reviewed-by: Christian Strømme <christian.stromme@qt.io> (cherry picked from commit fb8ba3f7250f837dd29600d30108ba6f4470a727) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add assertions and checks on QQWinPriv::deliveryAgentPrivate()Shawn Rutledge2021-03-191-23/+55
| | | | | | | | | | | | | | | | | | | The static analyzer found the case where it could actually be null during delivery of a WindowDeactivate event. In other cases, we assert rather than testing, until we know that it can actually be null. It shouldn't often be null because it's created in QQuickWindowPrivate::init() and destroyed in the destructor; however we've already seen races when event delivery continues while the window is being destroyed. If more such cases materialize, we can replace asserts with if()'s or check the new inDestructor flag. Fixes static analyzer warning 16738055c4c458145b59ad9b6bb643b5 Change-Id: I408e9a7d71a77fd29c2af91e59caf9ede6585af9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> (cherry picked from commit fb69e86bee67a228ca581a8bfe3384da14398f76) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* QQuickWindow: don't leak old screenChanged connectionsAndreas Hartmetz2021-03-121-4/+3
| | | | | | | | | | | | | | | | | | Connections could accumulate. Because the newest one was invoked last due to how signal-slot invocations are ordered, rendering was correct, but the stale connections caused unnecessary updates (and wasted a small amount of memory). This comes from a misunderstanding I had at the time about how QMetaObject::Connection works. Destroying or overwriting one does not affect the actual connection. While at it, also modernize the connect(). Change-Id: Idde81bdbff8947ed517bf2740d623a395c0acb74 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 9f8292d48913c5bc50377749c2b3e030cf16d703) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix click-to-focus in items within subscenes; improve loggingShawn Rutledge2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the ability to focus an item by clicking (such as a TextInput) when it's part of a subscene mapped to a 3D object in Qt Quick 3D, even if there are multiple subscenes with focusable items. QQuickDeliveryAgentPrivate::setFocusInScope(subsceneRoot, textInput) for example did not succeed; for one thing, this check fails: // Does this change the active focus? if (item == rootItem || scopePrivate->activeFocus) { because in a 3D scene, so far the viewport has focus by default, so the given scope (subscene root) does not have active focus. Each window ultimately has one actively focused item, so we need to delegate to the delivery agent belonging to the window's root item, to set its active focus. It's not even clear whether it's really a good idea for each subscene delivery agent to have its own QQuickDeliveryAgentPrivate::activeFocusItem. It might give us flexibility: perhaps each subscene root item should be a focus scope, and each delivery agent should decide which item would be hypothetically focused if the whole subscene got focus. But for now, it seems enough to set the activeFocusItem on the root item of the whole scene. Another problem was that when QQuickItem::forceActiveFocus() goes up the parent hierarchy, it didn't find a focus scope. So when you clicked on a TextInput that already had its focus property set to true, 1) QQuickItem::setFocus() does nothing because d->focus is already set 2) QQuickItem::forceActiveFocus() did not find a parent focus scope Therefore neither of them changed anything, and it wouldn't get active focus. Setting the ItemIsFocusScope flag on each subscene root item fixes (2), and that seems to be enough for now. Another problem was that QQuickWindow::event() was calling QQuickDeliveryAgent::grabberAgent() even when delivering an event that is NOT a press event, in spite of the comment "When delivering _update_ and _release_ events to existing grabbers, use the subscene delivery agent, if any." A hover event often results in a HoverHandler getting a passive grab, but that passive grab is not a reason to deliver a subsequent press event to the same subscene. When the mouse moves, we need to start over with picking in the 3D scene. When the 60fps frame-synchronous hover event occurs, we need to start over with picking, in case 3D objects are being animated under the cursor. When a press occurs, we need to start over with picking in case the press occurs in a different location from the last hover (even though that's unlikely with a mouse, it happens easily with a touchscreen). Another problem was that QQuickItemPrivate::deliveryAgent() was not finding the subscene DA during delivery of key events. A child item's extra is often not allocated, but we still need to keep looking at the parents. The optimization from 68c103225f4e8bd6c1b18ef547108fd60f398c0f was also wrong: after an Item's default initialization, we always need to do the search for the subcene DA. Only if we are sure that the item is NOT in a subscene (as in all normal 2D scenes) we can avoid doing that search next time. Consolidate the number of lines of output in the qt.quick.focus logging category and show the activeFocusItem transition. As with most logging in Qt Quick, it's expected that you set QT_MESSAGE_PATTERN to include %{function} so that you can always see where each line comes from. Therefore the log output itself has only minimal context (as in "q focus item x in scope y") rather than repeating the function name. Change-Id: I1b2a989c02c58c966653f965c0de512aa641bb99 Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit 543598a6cc07d67e7651c9f65c058465ea6d8425) Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Move event delivery from QQWindow to QQuickDeliveryAgentShawn Rutledge2021-02-251-89/+170
| | | | | | | | | | | | | | | | | | | | | | QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit 68c103225f4e8bd6c1b18ef547108fd60f398c0f) Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Split event delivery code from qqwindow into qqdeliveryagent.cppShawn Rutledge2021-02-251-1967/+12
| | | | | | | | | | | | | | | Event delivery logic will live in util/qquickdeliveryagent.cpp now. The actual QQuickDeliveryAgent class will be created in a followup patch. This patch is roughly the same as this series in dev branch: 44eebdf5f5fe3bd7be16bc0ef05f8fc63e38a9f2 ca9c29348a9e149109d9d381cdd44538160b7898 902c68f3ceaae407306ca5a3fdcdcfa159009e78 79f0af6cd097f55eacb763574e173f134c9c0a32 0ccea574f8e4e9a3954ef3bb95909565957bacbe dbdee417dc073a0da3c99849a3f393fa3cb660e9 Change-Id: I25f234d0550768cb01cd80c38525291202b25d99 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Rename DBG_* logging categories in Qt QuickShawn Rutledge2021-02-151-45/+45
| | | | | | | | | | | | | | We prefer camelCase rather than SHOUTING for module constants. It fits well to have logging categories as constants that start with lc. That has become conventional in various modules, and we've been using that convention already for some time when defining new logging categories. Now we finish renaming the Qt Quick ones, ahead of a refactoring which will result in moving some of them around. Change-Id: I47003b9e525fe70d35dbd2450d03379b52d67c1d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit a8685fdb4d57c0ba36d80c395c2ae878595f04da) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* QQuickWindowIncubationController: Use QPointer to guard QSGRenderLoop referenceMike Achtelik2021-01-261-3/+3
| | | | | | | | | | | | | | In some cases, when the QGuiApplication is shutting down while there is an active QAnimationDriver and an incubating object, the QQuickWindowIncubationController will try to access an already destroyed QSGRenderLoop. So use a QPointer to guard the QSGRenderLoop access. Fixes: QTBUG-90489 Pick-to: 5.15 Pick-to: 6.0 Change-Id: I528e06ff22dfcad804593db6771d9163b21808f4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Ensure we cancel touchMouseSynthesis upon receiving touchCancelRichard Moe Gustavsen2021-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | As it stood, we wouldn't cancel touchMouseSynthesis after receiving a touch cancel event. The result would be that the first touch event sent to QQuickWindow thereafter would have touchMouseId set to value different from -1. This again would fool QQuickWindow into believing that the event belonged to a touch event it has synthesized before, and it would as such take a different/wrong path for delivery. This caused text selection to fail on iOS, since a press-and-hold on a line edit from QPA would cancel the touch event and show a magnifier glass. When the user later touched inside the line edit again to move the cursor, this new touch event would not be delivered to the text edit. Pick-to: 6.0 Fixes: QTBUG-90485 Change-Id: Iad640ae57317ea86ee68ca053654b0b30ade003a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Update hovered on disabled QQuickItemsAllan Sandfeld Jensen2021-01-181-1/+3
| | | | | | | | | | | | | | | | Changes handling of hovered so that the property is still updated on disabled items, so that other items can bind to it. This is in particular useful for tooltips. [ChangeLog][Behavior Changes] QQuickItem::hovered will now update even when the item is disabled. Fixes: QTBUG-30801 Pick-to: 6.0 Change-Id: Id17298f657d7631b0e5019138ba33a7d5f863475 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Enable importing OpenGL textures for the GL_TEXTURE_EXTERNAL_OES targetLaszlo Agocs2021-01-141-2/+3
| | | | | | | | | Introduce a QSGOpenGLTexture::fromNativeExternalOES() function which internally passes in the flag QRhiTexture::ExternalOES when creating the wrapping QRhiTexture. Change-Id: I919e2539304d3aeaa6bc8e5953d96adc810abb12 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Empty the ShaderEffect content cache on releaseResourcesLaszlo Agocs2020-11-241-0/+7
| | | | | | | | Just use a function because the private and impl classes for QQuickShaderEffect do not have their own headers. Change-Id: If5070aeb8c2b07b9b7e2cf3e16071ee2af2e368b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Purge renderpass refs from renderer when redirecting via QRhiRtLaszlo Agocs2020-11-241-7/+8
| | | | | | | | Pick-to: 6.0 Fixes: QTBUG-88761 Change-Id: Ia5df65a4a09a7554a7d0cca4533f766cb5abe97b Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove unnecessary static_castVolker Hilsheimer2020-11-241-1/+1
| | | | | | | | Since QEvent::clone() overrides return the type that they clone, calling it on an already downcast pointer doesn't require another downcast. Change-Id: Iba957f67a3b6c45cbd59e9978dc92ed5eb5db6c0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Don't deliver to non-grabbing pointerhandlers if a point is grabbedShawn Rutledge2020-11-231-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, on press when QQuickFlickable::filterPointerEvent() calls captureDelayedPress() and will return true, it also accepts the event to stop propagation. It becomes the grabber as a consequence of that. On a future move event, when the drag threshold is exceeded while the delayed press timer is still running, Flickable already has the grab (but it accepts the event again), and QQuickFlickablePrivate::drag() calls setKeepMouseGrab(true). In this case we still want to prevent any children's DragHandlers from seeing the event, because a DragHandler will also see that the drag threshold was exceeded and try to steal the grab. A DragHandler can steal the grab only if there was no press delay: then it sees the initial press because Flickable does NOT stop event propagation (does not accept the event), so it can take a passive grab and continue to wait for the drag threshold to be exceeded, regardless of what else happens. In case of multiple touchpoints, allPointsGrabbed() returns false if the Flickable has only grabbed one point; but we want to avoid delivering handlers in children just on the basis of that grabbed touchpoint being within their bounds, even though other points may be delivered to various handlers. This fixes tst_FlickableInterop::touchAndDragHandlerOnFlickable. The blacklisting of dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch was bogus (it's in the mousearea_interop test). Pick-to: 6.0 Task-number: QTBUG-86729 Change-Id: I9f0d42e97de4f4a3b4f7773800a8d59dc34a0553 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix tst_QQuickMouseArea::notPressedAfterStolenGrab againShawn Rutledge2020-11-191-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem() doesn't need to call item->mouseUngrabEvent() because all grab changes are notified via the connection from signal QPointingDevice::grabChanged to slot QQuickWindowPrivate::onGrabChanged(). But in this case, MouseArea only accepts the event, rather than taking the grab itself. Therefore at the time the grab is "stolen", there was not yet any grabber, because grabbing is done after delivery. But we still need to inform MouseArea that it's not getting the grab it expects to get, so that it can reset its pressed state. But we don't want it to be redundant (other tests are counting events, and we don't want repeated ungrabs to show up in those); so now we have to track whether the item on which we're about to call mouseUngrabEvent() has already gotten it. This illustrates another problem with the tradition of accepting events and being unclear about what it means. Grabbing is one thing, ending delivery is another. Amends a97759a336c597327cb82eebc9f45c793aec32c9 Task-number: QTBUG-55325 Task-number: QTBUG-86729 Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickItem::windowDeactivateEvent(); cancel grabs insteadShawn Rutledge2020-11-191-3/+37
| | | | | | | | | | | | | | | | | | | When a QQuickWindow is deactivated, visiting every item in the entire scene to tell them the news isn't very efficient, especially considering that the only item that overrode this virtual function has been QQMouseArea, throughout the lifetime of Qt 5. If it's important to cancel grabs of MouseAreas, then it's equally important to cancel grabs of MultiPointTouchArea, pointer handlers, etc. It should be OK to delete the virtual function since it was never documented, and marked \internal, so hopefully no users are depending on it. The existing tst_QQuickMouseArea::pressedCanceledOnWindowDeactivate() test continues to pass, which proves that the WindowDeactivate event still has the desired effect on MouseArea. Change-Id: I0109370aba14096fb7777a83cf1b6763ac58013f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QMutableSinglePointEvent's new default constructorVolker Hilsheimer2020-11-191-6/+6
| | | | | Change-Id: I3b2d1fbc4b62b501aa6ed748a692cb4bba261c5e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Stop ungrabbing due to FocusAboutToChangeShawn Rutledge2020-11-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to un-blacklist the test for QTBUG-60123. To that end: revert 7b2e2117162594a2d0234bb02408f5b5a446488b and its followup 6933b7e8e6dc279a8eb34e1f4c60bc109dfb7d26. There is no detailed bug report explaining exactly why those were done, just the comment on code review: "This fixes the desktop components' combo box on linux re-opening at random times", probably referring to a combobox popup window in Controls 1. But when using QWidget::createWindowContainer() in two different windows and clicking MouseAreas in each of them, it turns out that this change of focus is causing the mouse grab to be canceled. The grab should be naturally given up after mouse release; canceling prematurely doesn't make sense. The Qt 5 fix for this bug was e0c30279ec1fad88346ed3fb483bc3c672fdd01b which tracked the grab on a per-window basis. It would be difficult to do that again now (change QPointingDevicePrivate::setExclusiveGrabber() to store a separate grabber for each window in which a grab occurred? what could go wrong...) It seems odd to have the same QEventPoint grabbed in two different windows at the same time, but popups need event forwarding so maybe that was why (if a MouseArea triggers the popup, should it stay pressed and keep its grab? the subsequent mouse moves and the release need to be forwarded to the popup, so maybe something inside the popup needs a grab, simultaneously or not). Anyway we don't have actual popup windows in Controls 2 right now; and we know that event forwarding for popups needs work in QtGui so that it will be easier when we try again to have them in Qt Quick (QTBUG-68080). So perhaps the original workaround has outlived its usefulness: popup event forwarding needs to be handled at the lower layer, not in Qt Quick. Task-number: QTBUG-57253 Task-number: QTBUG-60123 Task-number: QTBUG-86729 Change-Id: I56dbc3bb94f66a7f26f79a97bcb2f2bbc0b7aa92 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Use QMutable*Event classes to copy and synthesize eventsVolker Hilsheimer2020-11-181-25/+23
| | | | | | | | | | QMutableTouch/SinglePointEvent can be publicly copy constructed from their non-mutable counterparts, make use of that. Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* When Flickable filters UngrabMouse, react as if it was ungrabbed itselfShawn Rutledge2020-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | Fixes tst_QQuickListView::touchCancel again. In this scenario, a TouchCancel is sent, but gets turned into an UngrabMouse for delivery to the MouseArea which is the current grabber. We try to avoid calling QQuickWindow::mouseGrabberItem() because it's too vague a question to ask (which mouse? or did you mean the synth-mouse during synthesis from a touch or tablet event?); and now it acts different anyway, because eventsInDelivery.top() is an UngrabMouse, which did not include a pointer to the QPointingDevice until now. So now we turn the UngrabMouse event into a QSinglePointEvent so that it's possible to get exclusiveGrabber() and check that the grabber is not the same Flickable. (Otherwise, the grabber that's getting ungrabbed is usually the child receiver item sent to childMouseEventFilter().) Task-number: QTBUG-86729 Task-number: QTBUG-74679 Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Avoid calling QQuickItemPrivate's methods if QQIP is incompleteFabian Kosmale2020-11-171-0/+10
| | | | | | | | | | | | | | | | In QQuickWindow, we instantiate QQuickPaletteProviderPrivateBase, which in turn instantiates its updateChildrenPalettes method, which then calls QQuickItemPrivate::inheritPalette. However, QQIP is an incomplete type at this point. Including qquickitemprivate_p.h would currently create a cyclic dependency, and breaking that dependency might mean outlining performance sensitive code. Thus we instead (ab)use the fact that updateChildrenPalettes is virtual, do nothing in the specialization for QQuickWindow and instead implement the method in the same way as an override in QQuickWindowPrivate. Task-number: QTBUG-88457 Change-Id: I49b357d7a67f1945a4d3c25e8cabd428d1454aa7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't synthesize mouse from touch for items that accept touchShawn Rutledge2020-11-171-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that has acceptTouchEvents() == true merely fails to accept one touch event, that does not mean a mouse event should be sent. Finish changing the default to false: handling touch events is opt-in, just like handling mouse events; most items don't. And if you opt in, then you MUST handle touch events, because you will NOT receive mouse events as a fall-back. Now that Flickable handles touch, filtering multi-touch events becomes relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch when Flickable grabs a stationary touchpoint at the same time as another touchpoint is pressed, preventing a child PinchArea from reacting. So there's a new rule: just as we start over with event delivery when a new point is pressed, QQuickFlickable::filterPointerEvent() should also not immediately grab when any point is newly pressed; it can afford to wait, because it's filtering, so it will be able to see if one point is dragged past the drag threshold later on. When a parent (such as Flickable) contains only mouse-handling items (such as MouseArea), the parent should filter the touch event if it is able (if acceptTouchEvents() returns true). Flickable is now able to. Filtering parents that are not able to filter touch events can still filter a synth-mouse event as before. But filtering both must be avoided: then we would have the problem that Flickable filters a touch move, sees that it's being dragged past the drag threshold, and sets d->stealMouse to true to indicate that it wants to steal the _next_ event; then it filters a synth-mouse move, and that's perceived as being the next event even though it's just a different view of the same event, so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we rely on the delay caused by waiting for the next event: the MouseArea is trying to drag an item and the Flickable wants to flick; both of them decide on the same event that the drag threshold is exceeded. But MouseArea calls setKeepMouseGrab() immediately, whereas Flickable doesn't try to steal the grab until the next event, and then it sees the keepMouseGrab flag has been set, so it doesn't do it. If Flickable could filter the same event twice (once as touch, once as synth-mouse), this logic doesn't work, so it's effectively "more grabby" than intended. So it works better to have it filter only the actual touch event, not the synth-mouse that comes after. When the child has pointer handlers, we need to visit them, and therefore we should let Flickable filter a touch event on the way. tst_FlickableInterop::touchDragFlickableBehindButton() depends on this. [ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must explicitly call setAcceptTouchEvents(true) to receive QTouchEvents, and then it must handle them: we no longer fall back to sending a QMouseEvent if the touch event is not accepted. If it has additionally called setFiltersChildMouseEvents(true), then it will filter touch events, not any synthetic mouse events that may be needed for some children. Task-number: QTBUG-87018 Fixes: QTBUG-88169 Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickWindow: better hover debug, and a reminderShawn Rutledge2020-11-131-1/+7
| | | | | | | | | | | | | In the qt.quick.hover.trace category, the position is the most important thing for now. The output for "q" is verbose and usually there's only one window anyway, so just put the title last, in case we need to debug a multi-window scenario. Dealing with hover in multi-device scenarios is going to be interesting one of these days. Change-Id: I2b687085432ce2e02ca764b8b4669282e0180c54 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix QQWinPriv::deliverSinglePointEventUntilAccepted for wheel, gesturesShawn Rutledge2020-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | WheelHandler was only reacting to one wheel event between mouse moves, because it got added to the QQPointerHandlerPriv::deviceDeliveryTargets() vector, and was not removed at the beginning of delivery of subsequent events, as QQuickWindowPrivate::deliverPointerEvent() does. (In Qt 5 the equivalent vector was cleared in QQuickPointerMouseEvent::reset().) Wheel events are delivered via deliverSinglePointEventUntilAccepted() (grabbing the wheel is still not implemented). Native gesture events are delivered that way too; and sure enough, the same bug happens on the macOS trackpad, whether you are attempting to do pinch zoom or just two-finger-flick. tst_QQuickWheelHandler::nestedHandler() sends multiple wheel events in a row, so we do have some test coverage, and hopefully this issue explains why it needed to be blacklisted. Fixes: QTBUG-88428 Task-number: QTBUG-86729 Change-Id: Id1ed4a38dfa3eb2253c4a60f09f80aea0f69707e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Teach flickable to handle and replay touch as it does mouseShawn Rutledge2020-11-111-19/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQmlListProperty: Use qsizetype rather than int for sizesUlf Hermann2020-11-091-3/+3
| | | | | | | | | | [ChangeLog][QtQml] The QQmlListProperty callback functions use qsizetype now as type for the size of a list. This is in line with the containers that you might use to back the list. Fixes: QTBUG-88269 Change-Id: Ia38403cb32f241e6c70e1a580dbeff1d6d694331 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickWindow: Check if QQuickItem was not deletedBartlomiej Moskal2020-11-091-0/+8
| | | | | | | | | | | | | | Added check into deliverMatchingPointsToItem method for Android device. In QT_VERSION below 6.0.0 touchEnabled for QtQuickItems is set by default to true It causes delivering touch events to Items which are not interested In some cases it may cause a crash. For example using Material Style in Android. QQuickShaderEffectSource may be deleted and then try to handle touch Fixes: QTBUG-85379 Pick-to: 5.15 Change-Id: Ia2c4e016db57ef9c86fcc31d4cfba6154068a546 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: Fix documentation warnings for Qt QuickTopi Reinio2020-11-051-1/+2
| | | | | | | | | | | - Remove links to modules and examples that are not part of Qt 6. - Remove links to entities marked as \internal - Add missing enum value and QML property docs where it's trivial to do so. Task-number: QTBUG-88156 Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Remove unnecessary casts in QQWinPrivate::sendFilteredPointerEventImpl()Shawn Rutledge2020-10-301-8/+6
| | | | | Change-Id: Ie3c996b6e0635bb28b0c9686a4d9207837906e1f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix tst_QQuickMultiPointTouchArea::inMouseAreaShawn Rutledge2020-10-291-1/+1
| | | | | | Task-number: QTBUG-86729 Change-Id: I4cf59a1afacd56be114393e70f132d25a8f084eb Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't send an item a mouse release with a button that it doesn't acceptShawn Rutledge2020-10-291-18/+21
| | | | | | | | | | | | | In tst_qquickitem::ignoreButtonPressNotInAcceptedMouseButtons(), when the right mouse button release occurs, the item has a grab, but it's not interested in the right button, only the left. But of course we still want to deliver mouse drags, so if the button is NoButton and the item is the grabber, it gets the event. Task-number: QTBUG-31861 Task-number: QTBUG-86729 Change-Id: I952acc721a5f80a7fc5619c5fea640dae805e9c8 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Accept a mouse event's point if event is accepted after visiting itemShawn Rutledge2020-10-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When event handling code explicitly calls QPointerEvent->setAccepted(), all points get accepted, because that function is virtual now and makes it so. But the event is pre-accepted before delivery, because by tradition, the item must ignore the event if it doesn't handle it, but is not required to accept if it does handle it. Then in deliverPressOrReleaseEvent() (and other places) we check allPointsAccepted(), in case the event is a touch event and some item chooses to handle only a subset of the points. So it was not OK to remove this line that keeps them in sync after tradtional mouse delivery, which was added in 47ee54455beb1a063515041f85b4c216132491b3. The result was that delivery "kept going" past items that would neither accept() nor ignore() the mouse event, such that items further down could steal the grab, etc. In this case it was the ComboBox itself that received the press event, stole the grab from the TextField, and so the TextField did not get the mouse move and release that would select a range of text. Amends e783ef04fbbaa9a53121a6f575414b48043a10d2. Fixes: QTBUG-87947 Change-Id: Ib856d58a59c798c7bbfc5a222e2462a839fc2bdd Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fix tst_PointerHandlers::touchEventDeliveryShawn Rutledge2020-10-271-2/+2
| | | | | | Task-number: QTBUG-86729 Change-Id: I47a0a4aad7cff956b2ebd450870d625f817690d4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Deal with QEvent::setAccepted() calling QEventPoint::setAccepted()Shawn Rutledge2020-10-271-11/+4
| | | | | | | | | | | | | | | | Traditionally, a QQuickItem subclass could override touchEvent(); if the event is still accepted when it returns, that meant the item handled all the points, so completely that the item should get an implicit grab of those points, and they should not be delivered further to any other items underneath. But it's often not so simple in multi-touch UIs, which is why each QEventPoint has its own accept flag. QPointerEvent::setAccepted() now iterates the points and calls QEventPoint::setAccepted() on each; so QQuickWindow doesn't need to do anything to make that happen anymore. Change-Id: Idbe7abf278411ee2fea598c1a1939f4bdb214aa0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickWindow: Change 0 to nullptr for removeAllv6.0.0-beta2Fabian Kosmale2020-10-211-1/+1
| | | | | | | | | | | | | | The change in qtbase which made removeAll had the unfortunate side effect that were deducing type int now (instead of converting 0 to the null pointer constant), which -after a few indirections- leads to 3365: src/quick/items/qquickwindow.cpp:3785:22: required from here /usr/include/c++/10/bits/predefined_ops.h:268:17: error: ↩ ISO C++ forbids comparison between pointer and integer [-fpermissive] 268 | { return *__it == _M_value; } | ~~~~~~^~~~~~~~~~~ Change-Id: I2ba7c561a2431a8a71f77068daef60d5ae62f17c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Adapt to platform API renameTor Arne Vestbø2020-10-091-2/+2
| | | | | Change-Id: I1f2171e18ec3df71f7eaec1be0e0e0d1442a3860 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Prevent touch->mouse synth from altering the localized touchpointShawn Rutledge2020-10-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | QEventPoint is explicitly shared, so a QMouseEvent synthesized from a QTouchEvent shared the same QEventPoint instance. When QQuickFlickable::filterMouseEvent() calls cloneMouseEvent(), it was re-localizing the point for the flickable, after it had already been localized for delivery to the original receiver item. This caused a lot of failures in Controls, e.g. for any button inside a Flickable, QQuickAbstractButtonPrivate::handlePress() would be given the wrong position. After filtering, we need to be able to resume delivery to the original receiver item without re-localizing the point. During filtering, the filtering parent should receive the same version of the touch event that contains only the points that would be sent to the receiver item, not the potentially more-complete original event. Fixes: QTBUG-87157 Change-Id: I7eec6f5ecfe9f042199f0944897c04fbffb2172e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Remove special case for double-clickShawn Rutledge2020-10-061-1/+1
| | | | | | | | | | Followup to 389d4b1971630a67e3d6fa45b11ec13af59d26e0: after qtbase/871d19a5b96fa5a5be4ac50e3121e0704ff08374 isBeginEvent() will return false for a MouseButtonDblClick event, so that we will never see these events in QQuickWindowPrivate::deliverPressOrReleaseEvent(). Change-Id: I1a04be6b4d6728a9db4aafc4c94b3be12934139b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix compiler warningPaul Olav Tvete2020-10-051-1/+1
| | | | | | | | | Replace evil reinterpret_cast by evil nested static_cast. This fixes the warning `warning: dereferencing type-punned pointer will break strict-aliasing rules' Change-Id: I5ad608377444aa42b79a38db656acd94508716a0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Handle ungrab and grab-cancel consistently; inform handlersShawn Rutledge2020-09-261-30/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call onGrabChanged on Pointer Handlers during grab transitions: this was missing in a97759a336c597327cb82eebc9f45c793aec32c9. Flickable needs to receive an ungrab by child-event-filtering, in order to set its pressed state back to false (as in the cancelOnHide autotest). This is best done as a result of the QPointingDevice::grabChanged signal, while trying to send the ungrab to the item that was the grabber, rather than as a special case. Thus, QQuickWindowPrivate::onGrabChanged (the handler for the QPointingDevice::grabChanged signal) is now the only place from which we call QQuickItem::mouseUngrabEvent() and touchUngrabEvent(). But the result is that they are called in more cases than before, so some tests need adjustment. touchUngrabEvent() is not sent unless the event is available and we can verify that all points have been released. This is important for MultiPointTouchArea: it will react by ending interaction with all points at once. Another thing that's important to MPTA and multi-touch handlers is that QQuickWindowPrivate::deliverPointerEvent() must not clear grabbers of points that are not yet released, in the case that only some points are. QQuickWindowPrivate::removeGrabber() now calls QPointingDevicePrivate::removeGrabber() with its optional cancel argument, so that it will emit either a cancel or an ungrab transition. That's only relevant for Pointer Handlers, whereas QQuickItem mouseUngrabEvent and touchUngrabEvent don't make a distinction. Task-number: QTBUG-86729 Change-Id: Idf03aef2e2182398e0fc4a606c0ddbb2aaed5681 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove redundant definition of QMutableTouchEvent::addPointShawn Rutledge2020-09-181-12/+0
| | | | | Change-Id: I17f5074a2ecbcf7b078def79cedf179d1d25f089 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-602/+402
| | | | | | | | | | | | | | | | | | | | | | | QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove the pointId += deviceId << 24 hackShawn Rutledge2020-09-181-4/+0
| | | | | | | | | 1204ed14dc11e6343a569646428a7ffddd098f8c did this in some places but not others. Now we remove the remaining vestiges when delivering mouse and tablet events. Change-Id: I0aaecab49543ad65952d84f375e78936d737483e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Adapt to QEventPoint changesFawzi Mohamed2020-09-181-19/+19
| | | | | | | | adapt to changes done in qtbase 2692237bb1b0c0f50b7cc5d920eb8ab065063d47 QTouchEvent.touchPoint -> points,... Change-Id: I3ba1d54ff4f3375c781d765e806ac95392ad6c3c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickWindow: Consider z-order of children when delivering pointer eventsYoungSun Park2020-09-151-14/+22
| | | | | | | | | | | | | When creating a target item list for handling pointer events, put children after the parent item if they have negative z-order value. This fixes an issue where an item does not receive a pointer event if there is a child item that accepts the event even when that child item is shown under the parent item as per the stacking order. Fixes: QTBUG-83114 Pick-to: 5.15 Change-Id: I711faa22516f5c2396b1138dc507bcaa4ba22241 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* webOS: Allow to have activeFocus for each windowElvis Lee2020-09-141-1/+25
| | | | | | | | | | | This makes multiple windows focused if there is a single window per screen assuming that windows across screens don't compete the keyboard focus. Pick-to: 5.15 Task-number: QTBUG-83361 Change-Id: Id6f6fd0c95747b03d56c5e535f1313c27d67ab24 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix up beforeSynchronizing signal docsLaszlo Agocs2020-09-091-0/+6
| | | | | | | | | Unlike afterSynchronizing, this one forgets to mention the important distinction between these two signals and other signals emitted on the render thread. Change-Id: I1527e16436fd94c4e128bba123f5ab4c53365d1d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Capitalize "GUI" correctlySze Howe Koh2020-08-301-6/+6
| | | | | | Pick-to: 5.15 Change-Id: I2230e2dcb7bc2497b5dbe71a22c21d84176b5e57 Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
* Remove deprecated QQuickWindow::sendEventFabian Kosmale2020-08-261-56/+0
| | | | | | | | | | | [ChangeLog][QQuickWindow] Removed the obsolete QQuickWindow::sendEvent function. Use QCoreApplication::sendEvent instead. Change-Id: I583ea8f87b870b136315efa4e1105de484e5f1ab Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 17:32:41 +0000