aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items
Commit message (Collapse)AuthorAgeFilesLines
* Complete splitting of delivery logic qqwindow.cpp -> deliveryagent.cppwip/qquickdeliveryagentShawn Rutledge2021-02-171-11/+0
| | | | | | | Event delivery logic will live in util/qquickdeliveryagent.cpp now. The actual QQuickDeliveryAgent class will be created in a followup patch. Change-Id: I5dcbb7602ff90d87f8e23e09e29b458d0d60905b
* Remove code from qqwindow.cpp to be split into qqdeliveryagent.cppShawn Rutledge2021-02-171-1956/+12
| | | | | | | | | This is the first stage of a split according to the technique in https://devblogs.microsoft.com/oldnewthing/20190916-00/?p=102892 This won't compile as-is, but will after we merge the wip branch in which the functions exist in qquickdeliveryagent.cpp. Change-Id: I1a9749b7877248b54c557de564ec6fa5b0105f73
* Rename DBG_* logging categories in Qt QuickShawn Rutledge2021-02-155-64/+64
| | | | | | | | | | | | | 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. Pick-to: 6.1 Change-Id: I47003b9e525fe70d35dbd2450d03379b52d67c1d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QWindow and QQuickWindow overloads for qmlInfo()Mitch Curtis2021-02-151-0/+15
| | | | | | | Otherwise you can't print out window objects with it. Change-Id: I2a177bd71215cfcb3f5fc47c9171eaba9a12ac0f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qquicktextinput: Fix Undo history for IM eventBartlomiej Moskal2021-02-151-4/+6
| | | | | | | | | | | | | | | | | | Do not set m_cursor (cursor position) before calling removeSelectedText() in processInputMethodEvent(QInputMethodEvent *) method. Before this change, DeleteSelection command was added to history with new cursor position. If this command will be later rolled back, cursor position will not be set correctly. It should be set to position before handling the event. Pick-to: 5.15 6.0 6.1 Task-number: QTBUG-90239 Change-Id: Ib5e46d232e6b32f904e745da4f9e5bc03a58963f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Rami Potinkara <rami.potinkara@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* MouseArea: fix containsMouse behavior during visibility changesVolker Hilsheimer2021-02-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickItem returns whether it contains QGuiApplicationPrivate's lastCursorPosition. Since that position stores the coordinate last seen by Qt (the window border), it will always be within the window, and within an item that covers that part of the window's border. However, QQuickWindow stores the lastMousePosition as well, and resets that value when it receives a QEvent::Leave. We can use that to test whether the window that contains the item has seen a Leave event, in which case the item is definitely not under the mouse. Notes on the test: That we use QPointF() as the "reset" value leave the small possibility that the cursor might be at position 0,0 of the window (ie inside the window), and the QQuickItem there will not be under the mouse. We can't confirm this (through an expected failure test), as QTest::mouseMove interprets a QPoint(0, 0) as "center of the window". And since we can't simulate mouse moves outside a window's boundary using QTest::mouseMove, the test needs to explicitly synthesize a QEvent::Leave for the window. Fixes: QTBUG-87197 Pick-to: 6.1 6.0 5.15 Change-Id: I04870d6e914092275d9d790312fc702fb99f2935 Done-with: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Use functions as signal handlers when accessing parametersUlf Hermann2021-02-124-12/+13
| | | | | | | | | Injected signal handlers are bad practice because they aren't declared. Pick-to: 6.1 Task-number: QTBUG-89943 Change-Id: I3a691f68342a199bd63034637aa7ed438e3a037b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use QQmlBinding::Ptr typedefFabian Kosmale2021-02-101-7/+7
| | | | | | | | | | Instead of spelling out QExplicitlySharedDataPointer<QQmlBinding>. That is consistent with all other code, and makes grepping for binding pointers easiers, as they now all end with Binding::Ptr. Change-Id: I19018732a699368200f129cecf869ece1c8b1a7f Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* qquicktextinput: ensure we update IM when cursor changes positionRichard Moe Gustavsen2021-02-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Normally the cursor will change position inside a text input after receiving a touch or a keypress event. But it can also change position by sending it a QInputMethodEvent. But as it stood, we would in that case not inform the platform input context about it, which meant that the IM state in QQuickTextInput would be different from the IM state in QPA. A bug on iOS could be seen from this when dragging the cursor around using the magnifier glass. In that case QIOSTextResponder would move the cursor in QQuickTextInput using QInputMethodEvents. But since this would not be forwarded back to UITextInput, the result would be that if you e.g pushed backspace on the input panel, you would delete the character at the position the cursor had before the drag. This patch will ensure that we update platform IM state whenever the cursor changes position from QInputMethodEvents. Pick-to: 6.0 5.15 Fixes: QTBUG-72757 Change-Id: Ic39c60fbce982f80d014befddbb2d4439ddeea4f Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Don't hide the inputMethod when finishing the editAndy Shaw2021-02-041-2/+0
| | | | | | | | | | | | | There is no reason to hide the inputMethod explicitly when finishing the editing. This will be taken care of for us by the platform plugin and will account for a situation where Qt Quick Controls 2 will check if the item had focus when it is in an popup being closed at this point too. Pick-to: 6.1 Change-Id: I687718ae9b4fabbf6456597a475507d2ec1a1f45 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Remove superfluous include directiveFriedemann Kleint2021-02-021-1/+0
| | | | | | | | | | | It is not conforming to the include conventions (module missing) and thus breaks the Qt for Python doc build. Introduced by 48b4c1f450109b148f03f62574d78b460859c4a1. Pick-to: 6.0 Change-Id: I1ff56a967c457f1909b7f6e2e430458e3a3f47c9 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* 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>
* Add env.vars. to toggle pipeline cache load/saveLaszlo Agocs2021-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QRhi has APIs (but private ones) that allow retrieving and restoring the contents of the "pipeline cache". (which may map directly to VkPipelineCache, or may be a simulated, OpenGL program binary based solution) In many cases it is convenient if the saving of the cache blob to a file, and then, during subsequent runs of the application, the loading of cache contents, can be enabled via environment variables: QSG_RHI_PIPELINE_CACHE_SAVE=filename maps to setting the EnablePipelineCacheDataSave flag on the QRhi, and writing the collected data to file upon application exit. (more correctly, when the QRhi is about to be destroyed by the render loop) QSG_RHI_PIPELINE_CACHE_LOAD=filename maps to attempting to read the contents of the specified file, and, if successful, passing it to QRhi right after initialization. When supported and the data is not corrupt or incomplete, the result is likely improved pipeline creation times (the exact details depend on the driver with Vulkan, while with OpenGL it all maps to glProgramBinary instead of compiling from source) Setting QSG_INFO=1 can be useful to see what is happening when the above 2 env.vars. are set. With OpenGL the simulated "pipeline cache" is orthogonal to the Qt 5 era shader program disk cache: loading from both is supported transparently to the application. When QSG_RHI_PIPELINE_CACHE_SAVE is enabled, the disk cache will not be written to. Task-number: QTBUG-90398 Change-Id: I82d9a81e9dab39d3513a6aa7c6e1ff748a4ec6e5 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Expose the list of preferred instance extensions to rendercontrol usersLaszlo Agocs2021-01-213-5/+38
| | | | | | | | | As all QRhi stuff is private, it needs to have a public counterpart in Qt Quick in order to fully support the case of Vulkan-based QQuickRenderControl usage. Change-Id: Iaf9a7aa56022acd31af6ebf16de6b83a04966ff4 Reviewed-by: Andy Nichols <andy.nichols@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>
* Remove the qmake project filesFabian Kosmale2021-01-152-264/+0
| | | | | | | | | Remove all qmake project files, except for examples which are used to test that qmake continues to work. Change-Id: Ic4abb72dc2dcd75df7a797c56056b6b3c5fe62ac Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Pass QWheelEvent data to QML engine via QQuickWheelEvent pointerVolker Hilsheimer2021-01-152-16/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing events as objects or references in signal parameters requires copying, and we removed the broken copy semantics from QEvent for Qt 6 as much as possible. QVariant::fromValue still allows creation of a QVariant from a type that doesn't have a (public) copy constructor, which is why this passing of a QWheelEvent through a QVariant to QML went unnoticed. While QWheelEvent is a gadget and thus supposed to be invokable from QML, it's still a QEvent. Most QEvents are not gadgets - like QKeyEvent, QMouseEvent, QTouchEvent. We have QQuick*Event QObject wrappers instead to provide access to the low level event data from QML. So, use a single QQuickWheelEvent object instead to pass the data to QML, that class is designed for exactly that prupose. We need to copy the data anyway, and since we don't need to create/destroy the wrapper object for each event, this has no practical overhead. Extend the QQuickWheelEvent to provide access to the phase information of QWheelEvent as well, and simplify the reset() method. Note: making the QQuickWheelEvent store the QWheelEvent directly would allow passing calls to setAccepted through to the QWheelEvent. That is left for a future cleanup, and another reason for not passing events around as copies. Fixes: QTBUG-89594 Pick-to: 6.0 Change-Id: Id86a9b30c5a8c7c50091e464e368568a7f5ca2ea Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Flickable: ignore trackpad events with px deltas in disallowed directionShawn Rutledge2021-01-151-5/+18
| | | | | | | | | | | | | | | | If Flickable.flickDirection == HorizontalFlick, then if the accumulated QWheelEvent::pixelDelta()'s abs(dx) > 2 * abs(dy), clearly the user is trying to scroll horizontally; otherwise, don't accept the event. That way the event is allowed to propagate to a parent Flickable that does allow flicking vertically. Likewise if the nesting is the other way around, only allow the inner vertical Flickable to accept if the flicking is actually vertical. Fixes: QTBUG-57245 Fixes: QTBUG-80236 Pick-to: 6.0 Change-Id: Ieb0bf9310a67210ce7e9fe7a80c88baef2cc7ede Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix Text with ElideRight not being rendered when width goes from 0 to >0Fabian Kosmale2021-01-141-1/+4
| | | | | | | | | | | | | | | | | | QQuickText attempts to reduce relayouting. However, it was a bit to aggressive in doing that. If only the width changed in a geometrychange, it would not relayout if widthMaximum was true. However, if the width goes from 0 to greater than 0, the value of widthMaximum should have actually been false (but we would only notice this after relayouting). Thus, don't skip relayouting in that case. Amends 56ade46b4234bb828b8e4f9a6bf83b5687bd122e, which fixed the same issue, but for height. Fixes: QTBUG-83408 Fixes: QTBUG-33608 Pick-to: 6.0 5.15 Change-Id: I14b610c703eb0496c71de7b12ad9fcf16842af64 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Enable importing OpenGL textures for the GL_TEXTURE_EXTERNAL_OES targetLaszlo Agocs2021-01-142-3/+11
| | | | | | | | | 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>
* Remove QQmlCleanupUlf Hermann2021-01-131-2/+1
| | | | | | | | | | | | | | | | | The only place where it was still used is QQmlOpenMetaObjecType. The only effect of QQmlCleanup is that clear() is eventually called by the engine. In the case of QQmlOpenMetaObjectType the only effect of that was that the "engine" member was reset. However, the only place where that member was used was in setCached(), and in that place it was irrelevant. There is no reason why setCached() should be prohibited when there is no engine. We may be worried that the property cache assigned to the open metaobject might go away somehow if there is no engine, but the cleanup mechanism clearly demonstrates that checking for the engine on setCached() does not protect against this. Fixes: QTBUG-90004 Change-Id: I05445eaeb53a64c70de366090ea2ee4aecf2bad8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix warning and assert when removing items from groupsMaximilian Goldstein2021-01-111-1/+3
| | | | | | | | | When removing items from groups actively shown by a model filter a warning and assert was triggered in the past. This change fixes this behavior. Fixes: QTBUG-86017 Change-Id: I49b7498a3d03141b654e453a3c35a43fc7ba804a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Doc: mention that Item's childrenRect property is local to the itemMitch Curtis2021-01-051-0/+8
| | | | | | | | As opposed to being local to the item's parent. Pick-to: 6.0 5.15 Change-Id: Idcf2cdbedcac24a6890ce761c3f2a23f2c7a8dc4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* doc: explain QQItem event delivery, handlers, setAcceptTouchEvents()Shawn Rutledge2021-01-041-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | We quietly recommended calling setAcceptTouchEvents() in the Qt 5.10 release notes in any Item subclass that wants to receive touch events, and in the docs for setAcceptTouchEvents() itself; but the message about the impending behavior change might not have been obvious enough. In Qt 6 it becomes mandatory, so clearer docs will hopefully help to stave off bogus bug reports. We also never had a great overview of event handling from an Item's perspective; now it's a little better. Followup to ab91e7fa02a562d80fd0747f28a60e00c3b45a01 and a97759a336c597327cb82eebc9f45c793aec32c9 [ChangeLog][QtQuick][QQuickItem] When subclassing QQuickItem, you should call setAcceptTouchEvents(true) if you need the item to receive touch events. It will be required in Qt 6. Pick-to: 6.0 Pick-to: 5.15 Task-number: QTBUG-87018 Task-number: QTBUG-87082 Change-Id: I1c7a43979e3665778d61949c9d37c1d085ed594b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Show a tableview even if the syncView has an empty modelAndy Shaw2020-12-091-5/+2
| | | | | | | | | | By showing the tableview, we can be sure that headerviews will be visible even in the syncView has an empty model. Fixes: QTBUG-87526 Change-Id: I68c8b119122a2d2f88c2afbeb2d6c71a83a3ce33 Pick-to: 5.15 6.0 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Kill Flickable's wheel momentum if angleDeltas not multiples of 120Shawn Rutledge2020-12-072-34/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wheel momentum is great on old "clicky" mouse wheels: they feel really clunky without this feature. But it's also terrible on most laptop touchpads. We still aren't generating QWheelEvents with pixel deltas and ScrollPhase on most platforms (still only on macOS); but eventually we should. However, those laptop touchpads tend to generate angleDeltas that are not multiples of 120. Added logging categories qt.quick.flickable qt.quick.flickable.wheel and qt.quick.flickable.velocity. [ChangeLog][QtQuick][Flickable] Flickable now tries to detect whether you're using a "clicky" wheel on a desktop mouse. A laptop trackpad can generate QWheelEvent::angleDelta values that are not multiples of 120; in that case, smooth scrolling with momentum is disabled, to avoid losing control of scrolling. Set the environment variable QT_QUICK_FLICKABLE_WHEEL_MOMENTUM_ENABLED=0 to opt out of the old behavior entirely, or set it to 1 to opt in unconditionally. Pick-to: 6.0 Task-number: QTBUG-38570 Task-number: QTBUG-56075 Task-number: QTBUG-80720 Task-number: QTBUG-82565 Change-Id: I0da2d31259fa1c79ab217a3fa9e888893fc7b235 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Allow parent to filter out-of-bounds synth-mouse for grabbing handlerShawn Rutledge2020-11-301-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider Flickable { Text { TapHandler { gesturePolicy: TapHandler.ReleaseWithinBounds } } } On press, TapHandler gets the exclusive grab. Now drag vertically. The Text is short in stature, so your finger soon strays out of bounds of the Text, likely before you have dragged past the drag threshold. In this case, we want Flickable to continue to filter the move events because of the fact that TapHandler is the grabber. If it was a MouseArea instead of a TapHandler, it already worked that way; so this makes behavior of handlers more consistent with that. More specifically: QQuickPointerTouchEvent::touchEventForItem() now generates a touch event even if the touchpoint is not within the bounds of the given item, but is grabbed by one of that item's handlers. Until now, we had that exception only if it was grabbed by the item itself. tst_FlickableInterop::touchAndDragHandlerOnFlickable now always drags the delegate at index 2 (the third one) from its upper-right corner, upwards and to the left. The first drag goes outside the delegate's bounds, but the Flickable/ListView/TableView filters and takes over anyway (on the next drag), to prove that it is correctly depending on the grab that the TapHandler (or DragHandler) took on press. Pick-to: 5.15 Pick-to: 6.0 Fixes: QTBUG-75223 Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Correct height properties for QQuickText with reducing lineHeightReinhard Raschbauer2020-11-261-12/+13
| | | | | | | | | | | | | | | If the property lineHeight is used to reduce the line height, either by setting a proportional factor smaller 1.0 or a pixel size smaller than the font size, the offset calculated in lineHeightOffset is not taken in to account to calculate the height properties. But the offset is used to position the the rendered text. In the current implementation the property lineHeight does not have an effect on single line texts. This change takes that into account and adds lineHeightOffset to all height properties. Fixes: QTBUG-88229 Change-Id: Iab7d9b39a4c7876c7c95e43be6846623c10b0607 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Change QQuickRenderControlPrivate from autotest to private exportLaszlo Agocs2020-11-261-1/+1
| | | | | | | | | | | | There are legitimate cases for using the private class, the number one case being Design Studio where QQuickRenderControl and QRhi are used together. At the moment things work presumably because only member variables are accessed, and that works even in builds that do not have the member functions exported. Fix this up to be future proof. Pick-to: 6.0 Change-Id: I054deb31607ca8c95fccb2f5988dde6f0a9c372a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Document pooled(), reused() signals for ListView QML typeTopi Reinio2020-11-251-1/+32
| | | | | | Pick-to: 6.0 Change-Id: Ic8b2fa8333fdc6aae051f3b2faa3a0c0ecad9ad5 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Empty the ShaderEffect content cache on releaseResourcesLaszlo Agocs2020-11-242-0/+12
| | | | | | | | 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>
* Simplify ShaderEffect's internal shaderInfoCacheLaszlo Agocs2020-11-241-23/+5
| | | | | Change-Id: Id542b473c1596f9933cdef747f7fe329988618d4 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove unused external function declaration in ShaderEffectLaszlo Agocs2020-11-241-2/+0
| | | | | | Pick-to: 6.0 Change-Id: I05e3f804af3668235f97cebc54e1904a90092385 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Purge renderpass refs from renderer when redirecting via QRhiRtLaszlo Agocs2020-11-242-7/+9
| | | | | | | | 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>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 00:20:14 +0000