Setting the flag QSurfaceFormat::StereoBuffers does not actually do
anything, because we do not utilize the extra buffers provided. We need
to expose setting the correct buffers using glDrawBuffers between draw
calls.
Change-Id: I6a5110405e621030ac3a2886fa83df0cfe928723
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Flushing the queued paint events will bump numRepaints, and the whole
point of calling reset() is to prepare a consistent state before the
next test, so we need to call it after flushing the events.
Pick-to: 6.2 6.4
Change-Id: Iaefc9854caafe82c65c9587e18fd081439e8dda6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The qfiledialog test was failing on completer_data test. The fix
available for Android 11 also works in Android 7, so removed the if
clause.
Task-number: QTBUG-105377
Change-Id: I76a4c1073a754c9b299cfe731f42b80da1a6f8e2
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It may take some time before the shown window is available through the
accessible hierarchy, so do an asynchronous test for that to happen.
Pick-to: 6.4
Change-Id: I3f312ae636505b805899973678b1bf10a65f96b3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There's no need to split it, we can use the -x compiler flag to build
the .cpp file as Objective-C++, or, as done here, just rename the file.
This allows us to use QVERIFY and friends, giving more precise failure reporting.
Pick-to: 6.4
Change-Id: I6fb1c4454335082c8a39010c5b75c59e6ec6561b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When a compound widget is created not directly before its children,
then another widget will be in the focus chain between the compound and
the compound's first child. If one of those children is then made the
focus proxy of the compound, then the widget in between becomes
unreachable by tabbing.
To fix this, detect that we set the focus proxy to be a descendent of
the compound widget, and then move the compound widget directly in front
of its first child in the focus chain. This way we can't have any gaps
in the focus chain.
Augment the test case with a corresponding scenario. As a drive-by, move
the debug helper up in the code so that it can be easier used, and set
object names on relevant widgets.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-89156
Change-Id: I17057719a90f59629087afbd1d2ca58c1aa1d8f6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Basic unitttest and one to verify erase returns iterator, not
const_iterator.
Change-Id: I44c3b82b4686ff3809648063376f5e36fb7e181d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- If the string isn't shared, don't call detach(), instead remove characters
matching ch, and resize()
- If the string is shared, create a new string, and copy all characters
except the ones that would be removed, see task for details
Update unittets so that calls to this overload of remove() test both code
paths (replace() calls remove(QChar, cs) internally).
Drive-by change: use QCOMPARE() instead of QTEST()
Task-number: QTBUG-106181
Change-Id: I1fa08cf29baac2560fca62861fc4a81967b54e92
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- If this bytearray isn't shared call d->erase() as needed
- if it's shared, instead of detaching, create a new bytearray, and copy
all characters except for the ones that would be removed
See task for details.
Adjust unittest to test both code paths.
Task-number: QTBUG-106182
Change-Id: I806e4d1707004345a2472e056905fbf675f765ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 79a11470f3, which
resulted in QTBUG-105735. The new behavior is worse and affects multiple
screen readers, while the old issue is isolated to Windows Narrator and
could be considered a narrator bug.
Task-number: QTBUG-105735
Pick-to: 6.2 6.4
Change-Id: Ic8be1dbd592a3fdf2c3219ec4c5524bc2c7f0f6a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When submitting applications to the iOS and macOS AppStore the
application goes through static analysis, which will trigger on
uses of various privacy protected APIs, unless the application
has a corresponding usage description for the permission in the
Info.plist file. This applies even if the application never
requests the given permission, but just links to a Qt library
that has the offending symbols or library dependencies.
To ensure that the application does not have to add usage
descriptions to their Info.plist for permissions they never
plan to use we split up the various permission implementations
into small static libraries that register with the Qt plugin
mechanism as permission backends. We can then inspect the
application's Info.plist at configure time and only add the
relevant static permission libraries.
Furthermore, since some permissions can be checked without any
usage description, we allow the implementation to be split up
into two separate translation units. By putting the request in
its own translation unit we can selectively include it during
linking by telling the linker to look for a special symbol.
This is useful for libraries such as Qt Multimedia who would
like to check the current permission status, but without
needing to request any permission of its own.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
- If this string isn't shared, don't call detach, instead use ->erase() as
needed
- If this string is shared, create a new string, and copy all elements
except the ones that would be removed, see task for details
Update unittest to test both code paths.
Task-number: QTBUG-106181
Change-Id: I4c73ff17a6fa89ddcf6966f9c5bf789753f6d39e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When 'this' is IPv6 and 'other' is Any then there is no point in testing
'other's IPv6 address.
Added extra tests against QHostAddress::Any*.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-108103
Change-Id: I09f32b1b147b1ec8380546c91cd89684a6bebe2e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With the introduction of QAnyStringView, overloading based on UTF-8
and Latin-1 is becoming more common. Often, the two overloads can
share the processing backend, because we're only interested in the
US-ASCII subset of each.
But if they can't, we need a faster way to convert L1 into UTF-8 than
going via UTF-16. This is where the new private API comes in.
Eventually, we should have the converse operation, too, to complete
the set of direct conversions between the possible three
QAnyStringView encodings L1/U8/U16, but this direction is easier to
code (there are no error cases) and more immediately useful, so
provide L1->U8 alone for now.
Change-Id: I3f7e1a9c89979d0eb604cb9e42dedf3d514fca2c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Borrowed from tst_qtemporaryfile with some changes.
Change-Id: I596ddd0ac8dbe10edd63e481198064dcec15d3e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Many features of today's devices and operating systems can have
significant privacy, security, and performance implications if
misused. It's therefore increasingly common for platforms to
require explicit consent from the user before accessing these
features.
The Qt permission APIs allow the application to check or request
permission for such features in a cross platform manner.
The check is always synchronous, and can be used in both
library and application code, from any thread.
The request is asynchronous, and should be initiated from
application code on the main thread. The result of the request
can be delivered to lambdas, standalone functions, or
regular member functions such as slots, with an optional
context parameter to manage the lifetime of the request.
Individual permissions are distinct types, not enum values,
and can be added and extended at a later point.
Task-number: QTBUG-90498
Done-with: Timur Pocheptsov <timur.pocheptsov@qt.io>
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I821380bbe56bbc0178cb43e6cabbc99fdbd1235e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
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>
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>
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>
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 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>
This amends 23780891a5 which moved the.txt
test to tets/auto/corelib/platform/android and kept the old location
mistakenly.
Pick-to: 6.4 6.2
Change-Id: If58422f9a94cfe4d6a941cc5453d8f0506057dcb
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Removes a warning in the build.
Pick-to: 6.4
Change-Id: I07ec23f3cb174fb197c3fffd17215c40b40333cb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The `rcc_PREFIX` will be set to `/` if it is not passed to the
function and it is not defined in `QT_RESOURCE_PREFIX`.
I also removed an unnecessary check of the `rcc_PREFIX`.
[ChangeLog][QtCore][CMake] The `PREFIX` parameter of the
`qt_add_resources` is now optional. If not passed, and
`QT_RESOURCE_PREFIX` is not defined, `/` will be used as the path
prefix.
Fixes: QTBUG-104938
Change-Id: I6524ab5dc54f035272e4c2e3154eb67591efb650
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
With -no-feature-sql, CMake would error out because the target Qt6::Sql
didn't exist. Fix this by checking if the target exists.
Task-number: QTBUG-102480
Pick-to: 6.2 6.3 6.4
Change-Id: I411631acfd336ea699833954f86711067d160c04
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Interesting on its own just because it exercises stencil testing,
unlike any of the other existing manual tests.
In addition it serves as a base example for how outlines could be
done, it is one possible approach at least. (render with stencil
write, then render again slightly scaled up with a solid color with
testing against the stencil buffer content)
Change-Id: I0c845a9004136f229cab037f6f0aab2f772bdd76
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
This introduces a new helper function accessibleIdForAccessible
(inspired by Windows' automationIdForAccessible) to synthesize an id out
of the objectNames of the accessible parent chain. The id is then
exposed via the GetAccessibleId D-Bus function for consumption in a11y
tools.
Change-Id: If72b86c5864c43f4ca842aa11423dd8aea0dde4a
Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org>
We currently don't have any machinery for qmake or CMake to map
translations declared via TRANSLATIONS += or qt_add_translations
to the Info.plist CFBundleLocalizations key.
This results in macOS and iOS falling back to the development region,
CFBundleDevelopmentRegion, as the only supported localization of the
app, which is in most cases set to 'en'.
Unfortunately this doesn't work well with the behavior of iOS 11+
and macOS 10.13+ where the OS will set the locale of the app to
the best match between the app's supported localizations and the
user's preferred language.
https://developer.apple.com/library/archive/qa/qa1828/
Since we only support a single localization, the development region,
the locale always ends up as 'en_<REGION>', which after QTBUG-104930
is also reflected in the QLocale's uiLanguages(), resulting in the
QTranslator machinery always picking English translation for the app.
As long as we don't explicitly declare CFBundleLocalizations we need
to opt out of the system's behavior of finding the best match between
the app's declared localizations and the user's preferences, which we
can do via the CFBundleAllowMixedLocalizations key.
Fixes: QTBUG-63324
Pick-to: 6.4
Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QTreeView draws the different sub-rects of an item's background over
multiple calls to drawPrimitive(PE_PanelItemViewRow). The item row is
not separately stylable, but the item might have a styled background
property. To get a consistent background, we must use the item's
background rule when filling the item's row background.
To fix that, delegate the filling of the branch background to
drawPrimitive(PE_PanelItemViewRow), and implement PE_PanelItemViewRow
handling to render the rule for the ViewItem pseudo element if there is
a background rule defined for it.
Add a baseline test stylesheet for this scenario. Note that the selection
in an item view is better styled via the selection-background-color
qss property.
Task-number: QTBUG-73251
Task-number: QTBUG-106227
Pick-to: 6.4 6.2
Change-Id: I5d0c170f78009fe5015dd749975e6df27485b3b8
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The fix for QTBUG-73251 in f4976f86cd
resulted in QTBUG-106227. Add baseline test coverage for the respective
configuration to make sure we don't regress.
Refactor mapping of index to configuration to make accessing of subitems
more robust.
Task-number: QTBUG-73251
Pick-to: 6.4 6.2
Change-Id: I530ecd67fa5663f219884f641bc5e25c7ac5fe73
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
MySQL has a different default setting for case sensitive table names on
linux and windows which makes the test fail on linux but work on
windows when using the database with the default settings. Read out the
respecitive setting so the test will pass every time.
Change-Id: I8651858d47652022ddc4b6386a6153cf70c6fed6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After f4976f86cd, alternate rows are no
longer painted all the way, as the code is never called for styles that
don't include the tree item decoration in the selection, such as the
Windows styles.
Add a baseline test to record the appearance of such trees.
Task-number: QTBUG-106227
Pick-to: 6.4 6.2
Change-Id: If21076393fdf65205cab91299f8e557dbe9c4ea9
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We have NTDDI_WIN10_NI (0x0A00000C) in the Win11 SDK (10.0.22621)
so bump the value in Qt (currently 0x0A00000B) to it.
And when searching for _WIN32_WINNT/WINVER/NTDDI_VERSION throughout
the whole qtbase codebase, I found some duplicated code, mostly
leftovers from the legacy time. Replace them with our own windows
header can achieve the same effect: we have defined all the necessary
macros to unblock the latest features. And place the header at the
top most place to include the macros as early as possible.
Change-Id: I37d9ac40ca9748208c7b2e89f374eda362dbefd6
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This is consistent with what $(DEVELOPMENT_LANGUAGE) reports, as well as
the Apple Locales Programming Guide which states that "Locale names such
as “English”, “French”, and “Japanese” are deprecated in OS X and are
supported solely for backward compatibility."
Pick-to: 6.4
Change-Id: I99779d678ef9d4ea90249572f2f977e9b4df6c62
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The QHoverEvent ctor takes two points: pos and globalPos; pos is then
passed as both the scene and global pos to the QSinglePointEvent ctor,
which calls QMutableEventPoint::setScenePosition() on the persistent
QEventPoint instance and then detaches befeore setting ephemeral state.
Therefore, we must construct QHoverEvent with scene position first, not
local position, so that the right value is persisted; it's better to set
local position after the detach(), whereas it's too late to fix the
persistent point then.
Pick-to: 6.4
Fixes: QTBUG-106918
Change-Id: I45726a9ec05bba2fe0cde6f5fb87c269105caca6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
-1 is the default value for QSurfaceFormat::alphaBufferSize. Changing it
to 0 may result an unexpected pixel format change by ARB OpenGL
extension.
Pick-to: 6.4
Fixes: QTBUG-107629
Change-Id: Ia6a1b90fba6c43b6872b406f4fd946d937135cf8
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The workaround stopped working because JSEvents is now not a global
object. Update the workaround by exporting the JSEvents object from
emscripten runtime and replacing the function that removes the
event handlers to a dummy function that does nothing temporarily, only
to revert it when the context is destroyed.
Fixes: QTBUG-107197
Pick-to: 6.4
Change-Id: Icceae884c85e04fdafcca6cf3c563094d3f6f0dc
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
There is no reason to use different style of quotes when printing
messages.
Change-Id: I7d513ec04c803702974054569d28f26947942fbf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
