aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items
Commit message (Collapse)AuthorAgeFilesLines
...
* QQuickTextInput: Store mask data in std::unique_ptrFabian Kosmale2020-11-242-5/+5
| | | | | | | | | This ensures that the memory is freed reliably Fixes: QTBUG-88807 Pick-to: 5.15 6.0 Change-Id: I841a5a2b226a69ce50975d95702a948857d1b54f Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Accessibility event is sent on item's geometry changePiotr Mikolajczyk2020-11-241-0/+8
| | | | | | | | | | | In case of enabled accessibility, whenever the geometry of a QQuickItem changes, accessibility module is notified by a LocationChange event. This enables responding to this by for example moving the accessibility frame on the screen. Task-number: QTBUG-79611 Change-Id: I808e835384ef42bba2e9aabecf4be3cda07859fe Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
* Re-enable the caching of shader data loaded from filesLaszlo Agocs2020-11-231-8/+8
| | | | | | | | | | | | There was a mismatch for the cache key: sometimes using the original url as specified in the QML code, sometimes using the resolved url (which has, for example, a relative path expanded to absolute). Change this to be consistent. Pick-to: 6.0 Fixes: QTBUG-88673 Change-Id: I201750716d3ba6dbe73a4799ac56f26f9b8ec820 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* QQuickListView: Fix warning about cast from ASCIIFriedemann Kleint2020-11-201-1/+1
| | | | | | Pick-to: 6.0 Change-Id: Id7193f64093c20bb798b6bc6fbf87f1ce41364d7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Ensure QQuickWindow::transientParent property is documentedTopi Reinio2020-11-201-0/+1
| | | | | | | | | | | | While the parent class (QWindow) has that property, QDoc does not allow documenting properties from base classes. The documentation for QQuickWindow::transientParent includes QML-specific information, so use QDOC_PROPERTY macro in the header file to make the property documentation visible. Pick-to: 6.0 Change-Id: Ib281c776717e09e6929420c6173a520613356d91 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QML Text doesn't reset lineCount when text is emptyShinichi Okada2020-11-201-0/+2
| | | | | | | | | | | lineCount is not reset when replacing a multi-line QML Text 'text' property with an "" empty string. Also, the lineCountChanged signal is not emitted Pick-to: 5.15 Task-number: QTBUG-84458 Change-Id: Ic3c02e6a90e6675eadbaafc6af6ab0356ee98123 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make sure we don't modify the incoming event objects when localizingVolker Hilsheimer2020-11-192-4/+9
| | | | | | | | | | | Restore the position of the single event point after event delivery. Where possible, don't make a localized copy which explicitly shares its data with the original anyway. Instead, access the original directly. Change-Id: I5efa44c336eddeef1a1ab00dc91e2d0f223ed31d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix tst_QQuickMouseArea::notPressedAfterStolenGrab againShawn Rutledge2020-11-192-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-196-22/+38
| | | | | | | | | | | | | | | | | | | 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-187-46/+45
| | | | | | | | | | 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-172-6/+9
| | | | | | | | | | | | | | | | | | | | | 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-173-4/+27
| | | | | | | | | | | | | | | | 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-173-17/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Don't copy QKeyEvent instances, store the data explicitlyVolker Hilsheimer2020-11-162-17/+45
| | | | | | | | | | QEvent is a polymorph type, and even though it has a copy constructor, we shouldn't use it. Use the pattern as in QQuickMouse/WheelEvent. Change-Id: I26ab7b831e1e8dd156c32417f74bc7d800bcf71c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add logging category qt.quick.pinchareaShawn Rutledge2020-11-131-2/+10
| | | | | Change-Id: Iacfffdc774d5ea6980af7a29da07a82f17799e33 Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
* QQuickView docs: show correct usage of setInitialPropertiesFabian Kosmale2020-11-121-0/+4
| | | | | | Pick-to: 5.15 Change-Id: If63f4c59f18bc0754ce2e68e424f6efd0f512d30 Reviewed-by: Mitch Curtis <mitch.curtis@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-116-113/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-098-43/+43
| | | | | | | | | | [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>
* qquicktextinput: compile with explicit QChar(int) constructorDavid Faure2020-11-092-12/+12
| | | | | Change-Id: I78fe89cd97b462299969d57cda099ce54fa8078a Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* 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>
* Clear up Canvas docs wrt the unsupported FBO render modeLaszlo Agocs2020-11-061-17/+2
| | | | | Change-Id: I32f34979a45fea6ee1dfc163fa85f340eb7ca1e3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Promote suffixless graphics api enum values in GraphicsInfoLaszlo Agocs2020-11-062-7/+11
| | | | | | | | | Amends 23dbe3d6e0d3338812ad9f614028a6fdc5a54090. A similar change was done to QSGRendererInterface. Therefore the QML API should follow suit. Change-Id: I2f6d1aeefc17bf3b58b7683f46511d4433194e1c Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Do not assert with OpenGL in qquickcanvasitem testLaszlo Agocs2020-11-061-8/+5
| | | | | | | | | | This is due to not fixing the graphicsApi() check: OpenGL and OpenGLRhi are now the same. The condition should have been removed anyway since it makes no sense in Qt 6. Fixes: QTBUG-88208 Change-Id: I60db54121a0a74bfa3ca1650f90244f36fc7010f Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Use suffixless enum value in graphicsApi check in QQuickFboLaszlo Agocs2020-11-061-2/+1
| | | | | | | ::OpenGL and ::OpenGLRhi are the same thing now. Change-Id: Ic905eb868a7a62d32261bdc025b20e182ed6db7c Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Better describe the Quick 3D use case in QQuickGraphicsConfigLaszlo Agocs2020-11-051-7/+13
| | | | | Change-Id: Iae4a82af31bbefbe34ceef7e68c411e67b41dcd8 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Fix documentation warnings for Qt QuickTopi Reinio2020-11-0514-64/+68
| | | | | | | | | | | - 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>
* QQuickItem: remove unnecessary friendShawn Rutledge2020-11-031-2/+1
| | | | | | | | QEventPoint knows nothing about Qt Quick. Amends a97759a336c597327cb82eebc9f45c793aec32c9. Change-Id: Ie672e0431d3280abff7c34315a2c00cb02697a61 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Doc: Minor fix for \sa syntax that caused a disappeared linkEirik Aavitsland2020-11-031-1/+1
| | | | | | | qdoc would interpret the two {} expressions as just one link Change-Id: I06c5f6ebed097ffc7e93c2ebe94045a8f6a58d78 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Get rid of all instance usage of QFontDatabaseVolker Hilsheimer2020-11-021-2/+1
| | | | | | | | All QFontDatabase APIs are static, use them accordingly. Task-number: QTBUG-88114 Change-Id: Iaa6be07e47adcdb5115e475cc5228f403e9a2b27 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix QQuickItem::ungrabMouse()Shawn Rutledge2020-10-311-3/+2
| | | | | | | Amends a97759a336c597327cb82eebc9f45c793aec32c9 Change-Id: I43f03b699fe2b5e43c0bfe3e1ece3ce7c965f886 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Replace old Q_DECL statements with modern C++Allan Sandfeld Jensen2020-10-311-1/+1
| | | | | | | Since we depend on C++17 now, all of these can go. Change-Id: I0484fd4bb99e4367ec211c29146c316453729959 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Hide QQuickRenderTarget equality operators from ADLVolker Hilsheimer2020-10-312-23/+26
| | | | | | | | Also replace Q_DECL_NOTHROW with noexcept. Task-number: QTBUG-87973 Change-Id: I1471d65076ece5ab6d5efdf0e50b02751789d32b Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Modernize event handling in PinchAreaShawn Rutledge2020-10-303-69/+69
| | | | | | | | | | | | | | | Worrying about the window's touchmouse is really not a relevant concern for a touch-only item; and grabs are done by grabbing the specific points that the pincharea chooses to handle, not by grabbing the touchmouse. We simply didn't have suitable API in Qt 5. Also some drive-by fixes: better packing and initialization in QQuickPinchAreaPrivate; and the stealMouse variable has only been set, not checked, for a long time, so we can remove it. Remove unimplemented handlePress() and handleRelease(). Change-Id: Ia76dc9b9974f663b13c4bb9dac32efe8ed7815c5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Revert "qquickloader: Free memory of loaded components after source change"Maximilian Goldstein2020-10-301-13/+0
| | | | | | | | | | This reverts commit c5085eb8905f1a3c070f866746110980e84be271. It can cause crashes and only fixes an edge case that can't be encountered during normal usage. Pick-to: 5.15 5.15.2 5.12 Change-Id: Ia265f0d6716b59a0f483e5a114b3f3b1a76fe898 Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
* Fix qmltest::event testsShawn Rutledge2020-10-291-0/+2
| | | | | | | | | | | | | | | - Stationary points are delivered like updated points after 05dc0a387ae324f2d6f3d7e633a0a49473f6957a - QQuickItemPrivate::localizedTouchEvent() seems to need to detach QEventPoint instances with Released state, to avoid losing the localization during delivery - calling stationary() or release() without position causes the event to occur at the middle of the item, not at the last-known position as the test was expecting Task-number: QTBUG-86729 Change-Id: I6bdcebc04a11d93d1d006f8269c1df2e9206a393 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>
* Change terminology to "look and feel"Jerome Pasion2020-10-291-2/+2
| | | | | | | | -should be "look and feel" Task-number: QTBUG-88010 Change-Id: I5eef099eec362144651dd95d74023a571c4ac08c Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QQuickTextEdit: ensure we update after changing paddingRichard Moe Gustavsen2020-10-281-0/+4
| | | | | | | | | | | | | | As it stood we would never updated the paint node upon changes to padding. The result was that if you changed padding after start-up, you would not see any visual changes. This patch will ensure that we update the paint node when we change padding. Pick-to: 5.15 Change-Id: I2e9ed4406e8f01c26d1fa2ef09fe35a50f28411c Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@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-272-13/+9
| | | | | | | | | | | | | | | | 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>
* TableView: ensure we rebuild the sync view, even when flicking on a sync ↵Richard Moe Gustavsen2020-10-232-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | view child When two table views are connect through the syncView property, both views will flick when you flick on either of them. This also means that if you fast-flick more than a page on the sync view child, the sync view needs to rebuild, like if you did the fast-flick directly on the sync view. Because we updated the sync view's viewportRect too soon while fast-flicking on the the sync child, we didn't detect that it was a fast-flick, and that a rebuild was needed. The result is that you could sometimes end up with the views getting out-of-sync. This patch will allow TableView to only move the viewport without updating the internal viewportRect while flicking. The viewportRect will instead be sync-ed at a later point, like we do when you flick on the sync view directly. This will ensure that we rebuild if needed, also while fast-flicking on the child view. Task-number: QTBUG-87821 Pick-to: 5.15 Change-Id: Ifc74473eb43406acaa8e24880066fb4ca89d3a4e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 12:35:47 +0000