Our logic in the edit menu tap recognizer for determining whether the
tap should trigger the edit menu only looks at the bounds of the input
area, and as long as the tap is within these bounds we trigger the edit
menu.
This doesn't take into account that there might be controls laid on top
of the input area, for example a button, where we don't want to trigger
the gesture.
The only related logic we have is a heuristic that checks whether the
cursor ends up moving as a result of the initial press, in which case
we treat it as the edit area "accepting" the touch press.
The proper fix to this is to handle the gesture recognizer delegate
callback gestureRecognizer:shouldReceiveTouch:, and do hit testing
there, but we don't have any machinery for that in our IM protocol,
nor in QWSI.
As a workaround, we treat the gesture recognizer as having failed,
even when we do detect a tap that should open the menu, so that the
recognizer doesn't eat the touch event. We then open the menu manually
instead of relying on the gesture recognizer changing state. This
should be safe, as sending a touch/mouse event down to the input
area should normally be a noop.
The workaround does result in a slight visual wart when clicking
buttons that live inside input areas, as the edit menu temporarily
opens, but the menu is quickly hidden again as the focus object is
transferred to the button. Compared to the current situation, where
the button is visually pressed, but doesn't do anything, and we
bring up the edit menu fully, this is an improvement, even with
the wart.
Note that the original problem outlined in this changed is not an
issue in practice for Qt Widgets, as we synthesize mouse events
from touch events, and (wrongly) synthesize a mouse release in
response to the touch cancel triggered by the gesture recognizer,
so the button is still activated.
Fixes: QTBUG-113975
Pick-to: 6.5 6.6
Change-Id: I41e850f20d69ad8e3247949644a389e1c61c4dcf
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
ACE-encode the domain names, replace dashes with underscores,
prepend underscore to domain name parts that start with a digit.
Add a regression test into tst_qdbusinterface.
Fixes: QTBUG-71674
Change-Id: I92e0c6889163c0eccc4c833f2058d759631f562c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Or old and new load hints in mergeLoadHints() instead of just storing
new ones. Andjust QLibraryPrivate::setLoadHints() to handle objects
with no file name differently and just set load hints directly.
Mention that load hints are merged once the file name is set
in the documentation for QLibrary::setLoadHints().
Add a regression test into tst_qfactoryloader.
Update and extend tst_QPluginLoader::loadHints() to take into account
load hints merging.
Fixes: QTBUG-114480
Change-Id: I3b9afaec7acde1f5ff992d913f8d7217392c7e00
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code is commented out since 12 years ago.
Change-Id: I5cd7380f8f1e778ea62b510aeece1aced111d662
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not a real leak in that the string data is being freed on program
exit (or, more recently, QPixmapCache::clear()), but it can lead to
lots of memory being bound for much longer than expected when users
put in new QString keys without attempting to retrive them again. It
can also lead to problems with QStringLiterals lingering around until
after their underlying data has been freed. A bug in the Fusion style,
generating new string keys for identical state, exposed this
misbehavior, and one way to fix the resulting issue for the user is to
make sure that QPixmapCache doesn't leak QString keys.
The Fusion style issue with generating non-repeating keys for use with
QPixmapCache should also be fixed, eventually, but this patch
relegates that to an optimization issue (the caching is effectively
non-existent), the resource exhaustion is gone now.
The issue exists because the QString keys are internally mapped to
QPixmapCache::Key's by way of a QHash<QString, Key> cacheKeys data
structure. When the QCache, indexed by Key, not QString, decides to
evict an entry, the Key is invalidated, but no-one was removing the
corresponding entry from cacheKeys. So make the existing releaseKey(),
used to invalidate copies of Keys referring to evicted pixmaps, do
that, now. So as not to have to scan the whole cacheKeys QHash for the
right Key, store the QString key, if any, inside the Key, so
releaseKey() can retrieve it and use it for O(1) erasure from
cacheKey.
This allows removing the previous work-around in clear()
(6ab0d25a09), greatly simplify
object(QString), and requires to rewrite all code that holds iterators
or references into cacheKeys over an insertion into or removal from
the QCache. Two (insert() and remove()) have already been done in
prequel commits, so only flushDetachedPixmaps() was left.
Fixes: QTBUG-112200
Pick-to: 6.6 6.5
Change-Id: Ic93b0ed388ae963267fe242b491c6c941d146b99
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Implement insert(QString, QPixmap) in terms of insert(QPixmap) to
avoid duplicating code and to separate concerns: insert(QString,
QPixmap) is now only dealing with the cacheKeys, insert(QPixmap) is
only concerned with the Key-based lookup.
Task-number: QTBUG-112200
Pick-to: 6.6 6.5 6.2
Change-Id: I30394da43a5e93b7bd41ef9ce9c7aea044523c30
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The previous code used `cacheKey` as the name of an iterator, which
made the code hard to understand.
Instead of renaming that to the more idiomatic `it`, use QHash::take()
to get an actual `cacheKey` back, and then delegate to
QPMCache::remove(QPixmapCache::Key) for the actual removal.
Pick-to: 6.6 6.5 6.2
Task-number: QTBUG-112200
Change-Id: I9311c19f12a05cad694702672f17ae19ba339b04
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's a RAII class, and RAII classes should have only [[nodiscard]]
constructors.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ia83fa003677a839734208b12bde2c6287c1b79a3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They're RAII classes, and QUIP-0019 says RAII class' constructors
should be marked [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I0080f5b6a3cea346c0860e00958a8c204849040e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We should not export non-polymorphic classes wholesale. Only export
the non-inline functions instead.
There are no implicitly-declared special member functions in this
class that could cause problems, so we don't need to delay until Qt 7.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I2e98782160cccb9c0f59a68e67ffd29fec42b728
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Amends 55fe46fd58. Before that change,
key release events were ignored as the QLineEdit::event reimplementation
continued to call QWidget::event, and as QLineEdit didn't override
keyReleaseEvent, the default implementation in QWidget got called to
ignore the event.
Restore that behavior by explicitly calling the QWidget implementation
after updating QLineEdit-specific states, and add a test case.
Fixes: QTBUG-114654
Pick-to: 6.5 6.6
Change-Id: Ic8aa35a1c915b446aece47aaf03ef5cf1884b936
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A number of users have explored the behavior and complained about it.
Lets add a \note explaining this. The function in charge is
QThreadPool::stealAndRunRunnable(QRunnable *), which is a private
function, exclusively used by:
QFutureInterfaceBase::waitForResult()
QFutureInterfaceBase::waitForFinished()
also update the documentation to reflect these changes accordingly.
Fixes: QTBUG-112351
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I839858cb449063d8af9bef64d2f35a6816a419b0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Previously, failure handlers did not propagate cancellation. This would
lead to crashes when a QPromise was cancelled without having generated
any result. Subsequent continuations would be invoked and try to access
the result (which was nonexistent) and then crash.
This patch propagates cancellation through failure handlers to prevent
subsequent continuations from being called in the first place.
Fixes: QTBUG-114606
Pick-to: 6.6
Pick-to: 6.5
Change-Id: I23b28a8e70a76e1ba6416be4440360c6dbaef2a3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The export name is now ${TARGET_NAME}Entry. This can also be overridden
by using QT_WASM_EXPORT_NAME, both in CMake and qmake
Change-Id: I59c97ae6e22f0b2720716e9d7eff7b6b13d37ab5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The alternative would be to explicitly cast each list.size() to int. I
think using iterators is a cleaner solution.
Drive-by changes:
- Give a std::pair's members better names than first/second, by using a
structured binding
- Port to qsizetype
Pick-to: 6.6 6.5
Change-Id: Icff3126192f9813fba698d5722b209307011ca48
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was always 0
Task-number: QTBUG-113679
Pick-to: 6.6
Change-Id: I090036296ad2df99b986400863b1e57a5d6101fb
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since they don't contribute to the width of a string then we may
accidentally end up ignoring the potential left-bearing that the first
non-zero-width glyph has.
Task-number: QTBUG-113679
Pick-to: 6.6
Change-Id: I8e89a428acf5d0a3da0255c50778ccc773ff20e1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
On WASM, the shortcut triggering the dialog in textedit example
seemingly lets the event invoke the default action. What really happens
is that the dialog's exec() does not return and WASM does not have a
chance to set preventDefault() on the keyboard event it receives. This
masks other problems with keyboards shortcuts.
Uses of exec() on message boxes were replaced, too. Closing operation
is now performed in two steps, first the event is ignored and maybeSave
is called to query for potential changes of the text document.
If there are no changes or the file is discarded, the close continues
with a second event, now accepted.
PrintDialog::exec(), QPrintPreviewDialog::exec(), QFileDialog::exec()
were also eliminated in favor of open().
Finally, indirect calls to exec() via QColorDialog::getColor were
removed.
Task-number: QTBUG-76587
Change-Id: Ia90fad46ec3f94244723512be3ec93b64df9d9ef
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
The lack of 0x adornment made hex confusing. `xinput list` shows device
IDs as decimal, and device IDs appear in decimal in some categorized
qt.qpa.input.devices log messages, so let's be consistent here too.
Also fixed one more that was inconsistent in that category:
"scroll event from unregistered device <x>"
Change-Id: I98a39b30b1bc030611d3cfe9dd5e95886faf48ff
Pick-to: 6.5 6.6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We want to pass the QPointingDevice* because we've already identified
it by its "system ID" (xinput device number). The other versions of
handleTabletEnterProximityEvent and handleTabletLeaveProximityEvent
try to identify the stylus by only its deviceType, pointerType and
unique ID, which can go wrong if there are multiple tablet devices and
the unique ID is not provided (as with N-trig and Wacom tablets being
used at the same time). Anyway this fixes a TODO comment from
6589f2ed0c
Leave a "deprecated" comment by the QWSI functions that should not
be used.
Pick-to: 6.6 6.5
Task-number: QTBUG-104878
Change-Id: Id9f19c60b54b7900b02d5f87b5d12f9a9189721d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a dock widget is hovered over a QDockWidgetGroupWindow, a gap item
is inserted at its potential docking position. Since only one item at a
time can be moved with the mouse, only one such gap item can exist.
QDockAreaLayoutInfo::insertGap() therefore contains an assertion, that
kicks in if a second gap item is inserted.
QDockWidgetGroupWindow::hover() checks if the dock widget is hovered
over a gap item. If that is the case, no additional gap item is
inserted. The check fails if a gap item exists in the group window, but
the dock widget is hovered over another part of that group window.
This can be the case if the group window already contains more than
one dock widget: By inserting the gap, the group window's size changes,
one of the existing dock widgets receives another hover event and a
second gap insertion is attempted.
This patch adds QDockAreaLayoutInfo::hasGapItem() to check if a gap
already exists. The method is queried in addition to prevent a second
gap insertion.
An autotest has not been added, because gap items appear and disappear
during hovering. The improved functionality can be tested manually with
the mainwindow example.
Fixes: QTBUG-112491
Fixes: QTBUG-114542
Pick-to: 6.6 6.5
Change-Id: I9ea64e729873a86eb98ea950fbb066817fc25a07
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QDockAreaLayout items can be widgets, gap or placeholder items.
They appear and disappear during hovering.
This adds a debug operator to make troubleshooting easier.
Task-number: QTBUG-114542
Task-number: QTBUG-112491
Pick-to: 6.6 6.5
Change-Id: I0fa5d3c96ab91838f28ad7cec3c049fd39f47576
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QObjectPrivate::getPropertyAdaptorSlotObject called
connectionsForSignal.
Calling this function is only safe after it has been ensured beforehand that the vector has size > signalIndex. As getPropertyAdaptorSlotObject
is not supposed to modify the vector, it does not resize the vector and it could consequently end up with an out-of-bounds read.
To avoid that issue, we instead first check if the vector can
potentially contain an entry for the signal. If not, we simply return
nullptr, and avoid the call to connectionsForSignal.
The issue and its fix can be verified by running the modified
tst_qproperty test with ASAN enabled. The test is modified in the
following way:
- We first create a signal connection to a dummy slot. Otherwise,
connections.loadRelaxed() would return a nullptr, and the problematic
code would never be reached.
- We add enough signals to ensure that the fooChanged signal will
actually be out of reach (which means >= 8 signals, as the initial
capacity of the vector is 8)
Running the test without ASAN will most likely not result in a failure,
as then the out-of-bounds read will simply read garbage, and the most
likely result is that the cast below will fail.
Pick-to: 6.6 6.5
Change-Id: I18a3c4f52769c2b6491a685abb84f6fcfb44e4d8
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
It is possible for an application to trigger the unexpected result of
NSModalResponseContinue from our call to NSAlert::runModal, by showing
and hiding a modal dialog first, and processing events explicitly. This
at best only flashes the native message box, at worst it triggers an
assert from our processResponse function evaluating that response value
as impossible (via Q_UNREACHABLE).
We should never call processResponse with NSModalResponseContinue,
but instead keep the modal loop running and the dialog visible.
So introduce a wrapper to NSAlert::runModal that keeps calling that
method until we get a result other than NSModalResponseContinue.
Writing an auto test for this failed; a simple test didn't reproduce the
assert; trying to place the opening of the native message box into a
lambda that would be called by the event loop (simulating the button
press from the bug report's reproducer) resulted in the native message
box never closing and the test blocking (and still not triggering the
assert).
Fixes: QTBUG-114546
Pick-to: 6.5 6.6
Change-Id: Iab25eff55c48b103287d1881ac355e6cdd190f7a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This property can take a either a WebAssembly.Module
or a promise to a module, and we don't have to specify
the exact type in the property name.
Pick-to: 6.6
Change-Id: Iebaf52178253afe8c93cf78bbe0853461bf48b67
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
This is required when using the preload functionality
from qtloader.
Pick-to: 6.6
Change-Id: Ib1bf8788b87834ba0ff80d563897040e093a16b9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Set `QT_COMMAND_LINE_PARSER_NO_GUI_MESSAGE_BOXES` before trying to run
qt tools for correctness. This is to suppress QCommandLinerParser from
showing a message box when console is not available.
Pick-to: 6.5.2 6.5 6.6
Task-number: QTBUG-114530
Change-Id: Ib3d264a799a5da1f620d2bebe55539bafc43da0f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an environment variable to be able to stop QCommandLinerParser
from showing GUI message boxes when console is not available.
Pick-to: 6.5.2 6.5 6.6
Task-number: QTBUG-114530
Change-Id: I52500a2177894bc0bf2d20f9723ce3e8fe87420f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The test checks whether correct windows get correct keyboard input,
having been activated with mouse clicks.
Also fixes the event propagation error found. Key events would propagate
to parent windows, which is something that should not happen with
window managers.
Change-Id: I18bae8c14cce5ccae151c2a00c84ffdba3b4587f
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
This works around around the difference in class-level [[nodiscard]]
behavior between Clang and GCC. While Clang already warns about
QClass(~~~args~~~);
when QClass is marked as [[nodiscard]] at the class level, GCC does
not, and requires the ctor to be marked as [[nodiscard]] instead.
Pick-to: 6.6
Fixes: QTBUG-104164
Change-Id: Ifd7076ee422fb9472ae8bbba43d9bfeee1968a78
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was used as a work-around for constructor-level [[nodiscard]]
missing in C++17, but a) compilers are free to implement [[nodiscard]]
for constructors in C++17 (P1771 was not considered a normative
change, just a clarification of the existing wording), and b) prevents
useful code that returns such types from functions.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I440b418d58e86118e84689adb06d239ca598afcc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Spack, like VcPkg, sets the `CMAKE_FIND_FRAMEWORK` to `LAST`, as a
result, similar to VcPkg, when Spack is used, FindGSSAPI opts for
`gssapi_krb5` which is not what we want. By dropping the `gssapi_krb5`
from the list of alternative names we can resolve this without much
tinkering with internals of these package managers.
Pick-to: 6.5 6.6
Fixes: QTBUG-114537
Change-Id: If517c409511f58e3bed78316a2030393dc249a40
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
There are unused variable warnings which cause the compilation to
fail when Werror is used in qpermissions_wasm.cpp
Change-Id: I2cf2035f52f0a5d570a56dcd4c82bf2ecf3006c7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
When QXcbConnection::xi2SetupDevices() reacts to a device hierarchy
event and re-discovers an already-known slave device, it doesn't call
xi2SetupSlavePointerDevice() again. I.e. it won't attempt to add it to
m_touchDevices or m_tabletData because it was already known. So it
should not clear m_touchDevices or m_tabletData either, but only remove
the touch devices that are known to have disappeared. Tablet styli
normally come and go from proximity, so it's ok to avoid deleting the
corresponding device data.
Also fix some other failure cases after testing hotplugging more with
tests/manual/inputdevices: there should be no crashes, no duplicated
devices after plugging (although the QAIM might have a bug that makes
it look that way), no leftover instances after unplugging.
Amends 2a9d93efc6
Pick-to: 6.6 6.5 6.5.2
Fixes: QTBUG-114334
Change-Id: I30f5e532f7dd3a465d56ecdd34d893cbadbf0453
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Right-clicking in a QKeySequenceEdit opens the usual context menu for a
line edit, which generates a focusOut event. QKeySequenceEdit finishes
the recording when it loses focus, which includes deselecting the text.
We should not finish or deselect if the focusOut event has focusReason
FocusReasonPopup, as otherwise users cannot copy the text (keyboard
shortcuts don't work for that, obviously).
Pick-to: 6.6
Task-number: QTBUG-114624
Change-Id: I0b3c535c189151daa29cf17640493f3353e6394b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Like commit 91f6460aff which added support
for Windows, this commit does the same for our final major OS.
The Darwin kernel exposes a set of __ulock_{wait,wait2,wake} APIs [1],
but these APIs are marked as private, so we cannot rely on them being
stable, nor we can use these APIs in builds of Qt intended for
the Apple App Store. By wholesale disabling the use of the APIs
in App Store compliant builds, and runtime checking availability
of the APIs when we do build them in, we should be safe, unless
the semantics of the APIs change in ways we haven't accounted for,
but that's a risk we're willing to take.
Note that libc++ uses these private APIs to implement P1135R5
(the C++20 synchronization library) [2], but that use is under
a "special permission" from the Darwin team, and meant only for
use in the Apple vendored version of libc++ shipped with their
operating systems, where they control both the kernel and the
standard library.
[1] https://github.com/apple-oss-distributions/xnu/blob/xnu-8792.81.2/bsd/sys/ulock.h
[2] https://reviews.llvm.org/D68480.
Change-Id: Ib709fc1585f647a98d54fffd16663b4965458404
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Warning C4275 non dll-interface class 'QJsonValueConstRef' used as base for dll-interface class 'QJsonValueRef' UniRemoteAdapter C:\qt\Qt6.5.1\6.5.1\msvc2019_64\include\QtCore\qjsonvalue.h 219
Pick-to: 6.5 6.6
Fixes: QTBUG-114629
Change-Id: I443cf0c8a76243eead33fffd176930f96c43eb47
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Fixes an issue with generated code where the name of an enclosing
namespace is identical to an enum class type, when Q_ENUM_NS is used.
Consider:
namespace a {
Q_NAMESPACE
namespace b {
enum class b { Key, Key2 };
Q_ENUM_NS(b);
}
}
moc generated code such as:
Q_CONSTINIT const QMetaObject a:🅱️:staticMetaObject = { {
...
qt_incomplete_metaTypeArray<qt_meta_stringdata_CLASSaSCOPEbENDCLASS_t,
// enum 'TestEnum'
QtPrivate::TypeAndForceComplete<b::b, std::true_type>,
// Q_OBJECT / Q_GADGET
QtPrivate::TypeAndForceComplete<void, std::true_type>
>,
nullptr
} };
which confused the compiler:
error: ‘b’ is not a member of ‘a:🅱️:b
83 | QtPrivate::TypeAndForceComplete<b::b, std::true_type>,
Fixes: QTBUG-112996
Pick-to: 6.6
Change-Id: I37aee83c32efe96cc9d6c2bd0bdb9ba80bb7b8a7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The Freedesktop Icon Theme Specification [1] describes that,
if a theme does not specify anything for its 'Inherits' key,
"implementations are required to add the 'hicolor' theme to
the inheritance tree. An implementation may optionally add
other default themes in between the last specified theme and
the hicolor theme."
And later, when describing the lookup algorithm, that "The
lookup is done first in the current theme, and then recursively
in each of the current theme's parents, and finally in the
default theme called 'hicolor' (implementations may add more
default themes before 'hicolor', but 'hicolor' must be last)".
But it doesn't explicitly describe the behavior when a theme
does specify a list of inherited themes via the 'Inherits' key,
and this list explicitly includes 'hicolor'.
In that case, our custom fallback theme, which we inject after
the theme's explicit parents, will be prioritized after 'hicolor'.
As it's likely that the theme author added 'hicolor' to their
parent list to ensure that 'hicolor' is at some point consulted,
but didn't intent it to be priorized, and that the spec puts focus
on 'hicolor' being last, it seems reasonable that we can move the
'hicolor' theme to the end of the fallback list, and as a result
always prioritize fallbackThemeName() over 'hicolor'.
[ChangeLog][QtGui][QIcon] The 'hicolor' theme will now always be
prioritized last when looking up fallback themes, even if
explicitly declared as a theme parent in a theme.
[1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
Pick-to: 6.6
Change-Id: I76538e4e7e9e395f9e5a38e704c60fb6b9688885
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
We still need to consult fallbackThemeName() when computing the
parent list for an individual theme, as the Freedesktop Theme Icon
spec mandates that the "hicolor" theme comes last, but we no longer
need to do explicit fallback to fallbackThemeName() if a theme is
not found.
Pick-to: 6.5 6.6
Change-Id: I6c0b5a45d8258c5b6eaa761402944a735b1606ba
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The use of fallback icons should not depend on a theme being set.
[ChangeLog][QtGui][QIcon] QIcon::fallbackSearchPaths() will now be consulted
for fallback icons even if the current theme name is empty.
Pick-to: 6.5 6.6
Change-Id: Ia8d14062de7c53601fd9dac30f87a9e672aa2207
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
So that building only tst_qprocess also builds the required test app.
Change-Id: I19a92f9dd2f4de08302d09cad0caf55c285a6dae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
My fault, I had added that bit of the docs a while ago.
Pick-to: 6.6
Change-Id: I1fa2c10b0f7263e12b5b2a4d18f362c702f9d831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
