aboutsummaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge 5.14 into 5.14.1v5.14.1Kari Oikarinen2020-01-1512-31/+185
|\ | | | | | | Change-Id: Iefb900b42cc0476e62342724a5f3a480c09ce354
| * QQuickItemView: fix crash when changing modelWang Chuan2020-01-152-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When visible items become invisible, ListView will try to cache them and redisplay these items if necessary. However, we can't cache items when changing to a new model, since the old one will be deleted later Fix by adding a flag to let ListView know we are clearing items and prevent cache unnecessary items Fixes: QTBUG-80203 Change-Id: I50dcd3f0586c93496b143bdad0e59751360501a8 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * fix for out-of-screen preview windowsUlf Hermann2020-01-142-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | The problem was that the screen position was changed by the user and it did not check this before it set it to that saved position. Also added a warning if it is still happening - which is not expected anymore. Fixes: QTBUG-79323 Change-Id: Id3d945626461016d51fcad9f8882c3d39544a985 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
| * Register PointerScrollEvent and document the WheelHandler.wheel signalShawn Rutledge2020-01-133-4/+142
| | | | | | | | | | | | | | | | | | | | | | Writing an onWheel() handler script was working and mentioned briefly in docs; but PointerScrollEvent and the signal were not documented. Also fixed the type of QtQuick::WheelEvent::inverted: bool not int. Fixes: QTBUG-81302 Change-Id: I31342955c42e20ff52460a1b7ee95da325e38af6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
| * Remove unneeded/unused signalAlbert Astals Cid2020-01-132-2/+0
| | | | | | | | | | | | | | | | | | | | QQuickMultiPointHandler inherits from QQuickPointerDeviceHandler, which inherits from QQuickPointerHandler that already has a marginChanged signal. It's the only place that signal gets actually emitted from. Amends da722fb448f06cf43780e6f857a1ccd9f07176d6 Change-Id: I8ba3129ed69903d6f3cff56401c8a18580af0375 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * QQuickItemView: Fix iteration/deletion logicUlf Hermann2020-01-101-12/+16
| | | | | | | | | | | | | | | | If a QVector has been modified from the outside, all its iterators are invalid. Therefore, we need to do index-based iteration here. Change-Id: I02b850daf6aadd8f8a81cc93b0d295e1170d7dd6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
| * On QQmlEngine destruction drop singletons before type loaderUlf Hermann2020-01-101-2/+2
| | | | | | | | | | | | | | | | The singleton destruction can trigger additional types to be loaded. Fixes: QTBUG-80840 Change-Id: Ifa406b2a1cfd3b9e9b36e8005dfc0808eebf15cf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
| * SequenceObject: Better message when trying to write readonly containerUlf Hermann2020-01-091-1/+3
| | | | | | | | | | | | | | Before it would only output "Type Error". Change-Id: Ibd3a85f327c3ce8c58295c7e900c516b77c85a2b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
| * Fix unused variable warning on big-endianShawn Rutledge2020-01-081-0/+2
| | | | | | | | | | | | | | Fatal because of -Werror. Change-Id: I535848be1c733c0718779c8a4c8c93ed3873cc88 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | Return false for user types in isSaveable()Andy Shaw2020-01-101-1/+4
|/ | | | | | | | | | When calling isSaveable() for a user based type then it should return false because the client will not be able to read these types. This prevents it from using the wrong streaming operator for the user types then. Change-Id: I7f3bff359dd0c3fa49dc4e83db0057b79c481ed9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* V4: Avoid integer overflow on typed array length checkUlf Hermann2020-01-081-2/+5
| | | | | Change-Id: I370b4c4bd0d7962878849ca7c5edef6cb36eca25 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Check stack limit in FunctionPrototype::method_apply()Ulf Hermann2020-01-081-1/+7
| | | | | | | | | We could just crash there, assuming unlimited memory, but as this particular place seems to be a very attractive target for various mischief, let's just plug it. Change-Id: I3b0369ceb34dafd12ce8dc1f189fc5f9ee82c169 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* V4: Don't crash when iterating invalid Proxy objectsUlf Hermann2020-01-082-2/+2
| | | | | | Fixes: QTBUG-81109 Change-Id: I97f37c68d33f414d7bffa9b66e0aaed93370dc68 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* V4: Don't crash when sorting arrays with non-stringifyable entriesUlf Hermann2020-01-081-0/+6
| | | | | | Fixes: QTBUG-81108 Change-Id: I7e121776a2416b5338c4c1309ec7cc31c703ad28 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix unused variable warningShawn Rutledge2020-01-071-2/+1
| | | | | | | This was fatal because of -Werror. Change-Id: Ibe06f77d4728268af3f099554f7151bdaf9ac26b Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Stabilize QQuickItemParticleLouis du Verdier2020-01-072-46/+32
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes two crashes and a memory leak in QQuickItemParticle. The first crash was caused by the list m_loadables that kept pointers on QQuickParticleData, that could in the meantime become dangling pointers if the associated particle expired or got deleted by a call to the reset() method of the particle system. Its role was to keep a list of particles that did not have a delegate instantiated yet, in order to create them in the tick() method. This list is removed and the list of particles to handle is directly deduced in the tick() method. The second crash was caused by the list m_deletables that could in some situations (generally due to a reset()) contain multiple times the same delegate, and therefore cause a double delete in processDeletables(). This list is changed to a set to avoid this situation with a minimum impact on the rest of the code. The memory leak was caused by the m_managed list of delegates that was not freed when QQuickItemParticle gets deleted. Task-number: QTBUG-71193 Change-Id: I6fe30ee59a9a0bb90c14c62c7a48a50f465a9e0c Reviewed-by: Mikhail Svetkin <mikhail.svetkin@gmail.com>
* QV4: Support printing arrays with circular referencesFabian Kosmale2020-01-071-4/+9
| | | | | | Fixes: QTBUG-81105 Change-Id: Iaf0597cea3a5572f020c5f87a843774f33cc01fd Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QV4: Array.includes: Support large arraysFabian Kosmale2020-01-071-1/+2
| | | | | | | | | Creating new ScopedValues in the loop was quite wasteful, and would trigger a crash. We now simply reuse the ScopedValue. Fixes: QTBUG-81104 Change-Id: Ie1efd144886861a21c8f6827d7fd23699a1e0dcc Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QV4: Check recursion limit in toStringFabian Kosmale2020-01-071-0/+1
| | | | | Change-Id: I18b7a4e00150f6c47c991a5164901159b7f946b9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QV4MM: Fix crash caused by MarkStack overflowFabian Kosmale2020-01-073-1/+8
| | | | | | | | | | | | | | MemoryManager::collectFromJSStack did push to the mark stack without checking if there is actually still space available. To fix this, we now drain the stack once we hit the limit. The test case is a slightly modified version compared to the reported one, removing one loop. This was required as our regular expression does not throw an exception when there are too many capture groups. However, to trigger the bug, looping was not actually necessary. Change-Id: I4d00865f25a989c380f4f5b221f4068c80b71d2b Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* V4: Catch error when compiling broken RegExpsUlf Hermann2020-01-071-2/+2
| | | | | | | Otherwise we try to assign an invalid RegExp object, which crashes. Change-Id: I85478406524a2a9d7542758caaa1b42b4090bb93 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* V4: Fix sorting of sparse arraysUlf Hermann2020-01-061-1/+1
| | | | | | | setArrayData() needs to handle a nullptr argument. Change-Id: I1ea05d9db9beb1fede6d3c068cfcf700702e8aa6 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Avoid oob access on Array.concatUlf Hermann2020-01-061-1/+1
| | | | | | | | | | As we have already determined that we're past the end of the allocated space on the source object by checking os->values.alloc, we should conclude that all the remaining values are undefined. Fixes: QTBUG-81037 Change-Id: I664f22b7eb37c26061e8a9e2f88bcf2a7b6e09f3 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Emit QQmlEngine::warnings when load failsFabian Kosmale2020-01-061-1/+1
| | | | | | | | | This uses the existing infrastructure for reporting QML errors, instead of simply using qWarning. Fixes: QTBUG-81093 Change-Id: Ie18656a57f28fa9dfe922936fd05b44ebe1281e2 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QV4::Engine: replace std::function with a function pointerFabian Kosmale2020-01-062-5/+5
| | | | | | | Turns out, we actually do not need to capture anything Change-Id: I6194b45a1e8053be079d25a6d81212fa226fd3ea Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QV4::ExecutionEngine: provide QNAM accessorFabian Kosmale2020-01-034-2/+27
| | | | | | | | | | | In XMLHttpRequest, we need to get the QNetworkAccessManager from the engine. However, if the request originates from a WorkerScript, there exists no qmlEngine. We therefore add a new indirection to access the QNAM, and set it up accordinly in registerWorkerScript. Fixes: QTBUG-81055 Change-Id: I8915202b6d6b7139c8386304b3d1d7a22a82045e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QQuickWindow: make subFocusItem a QPointerFabian Kosmale2020-01-031-1/+1
| | | | | | | | | While running the fuzz tester, a crash was found related to the fact that the subFocusItem was already partially deleted. Task-number: QTBUG-34779 Change-Id: I62c48cf40baabc9f0a81074cc6408e9073459165 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix the build with -no-guiLiang Qi2020-01-021-0/+2
| | | | | | Task-number: QTBUG-74602 Change-Id: I08e8df96b10fbc0b58fbdae296c9d54de977e3f9 Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
* QQmlAdaptorModel: Guard access to wrapped AIMUlf Hermann2020-01-021-32/+44
| | | | | | | | | | | | | | | | | | The QAbstractItemModel may be nullptr, in particular when it gets deleted from the outside. In some places we did check for that, via operator T* from QQmlGuard, in others we didn't. The checks were quite hard to read as "if (model)" first invokes a conversion operator on a base class and then implicitly converts the result to bool. Similarly adventurous, "if (*model)" invokes operator* on a base class and then converts the result to bool. Make all the checks explicit, and add new ones where they were missing. Also, as we already retrieve the AIM in order to check it for nullptr, re-use it for the actual operation. Task-number: QTBUG-80963 Change-Id: I3548e22e9d2bef485a1cd4acf70839eb8e599e62 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QV4Engine: support conversion of QJSValue to SequenceTypeFabian Kosmale2019-12-201-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | 8704c640946ac852668638e2980d3e2b78aa27ae introduced new conversions via sequentialIterableToJS. Due to that, QVariant properties which formerly stored e.g. std::vector<QObject*> now would store a QJSValue. Those would still claim to support a conversion to QVariantList, but -contrary to what our documentation says-, we were not able to do a conversion to QSequentialIterable. The default constructed QSequentialIterable would then crash when calling begin(), as that function pointer was null. This patch fixes this by adding the necessary support to convert a QJSValue containing an array. Non-array QJSValues will still return an "empty" QSequentialIterable. Note that this changes what happens when a QJSValue is converted to a QVariantList, as QVariantValueHelperInterface<QVariantList> will check first if there is a converter to QSequentialIterableImpl before attempting to call any directly installed converter to QVariantList. In order to not change the existing behavior, the QSequentialIterable returns the QVariant corresponding to the QJSValue at a given array position, intead of a QVariant containing the QJSValue. Fixes: QTBUG-80609 Change-Id: I8101229c0d2043b3f2d618ed035b279844802dd8 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Remove use of wrapper macros for feature detectionTor Arne Vestbø2019-12-162-2/+2
| | | | | Change-Id: Ic9cd7e4ff2c5d253879b0aeaa15dbc25cad82891 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.14.0' into 5.14Qt Forward Merge Bot2019-12-135-7/+13
|\ | | | | | | Change-Id: Ibd935bf31aa2bcb2e4051c865ab946daeeeecddb
| * QQuickPixmapCache: Don't dereference nullptrv5.14.0-rc2v5.14.0Fabian Kosmale2019-12-051-3/+5
| | | | | | | | | | | | | | | | | | | | Consistently check that job->data is not null before derefencing it. Fixes: QTBUG-80510 Fixes: QTBUG-79937 Change-Id: I894503ddd2254814463073cc12f8365641efc689 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * QML: Resolve conflict in ImportSpecifier rulev5.14.0-rc1Ulf Hermann2019-11-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IdentifierReference could resolve to both ImpordBinding and IdentifierName, causing ambiguity in the grammar, and ultimately caused parse failues when parsing an import statement. This is now resolved by explicitly telling the parser to prefer shifting. This is a partial cherry-pick. Apparently the effect observed in the original change and fixed inline can also be triggered in different ways. (cherry-picked from commit 41bbf7e376d0e374dc7c4e2a5ed4157a1b880b4a) Fixes: QTBUG-80423 Change-Id: Iaec29c452b577312248a17cb48f005f4fc0bd8c4 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
| * mouseDrag(): ensure that intermediate moves are done for all dragsMitch Curtis2019-11-261-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code checking if the intermediate move distance was less than the drag threshold, but without accounting for negative distances. Since the negative distances were naturally less than the drag threshold, the intermediate distances were set to zero and the intermediate moves were never done. In practice, this means that mouseDrag() never did intermediate moves (i.e. what happens during a drag in real life) for drags that go from right to left or upwards. Task-number: QTBUG-80152 Change-Id: Ic27021f5ce5ba2937e95fb2dfb532bd2136f4205 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> (cherry picked from commit fad8ef3e4133538e3785d7067c35c652bc894711) Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
| * Fix NativeRendering text on core profileEirik Aavitsland2019-11-263-3/+3
| | | | | | | | | | | | | | | | This is a continuation of af090d8, making sure the same dpr snapping is done in the core profile shaders. Change-Id: Iccd19a377968fb7bfbd49c3ef13b72284a48bab1 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | rhi: Mark window as unused when neededLaszlo Agocs2019-12-111-0/+4
| | | | | | | | | | | | | | | | This is a bit more convoluted, but boils down to no-opengl + no-vulkan. Task-number: QTBUG-80692 Change-Id: I508116721ae8ea5013546f20ac89b67929305b52 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | qv4sequenceobject.cpp: Add "here be dragons" commentUlf Hermann2019-12-111-0/+16
| | | | | | | | | | | | | | | | No one should remove this at() before Qt6. Task-number: QTBUG-80535 Change-Id: I464c6f675dc68ad9762fcb594bb4d6ba6bdaf316 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Fix unused var in no-opengl buildsLaszlo Agocs2019-12-111-0/+2
| | | | | | | | | | | | Change-Id: I9c436f408562faaf74e2301ae93e25a0c4e9b22e Fixes: QTBUG-80692 Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* | QV4Engine: Remove runtime memberFabian Kosmale2019-12-091-2/+0
| | | | | | | | | | | | | | | | Runtime is nowadays only a collection of static methods, there is no point in having it as a member anymore. Change-Id: Ibe9fba3c7e52fbc0b16b6a5d717dd2d23ab21088 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | QQuickTableView: set empty content size when table is emptyRichard Moe Gustavsen2019-12-091-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | From before we would bail out early from the rebuild process if we detected an empty table. A result from this is that we left both contentWidth and contentHeight unchanged. This patch will set an empty content size when the table is empty. The effect will be that the user cannot flick the view around based on the old size. Fixes: QTBUG-80505 Change-Id: I3ac080476269fd5906ce79fa007eabb59b5ff4b1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | QQuickTableView: ensure we release items in the old model and not the newRichard Moe Gustavsen2019-12-091-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As it stood, we would wait to release loaded items until we started the rebuild process, if the old model was a DelegateModel. But at that time, the model would alread have been changed, so we would release the items by calling out to the wrong model. This patch will ensure that we always release the items immediately when syncing the model, which will also cover the case when the model is a DelegateModel. Fixes: QTBUG-80570 Change-Id: I1b06011f4795727d04d9cd8c20381f65552b8fe8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | QQuickTableView: support assigning a DelegateModelRichard Moe Gustavsen2019-12-091-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally you either assign a model to TableView that already has a delegate (or don't need one), like DelegateModel or ObjectModel. Or instead you assign a QAIM model and a delegate directly. But if you assign both a delegate and an ObjectModel, TableView would be confused, and ignore the assigned model and instead create an internal wrapper model that ends up empty. This patch will ensure that we don't create a wrapper model in such cases, but instead forward the delegate to whichever model is assigned, even if it ends up as a no-op for models that don't use one. Task-number: QTBUG-80534 Change-Id: Idd220df08617c379dc7808ee1f41c862b78cc201 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | Don't let PointerHandler steal touch grab from preventStealing MouseAreaShawn Rutledge2019-12-061-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The scenario: - mouse press: MouseArea grabs; DragHandler gets a passive grab - drag a little: DragHandler's drag threshold is exceeded - drag some more: DragHandler tries to take the exclusive grab This grab takeover succeeded before, because although MA has keepMouseGrab(), the event being delivered is a touch event, and MA does not have keepTouchGrab(). If this happens while QQuickWindowPrivate::touchMouseId is the same touchpoint that the DragHandler is trying to grab, it should not succeed, because we honor the keepMouseGrab() flag. I.e. keepMouseGrab() implies keepTouchGrab() whenever the touchpoint under consideration is currently the touch-mouse. On the other hand, if a DragHandler is used on some item inside a Flickable: on press, the Flickable grabs right away (it has a bad case of FOMO), but the DragHandler just gets a passive grab. When the drag threshold is exceeded, DragHandler must be able to steal the grab from Flickable, because Flickable was just being too aggressive. So now we have the rule that if the Item it wants to steal the grab from is a parent of the type that filters all events, it's OK to ignore the keepMouseGrab() flag and steal anyway (as it did before this patch). Fixes: QTBUG-79163 Change-Id: I2b3f175bea867cb737357857657653b0a7b83995 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | TapHandler: don't reject stationary touchpointsShawn Rutledge2019-12-061-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Multiple TapHandlers must be able to react to multiple touchpoints. Often when multiple touchpoints are in contact, some of them will be stationary. In that case TapHandler should not give up its active state, which is the result of returning false from wantsEventPoint(). This partially reverts commit dcc7367997e7241918cdf0c702c7bb8325eb1ad4. Fixes: QTBUG-76954 Change-Id: I836baf771f09d48be8d032472b0c3143e8f7f723 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Particle system: fix infinite loop after running for many hoursYulong Bai2019-12-062-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The infinite loop was triggered by several issues coincide together. In short, the direct cause is the particle's born time and lifespan were represented in 32 bit floats and not precise enough to pass aliveness check as time grows large. While the time grows large, the resolution of floating point decreases to the extent that resolution is even bigger than 2 milliseconds. Then it will fail to pass the aliveness check. Then, the dead particles will be treated alive and they are kept inserting into and popping out of the particles heap, which is similar to a live-lock. The fix is to separate freeing dead and inserting back alive ones in two different loops, ensure that the emitter can update time for next frame. There are still other issues: 1) as the times runs very long, the particle needs several frames's updates to actually make the states change noticeable, which means animation may become not so smooth after running for too long (like several days). May change particle's born/lifespan time to 64 bits in another patch. 2) the particle system's and animation's timers are 32 bit integers, after 2^31 milliseconds(24.8551348 days), they will overflow. May promote them to 64 bits in another patch. 3) as the time grows even larger such that the resolution is bigger than 16ms at 60 hz frame rate, the live-lock may occur again. Because the timer advances/delta will be not large enough to make dead ones reused. The next live-lock estimated time is 2^24*16 milliseconds = 3.10689185 days. The final fixes are 1) and 2) 4) may change the particle system's internal timer be set to arbitrary value (fast forward to large value) for easier writing autotest for above cases. Change-Id: I1190c0814c8197876b26dd4182dc4b065dd1ece6 Task-number: QTBUG-64138 Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
* | QQuickItemView: Emit correct change signal on model resetFabian Kosmale2019-12-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the variable was manually set to -1 beforehand, we would never emit the change signal, leaving bindings stale. However, simply removing the assignment would lead to not triggering the signal when currentIndex was 0. So now we set it to -2, which cannot happen in any other place. Note that QTBUG-64998 was already mostly fixed due to earlier changes fixing the currentItem part, only currentIndex was still broken Fixes: QTBUG-68232 Fixes: QTBUG-64998 Fixes: QTBUG-63422 Change-Id: I885e06f1e258e67c3368d017bf79bff760440863 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | Compiler: Support >32k stack slotsUlf Hermann2019-12-052-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the code generator would truncate the stack slots when writing the compiled function, as that one only had a 16bit field for them. Also, add a debug-mode check for stack overflows to the interpreter. Unfortunately, as it triggers a stack overflow, the test will not reliably fail without this change. Fixes: QTBUG-80511 Change-Id: I3019bb2de657ae4c3e1040db798a83533f854bff Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Fix ObjectModel item not being rendered when moved between modelsMitch Curtis2019-12-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When moving an item from ObjectModel A to ObjectModel B, polishes are scheduled for the respective ListViews in order: the ListView for A first, and then the ListView for B. However, when it comes time to do the actual polishing via updatePolish(), the list of items is traversed backwards. This means that the following calls var item = objectModelA.get(0) objectModelA.remove(0, 1) objectModelB.insert(0, item) will result in updatePolish() being called for ListView B first, and then ListView A. As a result of this, setCulled(false) will be called by ListView B (since the item is now visible within it), followed by ListView A calling setCulled(true) (since the item is now no longer in it). As there is no way for these models to know about each other (and it's not feasible to store refcounts in QQuickItemPrivate::extraData, since ObjectModel is in QtQml.Models, which can't know about QtQuick), this patch makes ListView check if the item is parented to its contentItem before culling it. This prevents it from hiding items which are no longer shown in its view. Change-Id: If50614ebc269fae875195bbc63c0c04dab237775 Fixes: QTBUG-67986 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Fix incorrect behavior of PathView with ungrabMouse()Shin-ichi Okada2019-12-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | When the grabbed Item is released and then grabbed again, if ungrabMouse () is called, the animation stops. In order to avoid this, when ungrabMouse () is called, if offset is different, it is modified to animate. Task-number: QTBUG-79592 Change-Id: I61cbd4dad90643722f12480f0dab3859ce116af8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 16:06:19 +0000