| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make use of the API introduced in
644349fecb9ce58659e590be7049ba93889d9f34
to set the accessible label-for/labelled-by
relationship between the "Filter" label and
the corresponding combobox in the QML FileDialog.
This makes screen readers like Orca on Linux announce
the label text when the combobox receives focus, so the
meaning/context becomes clear.
Change-Id: I06db7db7fb3afeb748b99ab29cb90e8bfd694279
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The files (folders) already processed are listed in each issue in epic
QTBUG-134547
These files were processed half a year ago. In order to make it clear
that all of these files are already processed, mark them with an
explicit default security header.
For the record, this was generated with this script:
find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py
in the folders listed in each subtask of QTBUG-134547
(add-cra-header.py only exist at my desktop, but it simply adds the
default security header if it doesn't already have any existing security
header)
QUIP: 23
Fixes: QTBUG-134547
Pick-to: 6.10 6.9 6.8
Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Popup uses a Pane as its popup item, so now that Pane reflects its
explicitly set contentWidth/Height through implicitContentWidth/Height
we can use the same expression for implicit width/height as regular
controls, which hooks us into the safe area binding loop detection
as well.
Pick-to: 6.9
Change-Id: I3709978dae0271d7daf44fc6988f09f03df15b1f
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Implement a side bar for non-native QtQuick Dialogs. This side bar has a
ListView as its content item that contains common standard locations
from QStandardPaths::StandardLocation.
Change-Id: Icd916aa91f02a072b4935573c91e6151e3dcdcc1
Fixes: QTBUG-123756
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QtQuick.Controls and QtQuick.Controls.impl modules were imported by
our non-native dialogs, along with the style specific modules (e.g.
QtQuick.Controls.Fusion and QtQuick.Controls.Fusion.impl).
This is not only unnecessary, but it also causes the styles to
occasionally mix. Making the look and feel inconsistent.
(e.g when using the QQC2 macOS style, the non-native dialog would be a
hybrid between the macOS style and fusion style).
Fix this by only importing the QQC2 module that's associated with the
QuickDialogsQuickImpl style used.
Pick-to: 6.8
Change-Id: I154e3eeca096e7da379fadac4966e5120858ca5d
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tab navigation between the file dialog list view, breadcrumbbar
and name filters combobox wasn't implemented on all styles.
Furthermore, the file name text field were not present in the tab
focus chain at all, regardless of the FileDialog's fileMode.
This patch fixes tab navigation for every style, and brings
the file name text field into the tab focus chain when
fileMode == SaveFile.
Pick-to: 6.7 6.6 6.5
Change-Id: Ie94d694449d545491c1198ec9b4594d8d475a210
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
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>
|
