| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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 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>
|
| |
|
|
|
|
|
| |
Non-static, non-forward-declared logging categories are deprecated.
Change-Id: Iaeb0183ef7ca05bbd0f4587166096c29825cc175
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
A recent fix introduced an unchecked deref of d->options. No problem
has been observed, but all other usages in this file are guarded, so
avoid introducing a potential crash.
Pick-to: 6.7 6.6 6.5
Change-Id: I3602808c42094d24ba08d32612af3d3e95e90279
Reviewed-by: Kaj Grönholm <kaj.gronholm@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
