aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/controls
Commit message (Collapse)AuthorAgeFilesLines
* QQuickToolTip: fix setTimeout() behavior when tool tip is visibleKonstantin Ritt2019-09-271-0/+9
| | | | | | | by applying the passed timeout value prior to re-starting the timer Change-Id: I27953dbb4781b5cb0c2039d56faa56f3c000206f Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Tumbler: fix displacement calculation when wrap is falseMitch Curtis2019-09-241-3/+24
| | | | | | | | | | | | Use the position of the item and the currentItem in the calculation in order to get reliable results. This fixes the displacement being off by a small margin, which increased as the delegate height became smaller. Fixes: QTBUG-66799 Change-Id: Ieca5033fb4c0ed62f5965a21fcab7aa558bd40e6 Reviewed-by: Andy Shaw <andy.shaw@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TextArea: prevent changing size of background recursivelyKonstantin Ritt2019-09-191-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the x/y position of background depends on the height/width of background and these values are not constant, the if statement in the method resizeBackground() will always pass. And since `resizingBackground` guard wasn't checked, any geometry change will always call resizeBackground() and then call themself recursively (via the change listener), that means the height/width of background will always be reset, no matter what value you set. Another part of the issue was in determining the extra bits too late: in case the background gets parented by the flickable, the new child caused the flickable to re-calculate its metrics and thus resize the background *prior* to remembering if it has w/h set. As a side effect, this fix also brings the possibility to reset previously set w/h to get the default background sizing behavior. Inspired by da06da57002b64cf4bcde0ca708b3275a5f919ae [ChangeLog][QtQuick][QQuickTextArea] prevent changing size of background recursively in construction Fixes: QTBUG-76369 Change-Id: Ide51ec1ebab63605ae3bfcc10a76a28be960ef36 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-09-081-1/+7
|\ | | | | | | Change-Id: Ifa88045268cdaa1adc0b1e206d5e20a3721d3837
| * QQuickIcon: properly resolve implicit valuesKonstantin Ritt2019-09-061-1/+7
| | | | | | | | | | | | | | | | when the property has not been set explicitly, the resolved mask must not contain a respective bit set either Change-Id: Iab0bd600b5bf458e26ed4601d4d2f608021f1518 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | tst_dial: fix copy-paste mistakeMitch Curtis2019-09-061-9/+9
| | | | | | | | | | | | | | Slider was incorrectly used in a03b6fec6. Change-Id: Ib76172f9ea0dca3b776a74df2329bd63c72f8517 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-07-043-0/+110
|\| | | | | | | | | | | | | | | Conflicts: .qmake.conf tests/auto/accessibility/tst_accessibility.cpp Change-Id: I0bc187e2a8edb4e357c1bf114dd9b1977d5c1e45
| * Add a test for having a ShaderEffect as a delegateJan Arve Sæther2019-05-221-0/+58
| | | | | | | | | | | | Change-Id: If4f3dca99638015b479509e4aa73e0190b1182ac Task-number: QTBUG-67343 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * Don't unnecessarily transform keysequences into stringsUlf Hermann2019-05-161-0/+29
| | | | | | | | | | | | | | | | | | | | | | Otherwise we cannot interpret them as the original key sequence anymore. When passing them on they are interpreted as the number key that represents the numeric value of the key sequence enum. Change-Id: Idd94ef95bc693cb6d51162dd1994adc953b52e25 Fixes: QTBUG-75572 Reviewed-by: Henning Gründl <henning.gruendl@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * Container: Keep currentIndex at 0 when removing item 0 if possibleJüri Valdmann2019-05-071-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Current behavior is to always decrement the currentIndex when the current item is removed -- even when the current item is item 0. This means, for example, that in a TabBar with three tabs and the first tab selected closing the first tab will leave nothing at all selected. Change behavior to keep currentIndex at 0 if there are still items left in the container. Now closing the first tab will leave the next remaining tab selected. Change-Id: If4e1903366e29fcee8226b776d5b2e03cec189df Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | SplitView: fix preferredHeight not being restored in restoreState()Mitch Curtis2019-06-101-5/+13
| | | | | | | | | | Change-Id: Icc236494f5df382d6bc49092d23a460822c835a1 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13v5.13.0-beta3Qt Forward Merge Bot2019-04-132-0/+84
|\| | | | | | | Change-Id: Ice7d2ed56c85521a946b218d84087b255d3613ae
| * QQuickComboBox: don't hide popup if focusedAlberto Mardegan2019-04-101-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | The ComboBox popup should be closed when the ComboBox loses focus, but not if the control gaining focus is the popup itself. While all the styles implemented in this module implement the ComboBox popup as an unfocusable window and handle all the keyboard events in QQuickComboBox itself, the developer can choose to replace the popup with a custom implementation, which might need the keyboard focus. Fixes: QTBUG-74661 Change-Id: I838ab9cb697df63ea2099e68f1ae99eadb06be08 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * SpinBox: fix indicators being hovered when mouse is moved while pressedMitch Curtis2019-04-081-0/+33
| | | | | | | | | | | | | | | | | | | | | | We also need to update the hovered state of each indicator when the mouse is moved while pressed, not just when we get hover move events. Change-Id: I6fa71344fd540f648683958e5804ae735523e72d Fixes: QTBUG-74688 Reviewed-by: Henning Gründl <henning.gruendl@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13v5.13.0-beta2Qt Forward Merge Bot2019-04-062-33/+24
|\| | | | | | | Change-Id: I5b112e0e4021191c387da86bb5b0477fe0c4da30
| * tst_dialogbuttonbox.qml: consolidate two similar testsMitch Curtis2019-03-291-24/+11
| | | | | | | | | | | | | | into one data-driven one. Change-Id: I7507765747dd984530e50df5cd08152b9d71cb66 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * tst_dialogbuttonbox.qml: use tryVerify() consistently to avoid flakinessMitch Curtis2019-03-291-8/+12
| | | | | | | | | | | | Change-Id: Ic18cca692b09f55818b9c99379aae4be72ba4159 Fixes: QTBUG-74711 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * Attempt to stabilize Tumbler::test_itemsCorrectlyPositionedMitch Curtis2019-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | I'm not sure if this will help (because I haven't been able to reproduce the flakiness, even in a CI VM), but the tumbler should really not still be spinning after we got the position of its items, so make sure it's stopped before doing any comparisons. Task-number: QTBUG-70597 Change-Id: I72555747b2ea4ef136cdaa13f7b0757be2624e73 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-271-0/+29
|\| | | | | | | | | | | | | Conflicts: .qmake.conf Change-Id: I37f9f88a11946d5d67935c682273eb0aa8593f9b
| * DialogButtonBox: don't sort buttons based on their memory addressesMitch Curtis2019-03-221-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When two buttons' roles are equal, the code would fall back to comparing the buttons' memory addresses. This leads to random results, which are especially noticeable on Windows and with release builds. This patch fixes the issue by instead returning false if the roles are equal. This still satisfies the "comp(a,a)==false" requirement of strict weak ordering: https://en.cppreference.com/w/cpp/named_req/Compare The patch also changes the sorting algorithm used from std::sort() to std::stable_sort(). Although it doesn't appear to be necessary from the testing that I did, it is good to ensure that the order of equal elements is maintained. Fixes: QTBUG-70451 Change-Id: I47561604108b12bf8ec0c794a2372767f0b2e04e Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-161-2/+134
|\| | | | | | | Change-Id: If27c142786ad2457a80ce1ef65220834eda81e94
| * Fix DialogButtonBox content size calculationMitch Curtis2019-03-151-2/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some history: - f1f884d3 worked around an issue in DialogButtonBox. - c2fd8f7d fixed it by using contentWidth; i.e. the implicit width of the contentItem. It caused QTBUG-72372. - I tried to fix QTBUG-72372 with 6476de0b, but created (or exposed) QTBUG-73860. The problem in QTBUG-73860 can be seen with the following example: Dialog { id: dialog visible: true standardButtons: Dialog.Ok } The single 'Ok' button here will go outside of the dialog. The underlying issue can be seen by looking into DialogButtonBox.qml: implicitWidth: Math.max(implicitBackgroundWidth + leftInset + rightInset, (control.count === 1 ? contentWidth * 2 : contentWidth) + leftPadding + rightPadding) implicitHeight: Math.max(implicitBackgroundHeight + topInset + bottomInset, contentHeight + topPadding + bottomPadding) The implicit width of the box in this case is contentWidth * 2 (there is one button, so control.count === 1). This should result in the button taking half the width of the box and being aligned to the right: alignment: count === 1 ? Qt.AlignRight : undefined ... delegate: Button { width: control.count === 1 ? control.availableWidth / 2 : undefined } What actually happens is that the contentItem (ListView) is temporarily 0 until it gets its final size of 100. However, QQuickDialogButtonBox doesn't respond to this change in the ListView's contentWidth. This problem can be fixed by returning to c2fd8f7d's resizeContent() implementation, which uses contentWidth. Then, there is a second issue: Dialog { id: dialog visible: true standardButtons: Dialog.Ok width: 300 } The button here is also positioned outside of the box. The problem is that the contentWidth is based on implicitContentWidth: QQuickContainerPrivate::updateContentWidth() { // ... contentWidth = implicitContentWidth; // ... } implicitContentWidth is calculated by calling getContentWidth(): void QQuickControlPrivate::updateImplicitContentWidth() { // ... implicitContentWidth = getContentWidth(); // ... } In the case of horizontal alignment, QQuickDialogButtonBoxPrivate::getContentWidth() uses the implicit width of the largest button: for (int i = 0; i < count; ++i) { QQuickItem *item = q->itemAt(i); if (item) { totalWidth += item->implicitWidth(); maxWidth = qMax(maxWidth, item->implicitWidth()); } } // ... if ((alignment & Qt::AlignHorizontal_Mask) == 0) totalWidth = qMax(totalWidth, count * maxWidth + totalSpacing); The Default style button has an implicitWidth of 100. The DialogButtonBox in the example above is 300 pixels wide, so the button should be 150, and it is, thanks to its width binding. However, the DialogButtonBox uses contentWidth to size its contentItem (ListView), and the contentWidth is, as mentioned, 100: the implicit width of the button. So, the button ends up hanging over the side of the box, as it's larger than the box thinks it is. This problem is fixed by setting DialogButtonBox's contentWidth to the contentWidth of the contentItem (ListView). This makes DialogButtonBox use the explicit widths of the buttons rather than their implicit widths. Since the contentWidth is no longer implicit, we must also change any use of contentWidth in the implicitWidth binding to implicitContentWidth. While writing auto tests for this, they caught an issue where contentWidth wasn't updated, so now we call resizeContent() in QQuickContainer::setContentWidth(). Change-Id: I99ffda21b47aeb14d4382e453e87c4312f343a1c Fixes: QTBUG-72886 Fixes: QTBUG-73860 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Fix SplitView crash when using certain attached propertiesv5.13.0-beta1Mitch Curtis2019-03-111-7/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the attached property object was created on an item that SplitView doesn't manage, then its m_splitView member will be null, so check for that. Sometimes, an attached SplitView object will be created on an item that SplitView _does_ manage, but SplitView's own contentItem hasn't been created yet (see the comment in the QQuickSplitViewAttached constructor). In that case the SplitView will see the item added as a child of its contentItem eventually, and we just have to wait. While we are waiting, check access to our members in case they are null. Fixes: QTBUG-74276 Change-Id: I70b7f017e621e0d15c239b962f0407743eb70b15 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-092-0/+154
|\| | | | | | | Change-Id: I34009799fe4016339920a7f0884af4dbe6d71418
| * Fix attached ToolTips using the timeout of the last shown tool tipMitch Curtis2019-03-081-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attached ToolTips share a single ToolTip item and set properties (such as delay) on it before showing it. Before 63899f3185, this wasn't a problem, but now QQuickToolTip has its own show() function that QQuickToolTipAttached calls. QQuickToolTipAttached passes -1 by default, which QQuickToolTip sees as the "default" and hence doesn't set a timeout at all. However, since that QQuickToolTip instance is shared, it still has a previous timeout value from the last time it was shown by a different QQuickToolTipAttached object. So, instead of QQuickToolTipAttached passing the timeout to QQuickToolTip::show(), make it set it on the QQuickToolTip instead. This ensures that it has the correct value if no timeout was specified for an attached tool tip. Task-number: QTBUG-74226 Change-Id: Iceed17bbb640a929fae3b9c975519df36cc2d210 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
| * QQuickScrollView: respect the content size set on/by the flickableRichard Moe Gustavsen2019-03-051-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the flickable inside a scrollview has an explicit content size assigned, or if the flickable was created by the application, then don't fall back to calculate the content size. The reason is that it should not try to change the content size of a flickable that is controlled by the application (or by the flickable itself, in the case of ListView, ScrollView and TextArea). Sometimes e.g ListView will report a negative contentWidth, which is not considered illegal. From before we used to just check if the child flickable had a negative content size, and if so, take that as a evidence that the flickable was owned by the scrollview. But with this patch, we instead add two extra variables that keeps explicit track of whether or not we should read the content size from the flickable, regardless of the values it might return. With the two new variables, we also no longer need the "ownsFlickable" property, as we can instead use the new variables to check for the same. Fixes: QTBUG-72536 Fixes: QTBUG-74000 Fixes: QTBUG-72940 Change-Id: Iec87cc953557bf8c1bdb32a3c11b721c607fc19a Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | SplitView: fix revisions, imports and \since versionsMitch Curtis2019-03-074-10/+10
| | | | | | | | | | | | | | | | Work was probably started before 5.12 but the patch ended up getting merged in time for 5.13. It seems that I forgot to update the versions. Change-Id: I19edf08158cca0967a7a536b3aee326e3b393d4c Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13v5.13.0-alpha1Qt Forward Merge Bot2019-02-021-0/+16
|\| | | | | | | Change-Id: I13c6458d7a7f92daf58c12e4c120d99a1f56cbfa
| * QQuickAbstractButton: fix clicked() not being emitted after long pressMitch Curtis2019-01-231-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a button is pressed long enough (QStyleHints::mousePressAndHoldInterval()) and there is a connection (e.g. signal handler) to the pressAndHold() signal, it is emitted. If nothing is connected to the signal, clicked() is emitted. Before this patch, QQuickAbstractButton used QObjectPrivate::isSignalConnected() to check whether or not anything was connected to pressAndHold(). The problem with this function is described by Olivier: "[...] there is an optimisation for the first 64 signals we store a bit in a 64bit integer to quickly see if a signal is connected. There is also the problem that it can return true even if the signal has been disconnected." This is also mentioned in a comment in the code: Returns \c true if the signal with index \a signal_index from object \a sender is connected. Signals with indices above a certain range are always considered connected (see connectedSignals in QObjectPrivate). When 5adce04 added inset signals to QQuickControl, it meant that signals in QQuickAbstractButton (which derives from QQuickControl) were pushed outside of that 64 signal range, resulting in the IS_SIGNAL_CONNECTED macro returning true. This patch fixes the issue by using QObject::isSignalConnected(), which does not use the 64 signal optimization. Fixes: QTBUG-72811 Change-Id: Ic6e54d6cab062e528522ef7e3cf27c1023d31347 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into devLiang Qi2019-01-1058-123/+237
|\| | | | | | | | | | | | | | | Conflicts: .qmake.conf src/imports/controls/qtquickcontrols2plugin.cpp Change-Id: I27f1260b539354e084beb28be78385e57fda63e1
| * DialogButtonBox: fix issue where single button would go outside boxMitch Curtis2019-01-081-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | c2fd8f7d made the following changes to the geometry calculation of QQuickDialogButtonBox's contentItem: @@ -244,11 +252,8 @@ void QQuickDialogButtonBoxPrivate::resizeContent() return; QRectF geometry = q->boundingRect().adjusted(q->leftPadding(), q->topPadding(), -q->rightPadding(), -q->bottomPadding()); - if (alignment != 0) { - qreal cw = (alignment & Qt::AlignHorizontal_Mask) == 0 ? q->availableWidth() : contentItem->property("contentWidth").toReal(); - qreal ch = (alignment & Qt::AlignVertical_Mask) == 0 ? q->availableHeight() : contentItem->property("contentHeight").toReal(); - geometry = alignedRect(q->isMirrored() ? Qt::RightToLeft : Qt::LeftToRight, alignment, QSizeF(cw, ch), geometry); - } + if (alignment != 0) + geometry = alignedRect(q->isMirrored() ? Qt::RightToLeft : Qt::LeftToRight, alignment, QSizeF(contentWidth, contentHeight), geometry); It turns out that this breaks the use case of a fixed width box (e.g. where a Dialog is assigned a width of 400 and the box assumes that width) with a single button. For example, in the case of the Default style, QQuickDialogButtonBox::contentWidth is 100 because Button's implicitWidth is 100. Since contentWidth is "used for calculating the total implicit width" of the box, it's not useful for positioning items which have an explicit width. The result is that QQuickDialogButtonBox thinks the contentItem is smaller than it really is, and therefore the ListView is positioned too far to the right. Only the Default and Universal styles are affected, as they are the only styles that resize the button to cover half of the button box. This patch fixes the issue by reverting the code above to its original state, where the content size of the contentItem is used instead of the contentWidth of the box. Change-Id: Idd2f94f3b4d3413fc2057c0ade2efdd66d701c08 Fixes: QTBUG-72372 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * Slider: fix wheel event propagationMassimo Callegari2019-01-081-0/+57
| | | | | | | | | | | | | | | | | | Don't propagate wheel events when reaching the limits. Sync the behavior with Qt widgets and SpinBox/ComboBox. Task-number: QTBUG-72750 Change-Id: Iefb8562c1d9632badc4a39bc4c301bd96b8a515b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * Fix TextField background not respecting control's widthMitch Curtis2018-12-211-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After 6858d4e9, the background of the Material style TextField does not respect the width of the control if the control is resized (e.g. due to being in a layout). - The first time resizeBackground() is called, !extra.isAllocated() returns true - that is, extra has not been allocated yet. - The if statement is executed and the background's width is set to the available width of the control (e.g. 120). - As a result of the background's width being set, its widthValid flag is set to true. This would previously be undone directly afterwards by setting widthValid flag to false. - In the case of the test case, the implicitWidth was already 120, so geometryChanged is not emitted. However, when the height of the background is set, this *does* cause itemGeometryChanged() to be called, which in turn does the following: extra.value().hasBackgroundWidth = p->widthValid; extra.value().hasBackgroundHeight = p->heightValid; resizeBackground(); So now all of the following checks evaluate to false: (!p->widthValid || !extra.isAllocated() || !extra->hasBackgroundWidth) This prevents the background from being resized. This patch fixes the issue by unsetting the widthValid (and heightValid) flags of the background directly after setting its width. To be safe, it also only unsets it if we were the ones to set it. By doing this, the check mentioned above succeeds because p->widthValid and extra->hasBackgroundWidth are both now false. It also adds some extra safety into itemGeometryChanged() that ensures that extra.value().hasBackgroundWidth is only set if necessary, and therefore prevents the extra data from unnecessarily being allocated. This is not necessary for the fix, but feels like the right thing to do. Change-Id: I051e281718bd8a2a20c100767d929fb71497ce1b Fixes: QTBUG-71875 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * Merge remote-tracking branch 'origin/5.12.0' into 5.12Qt Forward Merge Bot2018-12-0558-123/+136
| |\ | | | | | | | | | Change-Id: I7fe9e74beff3cdbfbf02ee0f129a8204ad31046e
| | * QQuickPage: fix a typo to avoid a crashLiang Qi2018-11-091-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | when setting null to footer Fixes: QTBUG-71444 Change-Id: Id4b0a3fd7aa104357674b4e2be6206894f8878da Reviewed-by: J-P Nurmi <jpnurmi@gmail.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| | * Tie minor version of all imports to Qt's minor versionMitch Curtis2018-11-0258-123/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes all Qt Quick Controls 2 imports match the current Qt minor version, which is 12 as of this patch. It also updates all other Qt Quick imports to match. This will also make future version bumps easier as all version numbers in existing code/docs will match. The following commands were used to verify that no old versions remain: for i in `seq 0 11`; do git grep "import QtGraphicalEffects.*1.$i$"; done for i in `seq 0 11`; do git grep "import QtQuick 2.$i$"; done for i in `seq 0 11`; do git grep "import QtQuick.Layouts 1.$i$"; done for i in `seq 0 5`; do git grep "import QtQuick.Controls.*2.$i$"; done for i in `seq 0 11`; do git grep "import QtQuick.Templates 2.$i as T$"; done [ChangeLog] From Qt 5.12 onwards, all import versions in Qt Quick Controls 2 follow the same minor version as Qt's minor version number. For example, the import version for Qt 5.12 is: "import QtQuick.Controls 2.12". Change-Id: I6d87573f20912e041d9c3b7c773cc7bf7b152ec3 Fixes: QTBUG-71095 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | SplitView: schedule another layout if requested sizes changed during layoutMitch Curtis2019-01-081-0/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in the review of ed87e837, there could be a scenario where the user sets the preferred size of an item inside the onWidthChanged handler of another item: onWidthChanged: if (width < 10) secondItem.SplitView.preferredWidth = 100 Before this patch, this would result in the preferredWidth assignment being ignored since it happened during a layout. This patch adds some auto tests to ensure that this works, as the previous patch (that converted layouts to be done in polish/updatePolish cycles) already fixed the issue. It also adds a check to avoid doing too many layouts in the case of one of the split handles being dragged. Change-Id: Ide519b33a2fa3bf746ae3793e0671fd1750c70d8 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | | SplitView: batch layout requests via polish()/updatePolish()Mitch Curtis2019-01-081-1/+48
| | | | | | | | | | | | | | | | | | | | | | | | This results in less layouts, especially when a bunch of properties change one after the other. Change-Id: I8dd76d147bcc20f2ccddb587e59ac3e59f580f21 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | | SplitView: react to changes in implicit size of split itemsMitch Curtis2018-12-051-0/+54
| | | | | | | | | | | | | | | Change-Id: Id81aac71f26ec9cbf643fdc480d76841d1e3be47 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | | Merge remote-tracking branch 'origin/5.12' into devQt Forward Merge Bot2018-12-041-0/+49
|\| | | | | | | | | | | Change-Id: I0d2601b897e4cb8ce7a0d562927f3895d1f08f25
| * | QQuickScrollView: override getContentWidth/Height()Richard Moe Gustavsen2018-11-271-0/+49
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A ScrollView lets you add the Flickable that should be decorated as a child. If that flickable has one (and only one) child, the contentWidth/Height properties of the ScrollView will be calculated by using the implicit size of that child (unless you assign something else to those properties explicitly). This logic goes wrong when the flickable is a TableView for several reasons. The first is that TableView will populate the content item dynamically, and for the first delegate item added, the content size of the ScrollView will be set to be the size of this item (since the TableView only got one child at that point). The second is that TableView has its own set of contentWidth/Height properties. And those properties are not respected by ScrollView. So even if TableView set the contentWidth/Height to be the size of the table, this will not be used by ScrollView. The result is that ScrollView concludes that the content item is empty, which means that no scrollbars end up visible or usable. This patch will fix this by overriding getContentWidth()/Height() from QQuickPane. The implementation will check if the flickable has valid contentWidth/Height values set, and if so, use them. Otherwise it will fall back to the old QQuickPane implementation (which will inspect the children etc). Fixes: QTBUG-71974 Change-Id: I027b9b939a10df2aeb816dea596adcb452f914b9 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: J-P Nurmi <jpnurmi@gmail.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add SplitViewMitch Curtis2018-11-134-0/+1981
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SplitView is an important tool for desktop applications that do not want to use a dock widget-style approach for their user interface. It allows users to have some degree of control over the sizing of elements in the UI, as well as the ability to conveniently serialize those sizes so that they're remembered across sessions. The main differences between this and the SplitView in Qt Quick Controls 1 are: - Has its own SplitView attached properties, rather than relying on the Layout attached properties (which required an additional import). - Uses the attached preferredWidth and preferredHeight properties as well as Item's implicitWidth/implicitHeight properties for the preferred size of items, rather than using the width and height properties. - Inherits from Container, so supports most of its API (though some parts of the API, like the currentIndex-related stuff, make no sense for SplitView). - Uses attached SplitHandle properties for the handle delegate to visualize hovered/pressed effects. - Offers convenience API for serializing the user's preferred sizes. [ChangeLog][Controls][SplitView] Introduced SplitView, a control that lays out items horizontally or vertically with a draggable splitter between each item. Task-number: QTBUG-56318 Change-Id: I3da91643ab312eb9ef5b0567da4e758f17747192 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Remove support for GPU_BLACKLIST files from some testsEdward Welbourne2018-10-125-5/+0
|/ | | | | | | The feature is no longer used and support for it shall soon be dropped. Change-Id: I9b35b43262b6f07609cf931315125e91e0a1f9b6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Merge remote-tracking branch 'origin/5.11' into 5.12Qt Forward Merge Bot2018-09-181-0/+3
|\ | | | | | | Change-Id: Ic5311418d3f25398380c4a32b35753329efb6f3f
| * Attempt to stabilise Popup::test_shortcut auto testMitch Curtis2018-09-121-0/+3
| | | | | | | | | | | | | | | | | | Ensure that the window is active before trying to activate keyboard shortcuts. Task-number: QTBUG-70413 Change-Id: Ibac1526efd9c53f1f2aa3401da3855ce26d35d6a Reviewed-by: Liang Qi <liang.qi@qt.io>
* | Extend opensuse blacklisting to opensuse-leapTony Sarajärvi2018-09-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | In openSUSE 15.0 /etc/os-release the ID of the OS was changed from "opensuse" to "opensuse-leap". So every blacklisting we did for opensuse, didn't cover opensuse-leap. This one adds opensuse-leap as a blacklisted platform whenever opensuse was blacklisted. Task-number: QTBUG-70413 Change-Id: Ib84cda329160d4cfed28cb168f380269c24f8435 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | Fix blacklist syntax of Popup::test_shortcutTony Sarajärvi2018-09-071-1/+1
| | | | | | | | | | | | Task-number: QTBUG-70413 Change-Id: Ie4ae23a7869bb0cbb41f452637ccf55c58b24182 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | Blacklist flaky Popup::test_shortcut on openSUSETony Sarajärvi2018-09-061-0/+2
| | | | | | | | | | | | Task-number: QTBUG-70413 Change-Id: I86b6d4924b6042b9d934bf3f15901eb9a8a6c7f5 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-07-171-7/+1
|\| | | | | | | | | | | | | | | | | Conflicts: src/quickcontrols2/qquickstyle.cpp src/quicktemplates2/qquickscrollview.cpp tests/auto/qquickstyle/tst_qquickstyle.cpp Change-Id: I9afddf07a956f43cf0445e91b8d1a02f167b6bd5
| * tst_tumbler: replace loop with tryVerify()Mitch Curtis2018-07-031-7/+1
| | | | | | | | | | | | | | 'cause it's better. Change-Id: I00a538013a10a7ff3b551b9f550427f898610dbb Reviewed-by: Liang Qi <liang.qi@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 04:04:29 +0000