aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quickdialogs
Commit message (Collapse)AuthorAgeFilesLines
* Blacklist tst_QMessageDialogIm::resultReflectsLastStandardButtonPressedShawn Rutledge2025-11-171-0/+4
| | | | | | Task-number: QTBUG-142016 Change-Id: I50e435bd6343fddcee26973467b3029555c2f983 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* DialogButtonBox: add properties for setting a default buttonOliver Eftevaag2025-11-144-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Qt Quick Controls lacked the ability for setting a default button in a dialog button box. This is something that we support in QtWidgets, and it makes sense to allow dialogs with a DialogButtonBox set as the footer to decide if a particular button should be default, and have focus when the dialog is opened. With this patch, we're introducing two different ways for selecting a default button. The first is the usage of the DialogButtonBox::defaultButton property, which works like this: ``` DialogButtonBox { defaultButton: Button { text: qsTr("Ok") } Button { text: qsTr("Cancel") } } ``` In the snippet above, the Button that is set as default should both be highlighted, and be the sub focus item of the DialogButtonBox. However, since the standardButtons property can be used to dynamically create buttons on the fly, we also needed an alternative way for picking a default button. In cases where standardButtons is being used to create buttons in the DialogButtonBox, the new defaultStandardButton property can be used: ``` DialogButtonBox { standardButtons: DialogButtonBox.Yes | DialogButtonBox.No defaultStandardButton: DialogButtonBox.Yes } ``` Something worth noting, is that the DialogButtonBox's contentItem is typically a ListView. ListView have the ItemIsFocusScope flag set, meaning that we need to give focus to both the ListView, and the default Button. In addition, the FontDialog and ColorDialog will now make the Ok button default, and give it focus when the dialogs are opened. The FileDialog and FolderDialog will continue to give the ListView focus, since that's IMO more user friendly. The MessageDialog will need new API to take full advantage of this new feature, which will be introduced later. [ChangeLog][DialogButtonBox] The DialogButtonBox now has two new properties, defaultButton and defaultStandardButton. When one of these properties are being used, a button set as default will be highlighted and receive activeFocus whenever the DialogButtonBox gets focus. If a DialogButtonBox is assigned as a Dialog's footer, it will also get focus when the Dialog is opened. This means that a Dialog with a DialogButtonBox as its footer, will give focus to a default button when opened. If both of these properties are unset, the first button with the AcceptRole will get focus, but it will not be highlighted. Fixes: QTBUG-58246 Fixes: QTBUG-139352 Change-Id: Ic083410184dd63e0e790694f782a7a98c1dc8b6e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Run tst_qquickfiledialogimpl also with the Imagine styleOliver Eftevaag2025-10-241-0/+4
| | | | | | | | | | | The intention was always to run it with every single built-in style. Previously the Imagine style was omitted because of an issue that needed more investigation. It seems like that has since been resolved, and that it's safe to include it in the list of styles to run tst_qquickfiledialogimpl with. Change-Id: I7634a938c550392f8f5c18c141404c80a7ab99b2 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QuickStylePlugin::unregisterTypes(): cleanup selectors from global listOliver Eftevaag2025-10-061-5/+10
| | | | | | | | | | | | | | | | | | | | | | | File selectors may have been added in QQuickStylePlugin::registerTypes(). It makes sense to clean them up when a style plugin in unloaded, otherwise the first style that was loaded will always be prioritized, even if it was unloaded later on, during runtime. This change causes tst_qquickfiledialogimpl to acutally run with all styles (except Imagine). Originally I thought da777a75f65ad101e9b0bad7c098004c0a699b41 would work by itself, but it turns out that the test would run 4 times with the same style (Basic), instead of the intended Basic, Fusion, Material and Universal styles. By cleaning up old selectors, the test will now finally run will all the different styles. This caused some of the test functions to break. The Material style is infamous for having transitions for opening and closing popups. There were a few other functions too that broke for other reasons. Fixes for those functions are also included in this patch. Change-Id: I3c350b5e72454fccedbc2579db4813d953dfbb95 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fusion File&FolderDialog: Give the FolderBreadcrumbBar a maximum widthOliver Eftevaag2025-08-301-0/+28
| | | | | | | | | | | | | | | | | | | The fusion styled File and FolderDialog's FolderBreadcrumbBar would grow in width as the number of nested directories in the currentFolder path would grow. The other styles would give it a maximum size, which would limit how much it could grow, but not the fusion style. The FolderBreadcrumbBar's width also affects the entire FileDialog default (implicit) width, which would cause the entire dialog to expand as you'd enter more directores. This was unintuitive, and not something that any other file dialogs do. Let's make the fusion style FileDialog behave like the other FileDialogs. Pick-to: 6.10 Change-Id: Icd67803b6e205ac9224b2561417667b4893a4e87 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Run tst_qquickfiledialogimpl tests for multiple dialog stylesOliver Eftevaag2025-08-272-11/+8
| | | | | | | | | | | | | | | | | | | | | We were only testing the non-native file dialog under the Basic style previously, but we have 4 other styles (Fusion, Imagine, Material, Universal) that were never tested. This unfortunately caused recent regressions in both the FileDialog and FolderDialog. By running each test once for more styles, we should be better protected against future regressions in individual styles. In this patch, we enable all tests for Basic, Fusion, Material and Universal. The Imagine style is intentionally omitted due to a bug, which causes the tst_qquickfiledialogimpl::defaults() test to fail. This will be fixed later. Change-Id: I9b4ab722c5ad3052122024ad3a7a2f0a99de77e6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FileDialog: Use SplitView to separate the sidebar from the contentOliver Eftevaag2025-08-161-5/+13
| | | | | | | | | | | | | | | | | | | | | | Previously a RowLayout was being used. But I would argue that it's better UI to use a SplitView instead. Add the necessary overrides in QQuickSideBar, so that the SideBar actually knows it's correct implicit size. This is needed in order for the SplitView to work correctly. We want the implicit width to be large enough to cover the delegate with the most text, with a maximum width of half the available space in the dialog. As for the height, we want it to be tall enough to cover all the standard paths + add favorite button, so that the feature of adding directories to the favorite list is less cumbersome. The height of the sidebar should be part of what determines the implicit height of the dialog. Pick-to: 6.10 Change-Id: If267d8197e82f8a91a059e31723c46fe95af3d41 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* FileDialog: Fix binding loops for Fusion, Material and Universal stylesOliver Eftevaag2025-08-111-5/+1
| | | | | | | | | | | | | | | These binding loops were introduced in 0e4d470d3df3963db3546f94e580994473052283, since the nested overwriteConfirmationDialog's width were still determined by the contentItem, but the contentItem's width depended on the overwriteConfirmationDialog's width. This resulted in a binding loop, which could be fixed by giving the overwriteConfirmationDialog an explicit width. Pick-to: 6.10 Change-Id: I3bb2957fd31710b093eb7f7e887df8f045809921 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Propagate modality to the non-native quick dialogsSanthosh Kumar2025-07-0911-16/+507
| | | | | | | | | | | | | | | The non-native quick dialogs don't block input to the windows even after setting the modality as ApplicationModal/WindowModal. This is because non-native platform dialogs (QuickPlaform*Dialogs) didn't set modal to its respective window (QQuickPopupWindow). This patch fixes that issue by setting the modality to the non-native platform dialogs. Task-number: QTBUG-127605 Pick-to: 6.10 6.9 6.8 Change-Id: Idb3374e881766ae92adc0360c9b9af5c498dd6df Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Add missing call to beginResetModel()Even Oscar Andersen2025-06-172-0/+82
| | | | | | | | | | | | | | | QQuickFolderListModel::beginResetModel calls endResetModel automatically to avoid consequtive calls to beginResetModel. However, the same logic is not done for endResetModell. This triggers a endResetModel without a preceeding beginResetModel which (apparently) causes problems with updating the view contents in some cases. Fixes: QTBUG-134600 Pick-to: 6.8 6.9 6.10 Change-Id: I9fe3034b784d83ee2ed5b65bdad3a77545891bc2 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* tst_QQuickFile/FolderDialogImpl: use canonical pathsMitch Curtis2025-06-112-146/+186
| | | | | | | | | | | | | | | | | This adapts to 7bd7df5aa170c240061144a9210a13b62949935c. The test was expecting e.g. this path: /var/folders/0r/vd385j117f949qnfm4h_539w0000gn/T/tst_qquickfiledialogimpl-dqvSBE/sub-dir But the actual path was this: /private/var/folders/0r/vd385j117f949qnfm4h_539w0000gn/T/tst_qquickfiledialogimpl-dqvSBE/sub-dir Fixes: QTBUG-137416 Pick-to: 6.5 6.8 6.9 6.10 Change-Id: I31b929017ebb1a672a614f8b409dc5c4e8d5e000 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix quickdialog test compilation if draganddrop or listview is disabledJuha Vuolle2025-04-281-3/+5
| | | | | | | | | | | Headers like qquickplatformfolderdialog_p.h aren't part of build if these features are disabled. Use same condition to enable the tests as the needed headers have. Task-number: QTBUG-136101 Pick-to: 6.9 6.8 Change-Id: I898ed607b4c6ac540fecacceaac1f630e64d3167 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Indent quickdialogs CMakeLists.txt properlyJuha Vuolle2025-04-281-4/+4
| | | | | | | | | A pre-move to ease the review of followup commit Task-number: QTBUG-136101 Pick-to: 6.9 6.8 Change-Id: I48ee8d07ced33d510193cda71c142742d3b69e6d Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Set the current directory earlier in tst_QQuickFileDialogImplFrédéric Lefebvre2025-04-251-4/+4
| | | | | | | | | | | | | | | | | | | The temporary directory is set as the current directory at the end of iniTestCase. iniTestCase() returns earlier if the temporary directory is not empty and this code is never reached. Set the current directory directory as the temporary directory earlier in tst_QQuickFileDialogImpl::initTestCase() to ensure that it is always set properly. Fix the failing test tst_QQuickFileDialogImpl::changeFolderViaDoubleClick() on Ubuntu 24 Pick-to: 6.9 6.8 6.5 Change-Id: I9e124280e69c67056e0cc9ce15a1a45b57221cb2 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* QQuickTest: add and use active focus macrosMitch Curtis2025-04-254-8/+8
| | | | | | | | | | | | | Also add support for popups (when controlstestutils_p.h is included). [ChangeLog][Qt Quick Test] Added QVERIFY_ACTIVE_FOCUS and QTRY_VERIFY_ACTIVE_FOCUS macros that can be used to get detailed failure messages for when QQuickItem::hasActiveFocus should be true but isn't. Task-number: QTBUG-133858 Change-Id: I30c67a84ccc16e3969bac5661648d0062bc3d62c Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* AbstractDialog: add property popupTypeOliver Eftevaag2025-03-061-0/+38
| | | | | | | | | | | | | | | | | | | | 18c4bf827dabea735435887f84ad1bea4136b1ea made all non-native dialogs in QtQuick.Dialogs use `Window` as their popupType, in order to make the dialogs appear as top-level windows. However, there are some users that wish to use these non-native dialogs without them being top-level windows, like they were before 6.8. This was unfortunately not possible, since there weren't any API to customize the popupType for QtQuick.Dialogs. We were reluctant at first, to provide properties that only customize the non-native dialogs, without having any effect when native dialogs are used. However, there needs to exist some way for the popupType to be reverted back to `Item`, and thus, it makes sense to have a property for it. Fixes: QTBUG-134037 Change-Id: Idcfe4d3960c7002566f344ae32422c9cb7ce7631 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Use popupWindow()->close() to fix tst_qquickColorDialogImpl::defaultsFrédéric Lefebvre2025-03-031-2/+2
| | | | | | | | | | | | | | tst_qquickColorDialogImpl::defaults is flaky where in some cases dialogHelper.dialog is not being close properly. Use popupWindow()->close() instead of dialogHelper.dialog->close() the to properly close it. Fix flaky test tst_qquickColorDialogImpl::defaults on Opensuse Pick-to: 6.9 6.8 6.5 Change-Id: Ic62e241e12f1289d2aaa11552047b61d99c056d9 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Fix flaky test tst_qquickColorDialogImpl::dialogCanMoveBetweenWindowsFrédéric Lefebvre2025-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | tst_qquickColorDialogImpl::dialogCanMoveBetweenWindows() is flaky where in some cases the quickDialog cannot be close properly as no signal is emitted when clicking the button. When it is failing, the re-parenting of the quickDialog is done properly, but the quickDialog is not rendered. The button cannot then be clicked to close the dialog. Close the popupWindow() and open it, before closing it with CLOSE_DIALOG("Ok"). Fix flaky tst_qquickColorDialogImpl::dialogCanMoveBetweenWindows on Opensuse Pick-to: 6.9 6.8 6.5 Fixes: QTBUG-134043 Change-Id: Ib60ecd745e0407fa67ba2dfcaf8e445dc96a0f06 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* FileDialog: add test which uses the new sidebarOliver Eftevaag2025-01-161-1/+28
| | | | | | | | | | The sidebar lacks test coverage. Add a basic test, which verifies that clicking on the various buttons that represents standard paths, actually changes the dialog's currentFolder. Pick-to: 6.9 Change-Id: I48d2672a2d26ae96c8a2069e1bbfb340117a10c3 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* DialogsQuickImpl: Implement ColorInputs as a custom controlOliver Eftevaag2024-12-111-36/+46
| | | | | | | | | | | | | | | | | | ColorInputs might as well be a real custom control, instead of a half-baked one. This also makes the ColorDialog much more responsive when resizing it. If we refactor the module in the future, we'll also likely need each style to be self-contained to one module each. This patch ensures that ColorInputs.qml is no longer shared between all styles. Pick-to: 6.9 Fixes: QTBUG-106246 Task-number: QTBUG-104091 Change-Id: I6c8a687a798f015dce47cc94a10266227899db0f Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Close popup windows on outside mouse press and releaseOliver Eftevaag2024-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Popups are expected to automatically close, when the user clicks outside of them. Clicking on a different window should close the popup window, regardless of whether that window is owned by the same application or not. In qt widgets, we use QWindow::setMouseGrabEnabled(true) and QWindow::setKeyboardGrabEnabled(true), to receive and act upon these mouse events, that would otherwise be sent to different applications. While this approach doesn't work on every single platform, it should work Windows, macOS and Linux/xcb, which are the most important ones. Closing popups in Wayland unfortunately can't be done in the same manner. The solution here was to close all popups on the ApplicationDeactivate signal (914c2ef4fb926c16e8874c9c3691401f7e22ae22). In qt quick, we have the closePolicy property, which we should honor to some degree. QWindow::setMouseGrabEnabled(true), gives us the flexibility needed to do that, and we can do the grabbing in QQuickPopupWindowPrivate::setVisible(), instead of static Q*Application functions which is the pattern used by widgets. Since we're already forwarding mouse and keyboard events to the active popup window, we'll need to close popups in cases when the user presses or releases the mouse outside of the popup window. The filterPopupSpecialCases() function already handles some special cases when the popup window is used by a menu. Instead of reimplementing the mousePressEvent and mouseReleaseEvent functions in QQuickPopupWindow, I instead made the decision to extend the functionality of filterPopupSpecialCases to handle cases for closing all sorts of popups when the mouse is pressed or released outside, instead of just limiting this functionality to menus. Note that instead of closing all popups, when clicking outside, we're only closing the current active popup window. This is consistent with qt widgets. Strangely however, the popup order functions in a FIFO manner, where the first opened popup is the active popup, and not the last. This means that popups are not ordered in a stack, but rather a queue. In cases when the closePolicy is CloseOnEscape, we don't have to do anything, since escape key handling is already taken care of, by the forwarding logic. Pick-to: 6.8 Change-Id: Icc1cfcf1526108e1bf7be90bac608fb094aa8f7b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add Qt::Qml before Qt::QmlPrivate to auto testsKarim Pinter2024-10-225-0/+5
| | | | | | | | | | The build for auto tests for VxWorks fails because Qt::Qml is not added before Qt::QmlPrivate resulting in many unresolved symbols from Qt::Qml library. When Qt::Qml is added before it solves this problem. Task-number: QTBUG-129113 Change-Id: I89d553ac1d6706e2e934665fed2f308e6b01ed78 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QQuickDialog: reject on hideEvent, when popupType: Popup.WindowOliver Eftevaag2024-09-271-0/+25
| | | | | | | | | | | | | | | | | Dialogs should be either rejected or accepted, when they close. When they close as a result of a hideEvent (usually when the user presses the X button in the window decoration), it's expected that the dialog emits the rejected signal. QtQuickDialogs expects either accepted or rejected to be emitted when the dialog closes. Because neither signal were emitted, QtQuickDialogs would enter a state, where it falsly believe that the dialog is still opened, when it was closed due to the hideEvent. Fixes: QTBUG-129323 Pick-to: 6.8 6.8.0 Change-Id: I03e0406c6c4ce0237ddfa625bb476b11013b7666 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Set visibility of popupItem to false when a popup window is not visibleEd Cooke2024-09-061-2/+1
| | | | | | | | | | | When transitioning out of a popup with popupType set to Popup Window, the popupItem's visibility needs to be set to false so that listeners are notified of the change. Fixes: QTBUG-126815 Pick-to: 6.8 Change-Id: I2545e530fa22d14478ab90f0fc3da61ef79dc171 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Fix binding loop in FileDialogOliver Eftevaag2024-08-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | The patch 1cc20d181bdee1131bf2eb191e7f8fe4e4927e03 introduced a nested dialog inside the FileDialog, which contained a Label as its contentItem. This would cause a binding loop, since the dialog would add itself as an implicitSize listener to the Label, and attempt to update it's own implicitSize twice, when the Label's text changes. Fix the issue by giving the dialog an explicit width. When the overwriteConfirmationDialog had an animation (which the Material Dialog has), it was possible to enter QQuickPopupPositioner::reposition(), when its parentItem (the fileDialogListView), no longer had a window. Add a check to return early, in those situations, to avoid a crash. Pick-to: 6.5 6.7 6.8 Fixes: QTBUG-127619 Change-Id: I0324a2a470f237ba1a65a95d8bea7fa50166d756 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Enable popup windows for QtQuick.DialogsOliver Eftevaag2024-07-235-148/+312
| | | | | | | | | | | | | | | | | | | | | | | | | | | The dialogs in QtQuick.Dialogs look so much better on desktop systems, when they appear inside real top level windows. This change enables the feature for all QtQuick.Dialogs types, and makes manual changes to each dialog, to make sure that they look good. This includes changes that hides the title from the header, since the title can now appear inside the window decoration instead. Lots of tests had to be changed, as a result, to properly generate and deliver events to the correct items. In addition, I've added some helper functions to dialogHelper, to handle cases we're we need to wait for a popup window to appear. Showing popups with dedicated windows, takes longer than simply creating a new item in an existing window. [ChangeLog] All dialogs in QtQuick.Dialogs will now use popup windows, if able. Fixes: QTBUG-126006 Pick-to: 6.8 Change-Id: Ieca6ae643d4f97b1bed648e448bbcd236a50e7e7 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fix binding loop that occurs in QtQuickDialogs using popup windowsOliver Eftevaag2024-07-194-46/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | Here's a vague description of the loop: 1. The implicitWidth binding of QQuickDialog needs to be evaluated. Call setImplictWidth(). 2. QQuickPopupItem::geometryChange() and QQuickPopup::geometryChange() are called, 3. QQuickPopupPositioner::reposition() is called. 4. QQuickPopupPrivate::windowInsets() is called, to be used as positional offsets. This ends up calling QQuickControl::background(). 5. Because of deferred execution, the background wasn't already initialized. Needs to be lazily initialized instead. 6. QQuickPopup::setBackground() and QQuickPopup::implicitBackgroundWidthChanged() are called. 7. Reevaluate implicitWidth binding. 8. Theoretically back to 1. which is why it's a loop. The fix here, is to avoid calling QQuickControl::background() in QQuickPopupPrivate::windowInsets(), but instead access the data directly, if the background is executing. Pick-to: 6.8 Change-Id: I89f5f92cd9f2dc5f78070a3cf1e21dc6bfdd10f7 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Unblacklist tst_qquickfontdialogimpl::settingUnderlineAndStrikeoutEffectsDoris Verria2024-06-182-4/+2
| | | | | | | | | | | | | | | A font change in the font dialog will trigger a font change in the sample text's textEdit. This may change the size of the text edit, and require a relayout of the dialog's items. That is what was happenning in tst_qquickfontdialogimpl:: settingUnderlineAndStrikeoutEffects and causing a failure to click a button because the items hadn't finished the relayout. To fix, before triggering any mouse events after the font change, we need to wait for a polish event using qWaitForPolish. Fixes: QTBUG-126375 Change-Id: Icb69a64bd27a78852b509213f792f2ee2f3bcf4f Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Blacklist tst_QQuickFontDialogImpl::settingUnderlineAndStrikeoutEffectsUlf Hermann2024-06-151-0/+5
| | | | | | Task-number: QTBUG-126375 Change-Id: I8a72fd9171e2506d8f32e92e6e14f77d6b7a1965 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Give QQuickPopup the ability to create top-level windowsOliver Eftevaag2024-05-271-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Desktop users typically expect dialogs to be top level windows, but there can also be advantages to having other types of popups, such as Menus, and ToolTips, be top level windows as well. Currently the QQuickPopup class is tightly coupled with the QQuickPopupItem which it creates, and forwards a bunch of properties to. But we want Popup to seamlessly create a new window, which renders the popup item. This should serve as a new feature, which is primarily targeted for desktop users, and should not replace the old behavior, since having the popup item in the same window will likely be preferred for mobile and embedded users. The default behavior will now be to create a popup window, when the QML application is running on a desktop system (determined by the platformIntegrations capabilities). It's also possible to opt out of this new behavior, by setting the AA_DontUsePopupWindows application attribute flag. The dialogs in QtQuick.Dialogs should now also appear in their own dedicated window, since they were using QQuickDialog behind the scenes. The combobox popup, will also appear in its own window. Some changes, such as modality, won't take effect until the window is reopened, since the window is destroyed/recreated on visibility changes. Done-with: Ed Cooke <ed.cooke@qt.io> Task-number: QTBUG-121363 Change-Id: I21f4fd1f922219359d3258854bdcdc9be6980f4f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Fix test compilation issues with QtLite configurationJari Helaakoski2024-04-302-0/+42
| | | | | | | | | Now developer build tests compile, but some are not working. Functional fix will come later via separate tasks. Task-number: QTBUG-122999 Change-Id: I0a0dfcf7affb73f928b8be62b3576a6a51658488 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Correct license for test filesLucie Gérard2024-02-2723-23/+23
| | | | | | | | | | | | | | According to QUIP-18 [1], all test files should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Dialogs: Defer automatic window resolving until dialog is openedOliver Eftevaag2024-01-154-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The qml tool, as well as the QQuickView class are creating their own window outside of the root qml file that is passed to them. This caused an issue where no dialog were able to find a window when componentComplete() was first called, which would make them return early in the QPlatformDialogHelper::show() re-implementations, and thus never show the dialogs when open() was called. This patch solves the issue by waiting until open() is called, before trying to find a window in any of the parent items. Since Window always has a contentItem, it was also possible to simplify the logic that searches for a window, by only trying to cast the parent to QQuickItem*. Another issue that came up, was the fact that dialogs with visible set to true, aka: FileDialog { visible: true } Should open as soon as possible upon its creation. To get around this, open() is called during componentComplete() if a window can be found during this time. Otherwise, the call to open() is deferred until the nearest parent item emits the windowChanged() signal. Note that calling setParentWindow() will now take priority over the implicit window search, unless the argument for setParentWindow is null. Meaning that moving a dialog to a different window, by modifying parents, will not happen for dialogs that are explicitly binding a value to parentWindow. Fixes: QTBUG-106598 Pick-to: 6.5 6.6 6.7 Change-Id: Idd7c0ecdeea6cbf26e8d41168788563ee9794118 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* FileDialog: set url schema when using the file name text fieldOliver Eftevaag2024-01-101-0/+42
| | | | | | | | | | | | | | | | When using the text field to choose a file name inside the non-native file dialog, the selectedFile property would be updated based on the currentFolder property and what the newly typed filename was. However, the schema was ignored. This patch fixes the issue by also setting the schema in QQuickFileDialogImpl::setFileName(const QString &fileName). Fixes: QTBUG-120065 Pick-to: 6.7 6.6 6.5 Change-Id: I1860fbbc8209270d0bc6e34a4be6a91bad2253ab Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Only update the filename text field when the user selects a fileOliver Eftevaag2024-01-091-0/+49
| | | | | | | | | | | | | | | | | Apparently, it's normal for file dialogs to not update the text field that represents the filename of the currently selected file, if the selected file is a directory. To achieve that behavior, I'm removing the binding on the text property, and instead call setText() to update the text field when either the user selects another file in the file dialog list view, or when the selectedFile is changed externally. But only if the selectedFile is an actual real file, and not a directory. Fixes: QTBUG-119917 Pick-to: 6.7 6.6 6.5 Change-Id: I8dbf41ba403d09419a2d66130bdad59e66c9d1cf Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* FileDialog: prompt the user when selecting an existing fileOliver Eftevaag2023-12-221-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is common for editing software to prompt the user when he/she wishes to save the work done in the editor, and an existing file is selected in the file dialog. This is an extra safety step, to hopefully prevent the user from accidentally shooting himself/herself in the foot, by overwriting an existing file and losing something valuable. One of the available file dialog option is DontConfirmOverwrite. Which according to the documentation, could be set in order to bypass a confirmation which is supposed to show up by default. But that weren't the case when using the non-native quick file dialog. The FileDialog will now show that confirmation dialog as a popup dialog, which popups up on top of the FileDialog, when selecting an existing file using the SaveFile file mode. The DontConfirmOverwrite option can now be used as intended, which will make the FileDialog behave like it used to, when selecting an existing file. In additon, hitting enter while the file dialog list view has focus, will now function the same as clicking the "Open" button. This was done in order to prevent the user from being able to bypass the new confirmation dialog. Fixes: QTBUG-119916 Pick-to: 6.7 6.6 6.5 Change-Id: I07710a7126c53f489fd5554ea21e7684244a93c1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* MessageDialog: make QQuickAbstractDialog::result return button pressedOliver Eftevaag2023-12-102-0/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The widgets QMessageBox returns either the StandardButton value of the last button pressed, or the index, in the case of custom buttons. This differs from how we did things in quick, where we'd always return either 0 or 1 (Accepted or Rejected). The documentation even states the following: MessageDialog sets the result to the value of the clicked standard button instead of using the standard result codes Which was incorrect, since the result property functioned the same, regardless of dialog type. The goal of this patch is to make the result property for MessageDialog behave the same as QMessageBox, without changing the behavior for other dialog types. In order to accomplish this, the type has to be changed from StandardCode to int, since the result value can either be a StandardCode value, or a StandardButton value. The widget QMessageBox also differs in that it will not emit rejected when the user presses a button with a role that isn't NoRole or RejectRole. I've decided to make the MessageDialog behave the same way. [ChangeLog][QtQuick][Dialogs][Important Behavior Changes] The MessageDialog will no longer emit rejected when the user presses a button that doesn't have the role NoRole or RejectedRole. Task-number: QTBUG-118445 Task-number: QTBUG-118689 Task-number: QTBUG-118212 Change-Id: I7084a889210027f5c057f5c22eee2e08867ce741 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Fix accept button enabled state in non-native file dialogEirik Aavitsland2023-09-211-0/+17
| | | | | | | | | | | | | | | | When editing save file name in the line edit, and changing it from empty to non-empty or the other way around, the accept (Save) button would not be enabled/disabled accordingly. Can be tested with the qml file from the linked task. Task-number: QTBUG-101552 Task-number: QTBUG-108455 Pick-to: 6.6 Change-Id: Icc0ea5f68cfe06e95f54839cf4bd930bd8d57daf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Fix default button label for non-native file dialog in SaveFile modeEirik Aavitsland2023-09-211-7/+9
| | | | | | | | | It would use the OpenFile label independently of actual mode. Fixes: QTBUG-105080 Pick-to: 6.6 Change-Id: Ia529f6854dd676197af99cbe0a610f5833181ce2 Reviewed-by: Kaj Grönholm <kaj.gronholm@qt.io>
* Normalize signal/slot signaturesMarc Mutz2023-07-121-2/+2
| | | | | | | | | | | | | | This is the result of running util/normalize on the code base. The following manual edits were needed: - skipped the hits in IS_SIGNAL_CONNECTED, which is using function pointers under the hood - restored the space before * in Q_SIGNAL void foo(QType *arg) Pick-to: 6.6 Change-Id: I299b3747c1aa2f6b3bc5ae1794edeb6fadfd75c6 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Make qtdeclarative tests standalone projectsAlexandru Croitor2023-07-055-0/+30
| | | | | | | | | | | | | | | | | Add the boilerplate standalone test prelude to each test, so that they can be opened with an IDE without the qt-cmake-standalone-test script, but directly with qt-cmake or cmake. Boilerplate was added using the follow script: https://git.qt.io/alcroito/cmake_refactor Manual adjustments were made where the code was inserted in the wrong location. Task-number: QTBUG-93020 Change-Id: Ibd12efab09ceb5852395e40f10b55fafb69c1b58 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add flag to hide eye dropper button from qml ColorDialogFabio Falsini2023-06-241-0/+18
| | | | | | | | | | | | | In devices with small screen like smartphone the ColorDialog dialog covers almost the entire screen so the eye dropper button doesn't make much sense and risks confusing the user. This patch add a flag to hide the button. Also if both title and button are not showed the header is resized to a fixed height. [ChangeLog][Dialogs][ColorDialog] Added a NoEyeDropperButton option to hide the eye dropper button Change-Id: I89f740b254a8f9d4a1274a2624d1b9b5da648184 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Fix various compiler warnings in testsVolker Hilsheimer2023-04-241-9/+9
| | | | | | | | | | Comparison of variables of different types (int or size_t and bool), missing override, lossy conversion from double to float. Pick-to: 6.5 Change-Id: Iad4b18450ab0a0a1cab01fa524777e1441986875 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Stabilize some tst_QQuickFileDialogImpl test functionsMitch Curtis2023-03-291-0/+9
| | | | | | | | | | | As with 989e05a0b8240778c9f249edea5c9d27d68f8e0f, ensure that the ListView delegates are up-to-date before checking the selected delegate. Task-number: QTBUG-101488 Pick-to: 6.5 Change-Id: Ib33df6d1a67d2090a5e6af52783212c2979930fb Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Improve tst_QQuickFileDialogImplMitch Curtis2023-03-291-20/+41
| | | | | | | | | | | | | Instead of hard-coding the list of expected visible file delegates, move that logic into functions and call them. Also, implement Clazy's suggestion of using the multi-argument overload of arg(). Task-number: QTBUG-101488 Pick-to: 6.5 Change-Id: Iafb35329c30452b5689303d962675ea908e0f32a Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Retire the qt_parse_all_argumentsAmir Masoud Abdol2023-01-205-15/+15
| | | | | | Task-number: QTBUG-99238 Change-Id: Ia11c9cbd7c06347319ab3674ec0cd8da0214747e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove "2" from Qt Quick Controls directoriesMitch Curtis2022-12-015-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Qt Quick Controls 2 was named that way because it was a follow-up to Qt Quick Controls 1.x. Now that Qt Quick Controls 1 is no longer supported, we don't need to have "2" in the name. Work on this was already started for the documentation in 1abdfe5d5a052f2298b7bf657513dfa7e0c66a56. By doing this renaming a few weeks before feature freeze, it won't affect the release but still results in as little time possible spent manually fixing conflicts in cherry-picks from non-LTS releases as a result of the renaming. This patch does the following: - Renames directories. - Adapts CMakeLists.txt and other files to account for the new paths. A follow-up patch will handle documentation. It does not touch library names or other user-facing stuff, as that will have to be done in Qt 7. Task-number: QTBUG-95413 Change-Id: I170d8db19033ee71e495ff0c5c1a517a41ed7634 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fix bug in FolderListModel's FileInfoThreadMitch Curtis2022-10-181-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the FileDialog in the goUp test is first created, it sets a bunch of properties, two of which are sortCaseSensitive and nameFilters. These cause FileInfoThread's sortUpdate and folderUpdate flags to be set to true, respectively. When FileInfoThread::getFileInfos() ran, it would see that folderUpdate was set to true, run related code, and then unset folderUpdate. However, sortUpdate would not be unset. This meant that the next time getFileInfos() was called, it would effectively reset the model when it didn't need to. This caused the currentIndex we set on fileDialogListView to be ignored because the ListView set it to 0 as a result of the insertion and removal of rows from the model caused by QQuickFolderListModelPrivate::_q_sortFinished(). This patch fixes the issue by: - Introducing an enum to manage the different types of updates requested, which also makes the code a little easier to understand. - Unsetting the various flags whenever needUpdate is unset. It also adds categorized logging to make debugging such issues in the future easier. Task-number: QTBUG-101488 Pick-to: 6.4 Change-Id: Iaf53509d3f028fd2e1385a2597898e8e0327aedb Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* tst_qquickfiledialogimpl: print QTemporaryDir errorsMitch Curtis2022-10-081-2/+2
| | | | | | | | | This will make diagnosing CI failures easier. Task-number: QTBUG-101488 Pick-to: 6.2 6.4 Change-Id: I18fead16fb631c63c7da40b5154266474e6feccd Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-072-4/+4
| | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace. Task-number: QTBUG-99313 Change-Id: I601bf70f020f511019ed28731ba53b14b765dbf0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-24 05:30:48 +0000