Qt Labs Platform already has native dialogs:
- ColorDialog | Platform availability
- FileDialog | Platform availability
- FolderDialog | Platform availability
- FontDialog | Platform availability
As with the old Qt Quick Dialogs, these come with the requirement that the application links to Qt Widgets:
The Qt Labs Platform module uses Qt Widgets as a fallback on platforms that do not have a native implementation available. Therefore, applications that use types from the Qt Labs Platform module should link to QtWidgets and use QApplication instead of QGuiApplication.
The implementation of ColorDialog will be a platform color dialog if possible. If that isn't possible, then it will try to instantiate a QColorDialog. If that also isn't possible, then it will fall back to a QML implementation, DefaultColorDialog.qml. In that case you can customize the appearance by editing this file. DefaultColorDialog.qml contains a Rectangle to hold the dialog's contents, because certain embedded systems do not support multiple top-level windows. When the dialog becomes visible, it will automatically be wrapped in a Window if possible, or simply reparented on top of the main window if there can only be one window.
What we're missing in Qt Quick are the non-native dialogs.
When QTBUG-69558 is implemented, each Popup can either be:
- A top-level window (on platforms that support multiple top-level windows), or;
- A non-native window (if the platform doesn't support multiple top-level windows, or if the user just happens to want a non-native window).
We can then possibly also remove the Qt Widgets fallbacks and only fall back to non-native dialogs from Controls 2.
Until that is implemented, it would be easier to:
- Ensure that our Qt Labs Platform offering of dialogs is up to par with the old Qt Quick Dialogs' offering. From what I can see, it is.
- Implement non-native versions of these dialogs in Qt Quick Controls 2.
To use native and non-native types in this manner requires the use of file selectors. File selectors are nothing new to Qt Quick Controls 2, and in fact will be required more often with Qt 6 if users wish to support multiple styles (due to the compile-time type changes).
We should aim to keep the API of the non-native dialogs in sync with the native dialogs.