Xdg-desktop-portal will reject any OpenFile request if there is an empty
filter. We will just simply skip it to avoid the rejection so users get
a file dialog.
Pick-to: 5.15
Change-Id: I85c056f46b22cdbc9e14010bc3c49206b6f8f002
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The previous fix didn't actually work, as it kept a reference
into a container which could have been muted by the time the
reference was going to be used.
Use an index instead.
Amends 32c09ea5b0.
Change-Id: Ib855b4a663c281467e46536b98a0ce2b961f19ee
Pick-to: 5.15
Task-number: QTBUG-87143
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change lots of code to avoid the deprecated operator+() or implicit
casts to int.
Change-Id: I0c343cd5b28603afdf1214eefb85e928313345e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use pointer to newly inserted element in 'filterList'
since local variable 'filter' goes out of scope at the end
of the block.
This is a follow-up for commit
3e09c28101
("Filechooser portal: Implement "current_filter").
Thanks to Giuseppe D'Angelo for pointing this out in that
commit's Gerrit change.
Pick-to: 5.15
Change-Id: I9af35c46315c7f90721d0d39b0fda6384c15786a
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This adds supports for setting and retrieving the selected
MIME and name filter for 'QXdgDesktopPortalFileDialog'.
For preselecting a filter [1]:
> current_filter (sa(us))
>
> Request that this filter be set by default at dialog creation. If
> the filters list is nonempty, it should match a filter in the list
> to set the default filter from the list. Alternatively, it may be
> specified when the list is empty to apply the filter
> unconditionally.
The "current_filter" return value was added in xdg-desktop-portal
commit [2].
[1] https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.FileChooser
[2] 35fca7fae8
Fixes: QTBUG-85658
Pick-to: 5.15
Change-Id: I8651c1a8942dfd358895b7826730729c4d22e680
Reviewed-by: Jan Grulich <jgrulich@redhat.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the base platform theme is not set to a null pointer, then we might
assume it has been already constructed and later on try to access an
invalid address which will cause a crash.
Pick-to: 5.15
Change-Id: I6187336bca527e1feeb0902bcfb16f2fbec86d24
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Recent version of xdg-desktop-portal got support for opening directories
through the portal, which means we no longer need to rely on opening the
dialog inside sandbox, hoping we have permissions to user directories.
[ChangeLog][Linux] QFileDialog will open directories through the portal
if required version of xdg-desktop-portal is running on the system.
Change-Id: Ifc9035e268f1cc8d9d6a93480e651e0d9e1e9929
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Qt version was added in 5.14 "for use as eventual replacement for
QString::SplitBehavior." Move another step closer to that goal.
Change-Id: I399b5ea56e9255e775ca1746632f7421519a6616
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
And also to get the original output names (qmake's "TARGET"), so that
the plugin file names are as they were in Qt 5.
Change-Id: I96a060d1a81693652847857372bec334728cb549
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This substantially decreases the number of warnings when doing
a Qt static build with examples.
This is a quickfix modifying the relevant files directly. A proper
fix will follow that regenerates the whole files.
Change-Id: I2a3cc2c4ea02b3412beb96f7b4be9d43365a460d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
This change introduces a new function called qt_find_package()
which can take an extra option called PROVIDED_TARGETS, which
associates targets with the package that defines those targets.
This is done by setting the INTERFACE_QT_PACKAGE_NAME and
INTERFACE_QT_PACKAGE_VERSION properties on the imported targets.
This information allows us to generate appropriate find_dependency()
calls in a module's Config file for third party libraries.
For example when an application links against QtCore, it should also
link against zlib and atomic libraries. In order to do that, the
library locations first have to be found by CMake. This is achieved by
embedding find_dependency(ZLIB) and find_dependency(Atomic) in
Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake.
The latter is picked up when an application project contains
find_package(Qt5Core), and thus all linking dependencies are resolved.
The information 'which package provides which targets' is contained
in the python json2cmake conversion script. The generated output of
the script contains qt_find_package() calls that represent that
information.
The Qt5CoreDependencies.cmake file and which which dependencies it
contains is generated at the QtPostProcess stop.
Note that for non-static Qt builds, we only need to propagate public
3rd party libraries. For static builds, we need all third party
libraries.
In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any
scope, the targets on which the property is set, have to be GLOBAL.
Also for applications and other modules to find all required third
party libraries, we have to install all our custom Find modules, and
make sure they define INTERFACE IMPORTED libraries, and not just
IMPORTED libraries.
Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We should be using QFile::encodeName() to properly convert filenames
from string to bytearray. This takes user's locale into account.
Change-Id: I090f73f21feb73af166e88baa0e7f4a595cdb25b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Terminating character is needed for gtk portal backend, which is not
able to contruct a string without it and thus not able to pre-select a
file or a directory in file dialog.
Change-Id: I5b40fb1ce584936fc92e93f38dc8559890852d99
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Snap now uses xdg-desktop-portal for portal support. Add check for apps
running in Snap and make them use portals by default. We also should be
using different name for the platform theme used by sandboxed apps.
Change-Id: Ibaa35b7549b3d94775d7edb937f729a300d071b6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We have to take obsoleted QFileDialog::DirectoryOnly file mode option
into account, because it is actually used, even internally in Qt when
using static QFileDialog::getExistingDirectory() method.
Change-Id: I6cdd35ae4724a1d889a0fb1c3555dc3ca4f3bf4d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When doing calls on native file dialog, we might end up calling an
implementation which will cause crash in case we don't have all options
loaded in the native file dialog. Imagine scenario when you want to save
a file, it sets acceptMode() to QFileDialogOptions::AcceptSave, which is
set to our flatpak file dialog, but not passed through to the native one
loaded inside. Then method calls like selectFile() might crash, like
in case of Gtk3 dialog, because its implementation asks for acceptMode,
but it's not set yet and thus we end up with crash.
Change-Id: I7a4239cb8b46ff6b08e2cfc1dd6abb9d9600aef8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Flatpak FileChooser portal doesn't support opening and exporting
directories to the sandbox as it's not technically possible. Files are
simply exported through document-portal, but directories are a different
story. We have to, in case we want to open a directory, use native file
dialog provided by platform theme we have loaded into flatpak platform
theme. Applications which need to open directories to be able to work,
like IDEs, music players, will have enabled access ho host's filesystem
anyway so it's fine to open a file dialog inside sandbox.
[ChangeLog][Linux] QFileDialog will use the native dialogs provided by
the platform theme instead of trying to use Flatpak portal to select
directories.
Change-Id: I0716193bb9878aa621b8ca88506f87c72f690887
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Filters are usually in format (Name (*.foo *.bar)), but valid filter is
also (Name ( *.bar *.foo )), containing additional spaces. When we split
content in the brackets divided by spaces, there will be then empty
strings which we need to filter out, otherwise the result we send over
DBus is not valid.
Change-Id: Iaa265189408f47324bc9b269d534bf4c8d7d2cae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When not specified, xdg-desktop-portal keeps using same Request object
over and over when returning response, causing multiple connections
to same slot on same DBus object. While this is not problem when using
FileDialog just once, it is a problem for QML FileDialog which is
usually reused. For this purpose x-d-p provides handle_token option
where you can specify token to be used when creating Request objects.
Change-Id: Ie6569700c48e05fcefa4d5c22c921410f87ea7ae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use QT_CONFIG(regularexpression), disentangle it from QT_BOOTSTRAPPED,
switch it off in the bootstrap build, remove the #ifdefs from
qregularexpression.{h|cpp}, and add QT_REQUIRE_CONFIG(regularexpression)
to the header.
qregularexpression.{h|cpp} are already correctly excluded in tools.pri
if !qtConfig(regularexpression).
Change-Id: I21de154a6a118b76f99003d3acb72ac1e220d302
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If a target item was passed, QGtk3Menu tried using gtk_menu_set_active()
to select the target item. However, the function does not do what you'd
imagine. Even the documentation states:
This is used by the GtkComboBox and should not be used by anyone else.
The correct function, gtk_menu_shell_select_item(), is in the GtkMenuShell
"base class".
Change-Id: Ia2c03f87bb97f618c041c03011af8c676108aea5
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
There is no codepath that can result in d->baseTheme being nullptr.
Remove the checks and get rid unneeded and sometimes dangerous fallbacks
(createPlatformMenuBar(), showPlatformMenuBar() and three more methods
could overflow the stack because of infinity recursion).
Change-Id: Ib03adadf56c169286de42671e2da506502df7aea
Reviewed-by: Jan Grulich <jgrulich@redhat.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
GTK's scale factor, which can differ from Qt's scale factor, must
be taken into account in the native GTK menu positioning function
qt_gtk_menu_position_func().
Task-number: QTBUG-55251
Change-Id: I4ad460baab54facd25564ad85ded383c9321d597
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Jan Grulich
Giuseppe D'Angelo
Lars Knoll
Jonas Karlsson
Michael Weghorn
Jarek Kobus
Alexandru Croitor
Friedemann Kleint
Tor Arne Vestbø
Liang Qi
Leander Beernaert
Qt Forward Merge Bot
Edward Welbourne
Allan Sandfeld Jensen
Albert Astals Cid
Tobias Hunger
Kevin Funk
Mikhail Svetkin
Ulf Hermann
J-P Nurmi
Alexander Akulich