Three methods parsing strings as numbers claimed not to fall back on
the C locale. In fact, the parsing is somewhat lenient and has long
accepted the digits and signs of the C locale's representations, along
with the U+2212 minus sign, regardless of locale.
The phrasing also tacitly suggested the matching QString function did
fall back to C locale; when, in fact, it (since 6.0) *exclusively*
uses the C locale. So that was misleading, too.
Change-Id: Ida3f2f23b834ced5150bea20d8716756afd48e91
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qhashfunctions.h defines a catch-all 2-arguments qHash(T, seed)
in order to support datatypes that implement a 1-argument overload
of qHash (i.e. qHash(Type)). The catch-all calls the 1-argument
overload and XORs the result with the seed.
The catch-all is constrained on the existence of such a 1-argument
overload. This is done in order to make the catch-all SFINAE-friendly;
otherwise merely instantiating the catch-all would trigger a hard error.
Such an error would make it impossible to build a type trait that
detects if one can call qHash(T, size_t) for a given type T.
The constraint itself is called HasQHashSingleArgOverload and lives in a
private namespace.
It has been observed that HasQHashSingleArgOverload misbehaves for
some datatypes. For instance, HasQHashSingleArgOverload<int> is actually
false, despite qHash(123) being perfectly callable. (The second argument
of qHash(int, size_t) is defaulted, so the call *is* possible.)
--
Why is HasQHashSingleArgOverload<int> false?
This has to do with how HasQHashSingleArgOverload<T> is implemented: as
a detection trait that checks if qHash(declval<T>()) is callable.
The detection itself is not a problem. Consider this code:
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
class MyClass {};
size_t qHash(MyClass);
static_assert(HasQHashSingleArgOverload<MyClass>); // OK
Here, the static_assert passes, even if qHash(MyClass) (and MyClass
itself) were not defined at all when HasQHashSingleArgOverload was
defined.
This is nothing but 2-phase lookup at work ([temp.dep.res]): the
detection inside HasQHashSingleArgOverload takes into account the qHash
overloads available when HasQHashSingleArgOverload was declared, as well
as any other overload declared before the "point of instantiation". This
means that qHash(MyClass) will be visible and detected.
Let's try something slightly different:
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
size_t qHash(int);
static_assert(HasQHashSingleArgOverload<int>); // ERROR
This one *does not work*. How is it possible? The answer is that 2-phase
name lookup combines the names found at definition time with the names
_found at instantiation time using argument-dependent lookup only_.
`int` is a fundamental type and does not participate in ADL. In the
example, HasQHashSingleArgOverload has actually no qHash overloads to
even consider, and therefore its detection fails.
You can restore detection by moving the declaration of the qHash(int)
overload *before* the definition of HasQHashSingleArgOverload, so it's
captured at definition time:
size_t qHash(int);
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
static_assert(HasQHashSingleArgOverload<int>); // OK!
This is why HasQHashSingleArgOverload<int> is currently returning
`false`: because HasQHashSingleArgOverload is defined *before* all the
qHash(fundamental_type) overloads in qhashfunctions.h.
--
Now consider this variation of the above, where we keep the qHash(int)
overload after the detector (so, it's not found), but also prepend an
Evil class implicitly convertible from int:
struct Evil { Evil(int); };
size_t qHash(Evil);
template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */;
size_t qHash(int);
static_assert(HasQHashSingleArgOverload<int>); // OK
Now the static_assert passes. HasQHashSingleArgOverload is still not
considering qHash(int) (it's declared after), but it's considering
qHash(Evil). Can you call *that* one with an int? Yes, after a
conversion to Evil.
This is extremely fragile and likely an ODR violation (if not ODR, then
likely falls into [temp.dep.candidate/1]).
--
Does this "really matter" for a type like `int`? The answer is no. If
HasQHashSingleArgOverload<int> is true, then a call like
qHash(42, 123uz);
will have two overloads in its overloads set:
1) qHash(int, size_t)
2) qHash(T, size_t), i.e. the catch-all template. To be pedantic,
qHash<int>(const int &, size_t), that is, the instantiation of the
catch-all after template type deduction for T (= int)
([over.match.funcs.general/8]).
Although it may look like this is ambiguous as both calls have perfect
matches for the arguments, 1) is actually a better match than 2) because
it is not a template specialization ([over.match.best/2.4]).
In other words: qHash(int, size_t) is *always* called when the argument
is `int`, no matter the value of HasQHashSingleArgOverload<int>. The
catch-all template may be added or not to the overload set, but it's
a worse match anyways.
--
Now, let's consider this code:
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
This code compiles, although we do not define any qHash overload
specifically for enumeration types (nor one is defined by MyEnum's
author).
Which qHash overload gets called? Again there are two possible
overloads available:
1) qHash(int, size_t). E1 can be converted to `int` ([conv.prom/3]),
and this overload selected.
2) qHash(T, size_t), which after instantiation, is qHash<MyEnum>(const
MyEnum &, size_t).
In this case, 2) is a better match than 1), because it does not require
any conversion for the arguments.
Is 2) a viable overload? Unfortunately the answer here is "it depends",
because it's subject to what we've learned before: since the catch-all
is constrained by the HasQHashSingleArgOverload trait, names introduced
before the trait may exclude or include the overload.
This code:
#include <qhashfunctions.h>
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
static_assert(HasQHashSingleArgOverload<MyEnum>); // ERROR
will fail the static_assert. This means that only qHash(int, size_t) is
in the overload set.
However, this code:
struct Evil { Evil(int); };
size_t qHash(Evil);
#include <qhashfunctions.h>
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
static_assert(HasQHashSingleArgOverload<MyEnum>); // OK
will pass the static_assert. qHash(Evil) can be called with an object of
type MyEnum after an user-defined conversion sequence
([over.best.ics.general], [over.ics.user]: a standard conversion
sequence, made of a lvalue-to-rvalue conversion + a integral promotion,
followed by a conversion by constructor [class.conv.ctor]).
Therefore, HasQHashSingleArgOverload<MyEnum> is true here; the catch-all
template is added to the overload set; and it's a best match for the
qHash(E1, 42uz) call.
--
Is this a problem? **Yes**, and a huge one: the catch-all template does
not yield the same value as the qHash(int, size_t) overload. This means
that calculating hash values (e.g. QHash, QSet) will have different
results depending on include ordering!
A translation unit TU1 may have
#include <QSet>
#include <Evil>
QSet<MyEnum> calculateSet { /* ... */ }
And another translation unit TU2 may have
#include <Evil>
#include <QSet> // different order
void use() {
QSet<MyEnum> set = calculateSet();
}
And now the two TUs cannot exchange QHash/QSet objects as they would
hash the contents differently.
--
`Evil` actually exists in Qt. The bug report specifies QKeySequence,
which has an implicit constructor from int, but one can concoct infinite
other examples.
--
Congratulations if you've read so far.
=========================
=== PROPOSED SOLUTION ===
=========================
1) Move the HasQHashSingleArgOverload detection after declaring the
overloads for all the fundamental types (which we already do anyways).
This means that HasQHashSingleArgOverload<fundamental_type> will now
be true. It also means that the catch-all becomes available for all
fundamental types, but as discussed before, for all of them we have
better matches anyways.
2) For unscoped enumeration types, this means however an ABI break: the
catch-all template becomes always the best match. Code compiled before
this change would call qHash(int, size_t), and code compiled after this
change would call the catch-all qHash<Enum>(Enum, size_t); as discussed
before, the two don't yield the same results, so mixing old code and new
code will break.
In order to restore the old behavior, add a qHash overload for
enumeration types that forwards the implementation to the integer
overloads (using qToUnderlying¹).
(Here I'm considering the "old", correct behavior the one that one gets
by simply including QHash/QSet, declaring an enumeration and calling
qHash on it. In other words, without having Evil around before including
QHash.)
This avoids an ABI break for most enumeration types, for which one
does not explicitly define a qHash overload. It however *introduces*
an ABI break for enumeration types for which there is a single-argument
qHash(E) overload. This is because
- before this change, the catch-all template was called, and that
in turn called qHash(E) and XOR'ed the result with the seed;
- after this change, the newly introduced qHash overload for
enumerations gets called. It's very likely that it would not give
the same result as before.
I don't have a solution for this, so we'll have to accept the ABI
break.
Note that if one defines a two-arguments overload for an enum type,
then nothing changes there (the overload is still the best match).
3) Make plans to kill the catch-all template, for Qt 7.0 at the latest.
We've asked users to provide a two-args qHash overload for a very long
time, it's time to stop working around that.
4) Make plans to switch from overloading qHash to specializing std::hash
(or equivalent). Specializations don't overload, and we'd get rid of
all these troubles with implicit conversions.
--
¹ To nitpick, qToUnderlying may select a *different* overload than
the one selected by an implicit conversion.
That's because an unscoped enumeration without a fixed underlying type
is allowed to have an underlying type U, and implicitly convert to V,
with U and V being two different types (!).
U is "an integral type that can represent all the enumerator values"
([dcl.enum/7]). V is selected in a specific list in a specific order
([conv.prom]/3). This means that in theory a compiler can take enum E {
E1, E2 }, give it `unsigned long long` as underlying type, and still
allow for a conversion to `int`.
As far as I know, no compiler we use does something as crazy as that,
but if it's a concern, it needs to be fixed.
[ChangeLog][Deprecation Notice] Support for overloads of qHash with only
one argument is going to be removed in Qt 7. Users are encouraged to
upgrade to the two-arguments overload. Please refer to the QHash
documentation for more information.
[ChangeLog][Potentially Binary-Incompatible Changes] If an enumeration
type for which a single-argument qHash overload has been declared is
being used as a key type in QHash, QMultiHash or QSet, then objects of
these types are no longer binary compatible with code compiled against
an earlier version of Qt. It is very unlikely that such qHash overloads
exist, because enumeration types work out of the box as keys Qt
unordered associative containers; users do not need to define qHash
overloads for their custom enumerations. Note that there is no binary
incompatibity if a *two* arguments qHash overload has been declared
instead.
Fixes: QTBUG-108032
Fixes: QTBUG-107033
Pick-to: 6.2 6.4
Change-Id: I2ebffb2820c553e5fdc3a341019433793a58e3ab
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I think we can remove the WARNING regarding AAT which was probably there
to avoid using older version. As far as I can tell, AAT is supported
from 2.0, and quite stable by now.
Task-number: QTBUG-107044
Change-Id: I8e6ba3f51b85e2859dd46435eee1220da46831d2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The fix for QTBUG-106277 appears to cause issues with older gcc versions
in C++2a mode (for instance used in our headers check).
Thus, use the old code for all non-MSVC compilers, which never had
problems with it.
Pick-to: 6.4 6.2
Fixes: QTBUG-108039
Change-Id: If6a0ce6e8f41e9dc752614557e96c555ca0fe75c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Compiling for android a certain configuration warns about comparisons
between types of different signedness.
On 32-bit we cannot cast the unsigned type to qsizetype and on x64
we cannot cast the qsizetype to Zlib's type (both potentially truncating).
So, cast both to size_t before comparing
Pick-to: 6.4 6.2
Change-Id: I0dd40c875b1a61a64f0574f0209a8549fc73164a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Process the regular SOURCES and DBus sources the same way in
the qt_internal_extend_target call. Previously the specified
COMPILE_FLAGS had no effect on DBus sources.
[ChangeLog][General] The internal DBus source files that are
generated, now are compiled with the same set of compilation
flags and options as other source files of the Qt module.
Change-Id: I9bdeb8f45c6af1b0cb0235425b0ff7efcb952d59
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extract function arguments to the corresponding variables and use
variables when parsing arguments. Remove whitespace between if keyword
and parentheses. Adjust size of code lines. Document function-specific
arguments.
Change-Id: I1c77fbf268618a844726683768575aff05894c70
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qml module is not found it doesn't make sense to run any
functionality that is related to Qml inside androiddeployqt. Add the
deployment setting option that indicates this explicitly and set it
to true when Qml module is not found by CMake or by qmake.
Task-number: QTBUG-106939
Pick-to: 6.4 6.2
Change-Id: I1e6cffbdd230007feffe7448617097c10238a6c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Doing so generates an error as this value for glEnable is
invalid with WebGL 2. The behavior is always as if this
was enabled. (unlike in GLES 3)
Task-number: QTBUG-107780
Pick-to: 6.4
Change-Id: I3fc34329fc573a6fac8e4265d90ca93520e4e2ee
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
The code called setEditFocus, which no longer exists anywhere in Qt.
Change-Id: Icd02b8d8b204819188e090e7462309e5c5a5b3d6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If we use winrt's factories we have to make sure to to clear the factory
cache when one of our dlls is unloaded or we will run into dangling
factory entries which might result in crashes. So we have to make sure
that winrt::clear_factory_cache is called on every dll unload.
In order not to increase compile times and dependencies too much
qfactorycacheregistration_p.h needs to be included in Qt code whenever
we use winrt's factory cache. A rule of thumb being: Include
qfactorycacheregistration_p.h whenever including winrt/base.h.
Other Qt modules which use winrt's factories need to be updated too.
Fixes: QTBUG-103611
Pick-to: 6.2 6.4
Change-Id: I7ab24e4b18bffaca653c5b7f56a66ce99212e339
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Short of expanding Qt Test Best Practices to have a section about
QEXPECT_FAIL, we can link to some existing documentation that briefly
covers it.
Pick-to: 6.2 6.4
Change-Id: I37bf2672e4b5b6e7315e009f86d03eeb7937d50e
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
SQLite's configure enables, by default, more options than the ones that
we enabled in our bundled copy of SQLite. Add the necessary defines
to reach feature parity, namely support for MATH functions, GEOPOLY and
FTS4.
[ChangeLog][Third-Party Code] SQLite shipped with Qt now supports
FTS4, the mathematical functions and the Geopoly interface.
Change-Id: Iaed93fa1994a4c14c0990fab18d7a6e3e67af1e4
Fixes: QTBUG-108016
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
The current code can't distinguish between Windows 10 and Windows 11,
this patch fixes that.
Change-Id: I8269f0544c09205ae9845b7981f4a86c664bee09
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is a level A SIC, as it breaks
QFile f = "/some/path";
In general, it's not a good idea to have this implicit conversion. A
QFile is not a representation of a path, so the conversion should be
explicit.
I am going to keep the current semantics (implicit conversion) up to and
including Qt 6.8 (LTS). Starting from 6.9, the constructor will be
unconditionally explicit. This is deliberate, and done in order to make
users fix their code while staying in Qt 6, rather than encountering
this issue (and countless many more) if and when they upgrade from Qt 6
to Qt 7. In the meanwhile, users can opt-in to the new semantics by
defining a macro.
[ChangeLog][QtCore][QFile] The QFile constructors that take a path are
going to become unconditionally `explicit` in Qt 6.9. Code like `QFile f
= "/path";` will need to be ported to equivalent one (e.g. `QFile
f{"/path/"}`). This has been done in order to prevent a category of
mistakes when passing strings or paths to functions that actually take a
QFile. Users can opt-in to this change even before Qt 6.9 by defining
the QT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH macro before including any
Qt header.
Change-Id: I065a09b9ce5d24c352664df0d48776545f6a0d8e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In 9ccbbeecbd we've added basic z-order handling, so main window
always stacks behind tool windows. After extensive testing we found
more basic cases to be handled:
- Modal windows go on top
- Qt::Popup goes on top of Qt::Tool
Fixes: QTBUG-105707
Pick-to: 6.4
Change-Id: I00eba330864c7abc31652226d55f66f4b7f44dc0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When the visual state of a QWindow changed, QGuiApplicationPrivate
sent an event to QWindow, where the visibility was updated and the
signal was emitted.
Following the pricinple of other visual updates, these actions have
been moved to QGuiApplicationPrivate.
Task-number: QTBUG-102478
Change-Id: I94f2f5b7570580ce422ca9dc03013742f6a9baba
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Some headers cannot be sent via XMLHttpRequest. In case one of those is
assigned to a network request, the header will now be trimmed on WASM so
that the request continues. Qt will print a warning on each request that
had its headers trimmed.
The list seems stable so it is not a lot of burden to sync Qt with it on
potential (unlikely) changes.
Fixes: QTBUG-95585
Change-Id: Id504ef43ad7e466ab567d4646d7ca00d6b7920d7
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Instead of using a local event loop, control the flashing through timers
and lambdas. Move the actual hiding of the popup then into a helper that
gets called when the flashing is done.
Note: this changes behavior -the popup will not be hidden when
hidePopup returns. And since events continue get processed during the
flashing effect, we might still get reentrancy (so the code added in
accc833e55 has to stay anyway).
Change-Id: I2ce20520dea16bd3be78544e9fdd059a2969a795
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It also fails for -no-feature-gui, but since the example depends on
QtWidgets, which implies depending on QtGui, we only check for
QtWidgets here.
Pick-to: 6.2 6.4
Change-Id: I777e540e6c2101ce8f08a5f80ba01b37ff858373
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some of the entries in QLocale's single_character_data[] table are
not, in fact, single characters; some RTL languages include
bidi-markers in some of the fields, some locales use some denotation
of "times ten to the power" as the exponent separator. There may be
further complications, but let's just get some tests in that verify we
are correctly serializing numbers in these locales. Include some
parsing tests to show that we are indeed failing them.
Task-number: QTBUG-107801
Change-Id: Iab9bfcea5fdcfcb991451920c9531e0e67d02913
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
%.f should be handled like %.0f. You probably don't want it for strings,
though.
Fixes: QTBUG-107991
Pick-to: 6.2 6.4
Change-Id: I07ec23f3cb174fb197c3fffd1721a941fbcf15e1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
What's now called TestMethods::invokeTest() was apparently once called
qInvokeTestMethod(). Also, its current instance is (now) cleared by
its destructor rather than (overtly) at the end of that function.
Change-Id: I04de7ca2247dd640a398b3e4e7bf410401f3cbbf
Reviewed-by: Jason McDonald <macadder1@gmail.com>
That's what we initially did for borderless windows and we need it in order
to draw rounded corners for context menus.
Pick-to: 6.4 6.2
Fixes: QTBUG-106108
Change-Id: I6e4254b714ad7a094aa295546d5ac7fba5e21b13
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
As of 3fcdb6cb6e we now have a hidden
Window menu, which results in macOS also populating the Dock menu
with the application's windows.
But since the AppKit logic for populating the window menu happens when
the window is shown, and we create the menu after many windows have
been already shown, we had a workaround to add the shown windows
manually.
Unfortunately this workaround didn't take into account the NSWindow
excludedFromWindowsMenu property, nor did it include various other
checks that AppKit itself uses to decide if a window should be
included in the window list, resulting in adding the NSStatusBarWindow
that AppKit uses to manage the status bar items.
Instead of trying to replicate the AppKit logic, we toggle the
excludedFromWindowsMenu property back and forth, which triggers
AppKit to reevaluate the situation for each window, and add it
to the window menu if necessary.
Fixes: QTBUG-107008
Pick-to: 6.4
Change-Id: I6c7f61c1f4610fec9ce1f814fcea2b6140230602
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit a43845b75a.
Reason for revert: As I can see from the pictures generated by the tests, the scroll bar now looks significantly worse and wrong.
Change-Id: I454b316b844839ebfc3f44633348e527e2a30f34
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
I'm not entirely sure whether this is a toolchain bug or if this is
intended. This commit ODR-uses all the static inline variables in
QOperatingSystemVersion so they are added to the list of exported
symbols in QtCore.
On Windows:
$ objdump -p bin/Qt6Core.dll | grep Windows11E
[2534] _ZN23QOperatingSystemVersion9Windows11E
On Linux:
$ eu-readelf --dyn-syms lib/libQt6Core.so | grep Windows11E
1985: 0000000000575430 16 OBJECT GNU_UNIQUE PROTECTED 18 _ZN23QOperatingSystemVersion9Windows11E@@Qt_6
Pick-to: 6.4
Change-Id: Ia317fd249bcd80dbd02c198803a3a61178c0c219
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It might not matter as far as I understand, but having it saved as BOOL
is better if it's a boolean.
Change-Id: If35485425257ca5518f0f8a49ca5353b9ac875a8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It is not necessary to disable the thread-based drm event reading
(QT_QPA_EGLFS_KMS_NO_EVENT_READER_THREAD) anymore when using screen
cloning.
Amends 8207751661 and
14bb413309
Note that this does not work when atomic commits are enabled. (i.e.
running with QT_QPA_EGLFS_KMS_ATOMIC=1 and attempting to use screens
that clone will not function as expected, regardless of which event
reading method is used - that needs a rework of how atomic requests
are handled, and is not something we are going to invest into given
that atomic is not even used by default)
Pick-to: 6.4
Fixes: QTBUG-91882
Change-Id: Iba83688c7790d7e721db3704d422034b654a8d8a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
FindWrapSystemMd4c now uses `find_package_handle_standard_args` like
all the other similar modules. This also fixes a case where CMake config
log for finding `md4c` was missing the CMAKE_MESSAGE_CONTEXT,
e.g., `[QtBase]`, which was caused by using `find_package` and let it
log outside the scope of the project, and not `QUIET`ing it.
In addition, the `CONFIG` parameter of the `find_package` was removed to
avoid unexpected issues when 3rd party package managers were used.
Change-Id: Id0bee436e8965452f9089c0e8c8793c3f1b63f02
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch avoids synthesizing mouse messages in the QPA for touch/pen
input, and lets the GUI do mouse event synthesis for unhandled touch/pen
events, if required, like in other platforms. This requires a workaround
to avoid breaking drag and drop with touch/pen (or making it worse). DnD
on Windows is based on the DoDragDrop() Win32 API, which does not work
with touch/pen input, which in some cases cause a DnD operation started
with touch/pen to hang until the mouse is moved. To avoid it we process
pointer messages for touch/pen and generate mouse input through
SendInput() to trigger DoDragDrop(), which then seems to work as
expected.
So now we inform QtGui that the Windows platform no longer sends
synth-mouse events after tablet events (unsetting the flag added in
f931e5e72d); this completes what was
attempted in 8ada0633cd.
Fixes: QTBUG-106368
Fixes: QTBUG-57577
Fixes: QTBUG-100788
Task-number: QTBUG-77414
Task-number: QTBUG-104594
Pick-to: 6.4 6.3 6.2
Change-Id: I46db3c74be2a95cf2d94ba930398e58dc930d2db
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
It seems the value name correction is not needed at all,
and we must not do such correction.
Amends commit 738e05a55a
Task-number: QTBUG-107794
Change-Id: I903a762aafab4b55275beb8438e6769285821567
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We have done the same thing when calling SetProcessDpiAwareness(),
but it's also needed for SetProcessDpiAwarenessContext(), otherwise
there will always be a warning message when the user uses a manifest
file to set the DPI awareness mode for the application (which is highly
recommended by Microsoft).
Pick-to: 6.4
Change-Id: I31894d41c89581b6edd7826cb3dabad492f6c2a8
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Currently we have a narrow version entry point, add a wide
version entry point as well, make them share exactly the same
implementation. The linker can choose the appropriate entry point
during linking.
The linker will always try to use wWinMain as the entry point
function if the UNICODE/_UNICODE macros are passed to it and
this will cause compilation failures without a wWinMain
implementation. This patch fixes such issue, though it usually
won't happen in most cases.
Change-Id: I7bc22d5bdc1cf35514a335a280a9f18732531b25
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use the minimum of "len" and "size() - pos", logically we'll only ever
remove characters up-to the end of the array.
This eliminates one if branch, and d->erase() can handle all the use-cases.
After making this change I looked at QByteArray::remove() and it has
similar logic, so it should be correct™.
Change-Id: Ife6c552f8a3f3dda1d5a1da12b80a60790f3bae4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Added command line option for passing core5compat module in windeployqt
Task-number: QTBUG-104845
Pick-to: 6.2 6.4
Change-Id: I6a0e13532edac4580e03d83be79f7db4ac54e3bf
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
To make it look more natural (without outline and with proper colors).
Otherwise this thing looks bad in both Aqua and Dark themes -
can be seen if scrollbars always shown (this option is set in "General"
settings).
Tried so far:
- not to draw this element at all - gives a visible hole in the corner
- ask the horizontal bar to render its knob track a bit longer (resetting
a clip properly) - gives a weird side-effect when scrolling in Dark
mode + unfortunately outline of a track is still visible (it overlaps
the vertical bar's track).
Alas, good old hardcoded colors/alpha values as a last resort.
PE_Frame had -1,-1 adjustment, making a frame line visible in the
corner below scrollbars, giving another strange effect.
Fixes: QTBUG-106927
Change-Id: Ie0367c3bd6f40b3fa4ca6afac09f27e446fc007d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Some modules may have header files that do not pass headersclean check
under some conditions. It's nice to have an option in the
qt_internal_add_module function to disable the check for the modules of
this kind. At the moment this flag is useful for the ActiveQt module,
since it syncs and installs header files that don't belong to it.
Amends b89d63515b
Task-number: QTBUG-103196
Change-Id: I21a82d50d50bdac225ed483ab0cc50339c2a4873
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since QtAutoDetect is called before the project, we still don't have
access to our IOS, WATCHOS, TVOS variables, and we must use
CMAKE_SYSTEM_NAME variable instead.
Pick-to: 6.4
Change-Id: I61afe216baec85b3fcd489957f4b6774134f8078
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
