| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
In order to achieve this, it separates out QQuickSpinButton into a
separate file (and renames it since it's not only purposed for SpinBox
anymore). This allows it to be also used by QQuickScrollBar.
Fixes: QTBUG-88115
Pick-to: 6.0
Change-Id: I2dea42b29750b7bc619031f40a43717fc10c177b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
| |
Prevent it from cluttering the settings directory
with a "Qt Project" directory.
Pick-to: 6.0
Change-Id: Ic774852a76eb94073abd937cb65b28fa9e544837
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Since we only depend on using setFamilies() now instead of setFamily()
then we can rely on the fact that it will be resolved correctly, so we
can remove the code that was ensuring that family() would take
precedence if families() was empty.
Change-Id: Iea1464ec840dc76c04a4acae445cab367e03d3ca
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
Fixes: QTBUG-88038
Fixes: QTBUG-88138
Change-Id: Id16f741675016b681aae7d306909be9a5c5ff168
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
| |
Change-Id: Id16f972a7f2c0f3c9c9d2fe1d14b9e0830a85a0a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following 72e0d699cec09458ca9325035d477d4899e8e47b in qtbase, the model
tester exercises additional code paths to verify correct row/columnCount
implementations for flat models.
This revealed a few bugs in the models used in QQuickHeaderView and the
unit test:
* neither QHeaderDataProxyModel nor the test models handled a valid
parent index for calls to row/columnCount
* QHeaderDataProxyModel::sibling passed the index on as parent
Change-Id: I612e18030d837275614d61ce8987c93fff7f20a9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
This has a long history of being flaky. Until we decide what to do with
it, blacklist it to unblock CI.
Task-number: QTBUG-70597
Change-Id: Ic115a345662fc61464065d678720c88597181d98
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Unblock CI until these can be fixed properly.
Task-number: QTBUG-88038
Change-Id: Ie7520e30a7df4b554ceba6411b88d2249ffbce5d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: I47dcf16b1d207317985e303c626a121aa307704c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: If89dcf833f9dbf09f8b3a558ce441dc1c21499ce
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A control should have been pressed if it's going to accept a release.
This prevents an issue where a menu opened by pressing enter (handled
via attached Keys property) would instantly trigger the first menu
item.
Pick-to: 5.15 5.12
Fixes: QTBUG-83698
Change-Id: I6b1afbb76f37623012472b2b1148b4862c159239
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-87037
Change-Id: Iaf92dd98f616628bf1d6d692847fbdf3138119fe
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
| |
Change-Id: I3042ad7543eefa3153db0e9eee1ae9186f7011d1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
8b534487044dfb3b464431ecb91ef4e0864af4ed made it so that the most
appropriate built-in style is chosen by default is no style is
specified. This breaks tests that assume the old behavior is still in
place.
Fix those tests to explicitly set the Basic style.
Task-number: QTBUG-86403
Change-Id: I6a51611741e2d0cb9109bb0221c2214a5c5179df
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
| |
Modify special case locations to use the new API as well.
Task-number: QTBUG-86815
Change-Id: I4a690095fcd4b1141550de86b6820ae2dd579429
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit changes the how the default style is set, and since
the tests all assumed that Basic was the default, we now need to
ensure it is explicitly set.
If we want to, we can revert this patch (or file-by-file) later and
ensure that these tests work with all styles. For now, just keep things
working as they used to.
Tests that use QTEST_QUICKCONTROLS_MAIN are not changed, as they
already run with all built-in styles.
Tests that don't use types that will cause issues,
like tst_qquickcolor, do not need to be changed.
tst_snippets can be run manually to produce screenshots, so we specify its
style in a qtquickcontrols2.conf file to allow it to be overridden by e.g.
application arguments (QQuickStyle::setStyle() takes precedence over all
other approaches of setting a style).
Change-Id: Ifae7e959f89a41a757c170272038fad139bba04f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ChangeLog][Styles] An appropriate built-in style is now used as the
default style if one is available for the target platform. For example,
when running a Qt Quick Controls application on macOS, the macOS style
will be used. On Android, the Material style will be used. When running
on e.g. an embedded device, where no native style is available, use the
Basic (formerly "Default") style.
Change-Id: Ie61d1a8a1a83fbeba63387c7ca3671084f47bc04
Fixes: QTBUG-86403
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
| |
Use the actual type name instead of "type".
Change-Id: I081e226a2a6cda1dd5e5cf976629ceb63a9b8db1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
| |
This passes for me locally on both macOS and Linux.
Task-number: QTBUG-87018
Change-Id: I2d5f27f3f18e8c419485beb1714515b86723bb08
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
cd669f1f216e54fa59eee77459d608a41f5df290 fixed these tests,
but I forgot to unblacklist them in that patch.
Task-number: QTBUG-87018
Change-Id: I50b4f571eb9b231449e320ad90da3a9d4ae59a88
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
Unlike the other functions, the x and y parameters do not currently
default to the center of the control if unspecified.
Change-Id: Ie6c5945c0b43f1ef0d79e76a96da18ea102a50e2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
So that we can unblock CI.
The failures need more time to be looked into.
Task-number: QTBUG-87018
Change-Id: I350a4100011127588077edecb73ae11078100940
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Amends 6115585477bea66d90acbbd8a25b898d121bd50e
Task-number: QTBUG-87018
Change-Id: I3c742bd8fc593f4d3a4f33104e708344fdafe3ec
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-86815
Change-Id: Ie0688d13b1787da3c1fc241a7d864aa014ca1d70
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By allowing importing styles without first importing QtQuick.Controls,
which does runtime style selection.
[ChangeLog][Styles] It's now possible to select a style at compile-time
by importing that style explicitly instead of QtQuick.Controls. This
avoids the need to do run-time style selection and hence deploy the
QtQuick.Controls plugin with the application.
Change-Id: I666d6dc7727fffd2c7b05743855f2086f076465a
Fixes: QTBUG-86284
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ChangeLog][Styles] The Default style was renamed to Basic to account
for the introduction of the platform styles (macOS, Windows), which
will be used by default (where possible) when no style is specified.
Fixes: QTBUG-85984
Task-number: QTBUG-68814
Task-number: QTBUG-86403
Change-Id: I22b3199c8662e4ee5d55a1be1a51c9856ac62376
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Qt 5, QtQuickControls2Plugin::registerTypes() was responsible for
calling initializeTheme() on each style plugin. Now that we delegate
more work to the QML engine, each style plugin calls initializeTheme()
via registerTypes().
To avoid fallback styles overwriting font and palette data set by the
current style, we need to check if the theme has been intialized before
calling initializeTheme(). To do this, we add a static
"themeInitialized" bool that QQuickStylePlugin sets to true after
calling intializeTheme() for the first time. It checks this value and
avoids calling intializeTheme() if it's true.
We also need to make QQuickStylePlugin ensure that the theme it's
initializing belongs to the current style.
Fixes: QTBUG-86303
Change-Id: Ie65e646677c78622829f4949c41cb79204cf5786
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
| |
Also cleanup documentation, with the exception of the "High-DPI
Support in Qt Quick Controls" page, which needs to be either
removed or rewritten after some fact checking.
Change-Id: I3cdf1f8554f8f26627a9a5f17c2ee0038c933468
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
AA_DisableHighDpiScaling and AA_UseHighDpiPixmaps have been deprecated.
As of 90358f6042d1fe2db849e17e1b0c875fb0560b20
and 2dc46c09026362cc267b1183faf09fb29479ef93 in qtbase, respectively,
these settings are deprecated and have no effect.
Change-Id: I1eb1f77a64893dd077bd08216d26633d43e1e0e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This amends 1a5a0a591c35dcf498a232a802087683f2244ecb so that it only sets
the hadActiveFocusBeforeExitTransition variable if it is false, ensuring
that it is correctly handled later on if it is true from before. This
handles a case of closing, opening and then closing again in one function
call.
Pick-to: 5.15
Task-number: QTBUG-85884
Change-Id: Ied4ca33045b005f5f666e63d85fb603e9350d982
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the inputted value is out of range but it would be fixed to the
previous value then it would not update the text correctly to show the
corrected value. This ensures that it is updated as appropriate.
Before it would check if the value had actually changed after it had
been fixed to the corrected value. So if it was corrected to the
original value then it would not see it as having changed. Additionally
the displayText also has the original text before the change, so we
have to force through an update to ensure the contentItem's text is
updated too.
Change-Id: Ic38787d0803ab59cd998f4e2871c613f1642e764
Pick-to: 5.15
Fixes: QTBUG-85719
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
| |
This ensures that we received the warning we expect in
tst_StyleImports::importStyleWithoutControls when run with native styles.
Change-Id: I290f4e72222688e68ae36ace36f1d8be4bedaf31
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
| |
Not all styles will have a specific version, so don't specify it.
Change-Id: I92f020314d76934f286ca2946e994e2d1c5d37e5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Set the default width of an empty TextField to 90px (which
is a number found by creating an NSTextField in XCode
and measuring it with pixeltool). This should also make
tst_QQuickPopup::macOS::cursorShape() pass.
Change-Id: Ia2a059668c2e1eaea3eef20015a8ea99468dd8ad
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|\ |
|
| |\
| | |
| | |
| | | |
Change-Id: I18a4fd46cf13c65fe6f4c3981b7c61ab52109b8d
|
| | |\
| | | |
| | | |
| | | | |
Change-Id: I9999194551f71abec3731355cd746e69e2e0b187
|
| | |\ \
| | | | |
| | | | |
| | | | | |
Change-Id: I5375ecd1dcbc058806e34fce757df2bf30dac16e
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is how the macOS platform behaves. This will cause a slight
behavior change for all Qt Quick Controls 2 styles on macOS, as
reflected by the change in autotests.
Change-Id: I9ea744737d0d157ee8c83955f718c1cd889a8c1d
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I don't know why this is necessary, but without it, the mouse area
doesn't get any mouse events on subsequent runs (tested with
QT_LOGGING_RULES=qt.quick.mouse=true).
Change-Id: I69fa13ad282789f522542e52a945973fee66f44d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem is that QtQuick.Controls.macos is only
available with revision 6.0. And when importing e.g
QtQuick.Controls 2.15, we try to load a style with the
same revision. But it simply doesn't exist. So remove
all versioning from the tests to also support testing
newer styles.
Change-Id: I666a93ab03ec4c5dcf2055a363547f8cdac8d25e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The included test fails every now and then for Imagine, Fusion
and Mac style. By using QTRY_VERIFY to wait a bit before we check
if the menu is highlighted, it seems to pass each time.
Change-Id: Ib8b207e1b5f81b3086595bb8ad7dc6881272def1
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Change-Id: I1cb364046a35eac277ad08268b22851a6147d8c8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before this patch, the documentation stated the following for e.g.
accept():
"Closes the dialog and emits the accepted() signal."
In practice, styles that have enter and/or exit transitions for Dialog
result in closed() being emitted after accepted() (and rejected()).
As there is no way to guarantee this particular order, we should be
consistent and swap it around so that accepted()/rejected() are emitted
first.
[ChangeLog][Important Behavior Changes] Dialog's accepted() and
rejected() signals are now emitted before closed() when calling done(),
accept() and reject().
Fixes: QTBUG-85748
Change-Id: I706dda8de28c350d65e3188787af8f66a2c5f07d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The old sequence of events was:
1. setVisible(true) (enter transition begins)
2. startTimeout()
3. opened() (enter transition ends)
4. time out elapses (exit transition begins)
5. closed() (exit transition ends)
In most cases, a timeout would be longer than an enter transition,
so the only (barely) noticeable issue would be a slightly quicker
timeout than what was set. However, if the timeout was shorter than the
enter transition, then the sequence would be:
1. setVisible(true) (enter transition begins)
2. startTimeout()
3. time out elapses (exit transition begins)
4. closed() (exit transition ends)
This can result in the enter transition being interrupted and
the tooltip never being properly visible.
Avoid this by only starting the timeout when opened() has been
emitted. This also brings the behavior in line with what would
be expected when reading the documentation.
[ChangeLog][Important Behavior Changes] ToolTip's timeout now begins
only after opened() has been emitted. This bug fix results in tooltips
with enter transitions being visible for the entire duration of the
timeout property. This means that they are visible slightly longer than
they were before, so it may be worthwhile to visually check tooltips in
your application and adjust timeouts if necessary.
Fixes: QTBUG-82257
Change-Id: Iebad64a8cca1f328f9ce85aa78ea0f12918dadf1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise &mnemonic shortcut in the active menu would be stolen by one
of the ambiguous items shadowed by the active menu.
Fixes: QTBUG-86276
Pick-to: 5.15
Change-Id: I5a1caea60da937fef409720f1ca11b99045ed4b8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise tst_qquickmenubar of Material style would fail as follows:
1. Type Alt+E to open Edit menu
2. Type Alt+H to switch to Help menu
Since the key events of (2) are generated really quick, (2) wouldn't
open the Help menu. The Edit menu still exists in the popup stack and
blocks the MenuBar shortcuts.
I originally thought the closing popup shouldn't block the parent
shortcuts.
for (QQuickPopup *popup : popups) {
if (qobject_cast<QQuickToolTip *>(popup))
continue; // ignore tooltips (QTBUG-60492)
+ if (!popup->isOpened())
+ continue; // closing, or not yet fully open
However, the shortcuts in the closing popup are enabled until the popup
gets invisible. So changing the resolution of ambiguous shortcuts would
introduce another inconsistency. For example, unambiguous shortcut in
the closing popup could be triggered, whereas ambiguous one wouldn't win
because of the registration order.
Task-number: QTBUG-86276
Pick-to: 5.15
Change-Id: I3510cc7a06294e1d1d3512297fc9389bddc4da3b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is close to what the widget QMenu (and Windows native menu) do.
Before, the active menu was left open and Alt+<key> shortcut would be
delivered to one of the matching items, which might be an item shadowed
by the active menu popup.
With this patch, the active menu is closed on Alt key pressed so the
subsequent shortcut event will (likely) be delivered to the matching
MenuBar item. Since I'm going to fix the issue of &mnemonic key conflict
resolution, I need to first change the way of delivering a shortcut
event to the parent MenuBar.
The test cases use the undocumented function to simulate low-level
behavior of Alt itself and Alt+<key> events. Apparently, there's no
public QTest function to send multiple key events without releasing Alt
modifier.
Task-number: QTBUG-86276
Pick-to: 5.15
Change-Id: I0ed6ea94f0fee7983a5cb6352d388036d3a1f8df
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The following code
import QtQuick
import QtQuick.Controls.Material
ApplicationWindow {
width: 200
height: 200
visible: true
}
produced an error in Qt 5:
QQmlApplicationEngine failed to load component
qrc:/main.qml:4 ApplicationWindow is not a type
In Qt 6, the types are provided by the qmldir, so the import will work,
but as QtQuickControls2Plugin has not been loaded, there is no
QQuickTheme object yet, and so the style will not work as expected
(any colors, fonts, etc. from the theme will not be used by the
style).
Produce a warning for this scenario, and test each style to make sure
that we don't crash.
Fixes: QTBUG-86280
Change-Id: I99f940255f56da0522ad192ae5da4c9110ea308e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The paletteChanged signal was used as the change signal for a lot of
properties. The problem with this was this binding, for example:
Material.foreground: Material.toolTextColor
results in foreground being set, which emits paletteChanged.
toolTextColor has paletteChanged as its change signal, so that is
triggered and then the foreground binding is re-evaluated in the middle
of already being evaluated.
I haven't found a way to fix this for toolTextColor yet, so we
temporarily skip emission of toolTextColorChanged when foreground
changes. This means that some text will be the wrong color when
foreground is changed after startup.
For other properties, using more specific change handlers is enough
to solve any binding loops.
Task-number: QTBUG-85699
Pick-to: 5.15
Change-Id: Ied52d4c38914765ed5c75e234954f4baabaaa9af
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|