Additional data should also be taken into account when using move
operator and function swap. This is already implemented for move
constructor.
Task-number: QTBUG-78544
Change-Id: I24ba34b0957a8fba7e15a934f2d08222dc95650f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The logic is now mostly handled in QGuiApplication, with QApplication
only dealing with the widget-specific palettes and interaction between
the style and the palette.
The application now picks up changes to the platform theme and will
re-resolve the current application palette appropriately. This also
works even if an explicit application palette has been set, in which
case any missing roles are filled in by the theme.
The palette can now also be reset back to the default application
palette that's fully based on the theme, by passing in the default
constructed palette (or any palette that doesn't have any roles set).
This is also correctly reflected in the Qt::AA_SetPalette attribute.
Conceptually this means QGuiApplication and QApplication follow the
same behavior as QWidget, where the palette falls back to a base or
inherited palette for roles that are not set, in this case the theme.
Behavior-wise this means that the default application palette of the
application does not have any roles set, but clients should not have
relied on this, nor does QWidget rely on that internally.
It also means that setting a palette on the application and then
getting it back again will not produce the same palette as set,
since the palette was resolved against the theme in the meantime.
This is the same behavior as for QWidget, and although it's a
behavior change it's one towards a more sane behavior, so we
accept it.
[ChangeLog] Application palettes are now resolved against the platform's
theme palette, the same way widget palettes are resolved against their
parents, and the application palette. This means the application palette
reflected through QGuiApplication::palette() may not be exactly the same
palette as set via QGuiApplication::setPalette().
Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
...but keep support for deserializing for all older versions in order to play
nice with existing .qsb files.
The usage of binary JSON and then CBOR is a historical artifact: relying
on the QJsonDocument (which we generate for purposes unrelated to binary
serialization) was a convenient shortcut. However, writing to and
reading from a QDataStream instead (which QShader already does) is trivial.
In order not to be limited by potential CBOR requirements in the future,
take it all into our own hands.
Extend the qshader autotest accordingly.
Task-number: QTBUG-81298
Change-Id: If0047b659bd6601ca47b5bbbce1b719630cde01e
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
This amends a1f4321bbb as the font
families should take precedence over the font family set. If the font
family is already included in the families then it should keep its
placement. Otherwise it should be appended.
Task-number: QTBUG-80475
Change-Id: I0049189c88b6879e57619815ec780960e9c0a300
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Conflicts:
src/corelib/tools/qvector.h
Make QVector(DataPointer dd) public to be able to properly merge
5b4b437b30 from 5.15 into dev.
src/widgets/kernel/qapplication.cpp
tests/auto/tools/moc/allmocs_baseline_in.json
Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Change-Id: I929ba7c036d570382d0454c2c75f6f0d96ddbc01
The previous implementation did not take into account different color
groups in resolve mask. It led to some issues when resolving a
palette or checking whether a brush is set or not.
Task-number: QTBUG-78544
Change-Id: I9b67b2c444eb62c022643022a874dc400005e6ee
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
If the singular fontFamily() is given, then this is obviously the one to
be preferred over any plural fontFamilies(). Make sure it always ends up
first in the list of emitted font families.
Change-Id: I1e3b1ba29721c8298b1a0d4a1e1da49ba5b4e7ac
Fixes: QTBUG-80475
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Added new API setDocumentXmpMetadata/documentXmpMetadata and
addFileAttachment
[ChangeLog][QtGui][QPdfWriter] New API to provide external document XMP
metadata and attach files to PDF.
Fixes: QTBUG-78651
Fixes: QTBUG-78764
Change-Id: Ic0b37e8d12899f907001db469080594c14c87655
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
It wasn't tested and behaves in a very particular way.
Change-Id: I60a31681e5b221cf9a86df77e410a76ee4c10864
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
This is not to be taken as supported and is still undefined behavior,
but I prefer we do not crash.
Change-Id: Icf4f3398bfd57fcbdc611a5a821a1f2de0838330
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The previous implementation was *extremely* expensive. It
relied on loading a binary JSON file from resources (which
involved decompressing it), then extracting information out of
it to build a gradient. Already-loaded gradients were kept in
a local cache, which had to be mutex protected.
Instead, this patch extends the gradient generator to build
static arrays filled with the web gradient data, sitting in
.rodata.
These arrays are used when building QGradient objects with a
web gradient. No explicit mutex protection is necessary, since
accesses will just read from the arrays.
As benefits, this patch removes:
* the binary json representation from QtGui's resources (~4KB
compressed, ~50KB uncompressed)
* the overhead of reading from the JSON for each used web
gradient;
* the startup costs of registering the webgradients in the
resources;
* all the overhead of mutex locking when building such
gradients;
* all the runtime memory allocations to load, parse and cache
the web gradients (including the memory + CPU spike on first
load due to the uncompression of the JSON data, as well as a
couple of deep copies).
Change-Id: If5c3d704430df76ce8faf55ee75ebd4639ba09c4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When an existing item is replaced with a new one in
QStandardItemModel::setItem() then the persitent index is invalidated
which leads to some unexpected behaviors (like e.g the header size and
resize mode are reset).
Therefore we have to make sure that the invalidation does not happen.
This can be achieved by delaying the call to QStandardItem::setModel()
for the old item until the new is properly added. After this, the old
item no longer gets a valid QModelIndex from the model and therefore
can't invalidate the persistent index anymore.
Fixes: QTBUG-13605
Fixes: QTBUG-73000
Fixes: QTBUG-80586
Change-Id: I4e45e6feb81b7287c0859f638d7ab1a576fc2f0f
Reviewed-by: David Faure <david.faure@kdab.com>
When cloning a QTextDocument, the text fragment of the original document
is copied into the new one, which results into copying also the
formatting attributes. However, when the text document is empty, the
corresponding text fragment is also empty, so nothing is copied.
If we want to transfer the formatting attributes for an empty document,
we need to set them explicitly.
Fixes: QTBUG-80399
Change-Id: I382cd0821723436120af47c06ec7bfa849636307
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
QDoubleValidator would accept "1,23" as valid in a locale which has ','
as a thousand separator. However, it should have been Intermediate
instead, as there is still one digit missing.
Fixes: QTBUG-75110
Change-Id: I6de90f0b6f1eae95dc8dfc8e5f9658e482e46db3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The new version takes/returns a value that can be unpacked and passed to
other functions without knowing which backend is in use.
The old API will be removed in a later change when dependent modules have
been updated
Task-number: QTBUG-78570
Change-Id: I18d928ceef3cb617c0c509ecccb345551a7990af
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The code was assuming that if the parsing of the value worked,
then it must be a list of 4 variants. But in this case it's just
a single length.
This came from <td> using 4 values for border-width
while other elements use a single value. But the storage
is shared. So the fix is to use 4 values everywhere.
When reading 4 and there's only one, it gets duplicated,
so the caller can just use the first one in that case.
Task-number: QTBUG-80496
Change-Id: I682244b6e3781c4d673a62d5e6511dac263c58e8
Reviewed-by: Nils Jeisecke <nils.jeisecke@saltation.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The code was initially introduced in
9204b8c31e but getting the names were
conditioned on whether or not Windows identified it as a truetype font.
This excluded cases which had preferred names embedded but was not
truetype fonts. To fix that we run the code unconditionally.
[ChangeLog][Windows] Fixed a bug where some fonts would not be
accessible by referencing their typographic name.
Fixes: QTBUG-78556
Change-Id: I8823684b09cce3b1b8722b1e609a5bb49b13da13
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
For Metal and Vulkan this needs actual work because that's where
the concept of renderpass descriptors is relevant. GL and D3D can
just return true always.
The big benefit of this is that Qt Quick can now compare renderpass
descriptors via isCompatible() for its pipeline cache (similarly to
how it is already using isLayoutCompatible() for srbs), and so
renderpass descriptors for layers (Item.layer, ShaderEffect) will
typically be compatible and so can pick up pipelines created by other
layers from the cache.
Also add autotests for shader resource binding and renderpass descriptor
compatibility.
Task-number: QTBUG-80318
Change-Id: I0008bc51c4ee13b0113d2c8caf799e1257f18a18
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
While we are at it, remove the Border and MirrorOnce wrap modes that have
not been supported on OpenGL, because they are unsupported with Metal+iOS
as well.
Task-number: QTBUG-78580
Change-Id: I0db94b9d3a6125b3bb5d7b1db5d02a42cd94d2c2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reimplement QDomDocument using QXmlStreamReader and switch to the new
implementation starting from Qt 6.
The changes in the behavior are reflected in tests: some test cases
which were marked as "expected to fail" are now passing.
Task-number: QTBUG-76178
Change-Id: I5ace2f13c036a9a778de922b47a1ce35957ce5f6
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Calling QColor::setFoo() is currently inconsistent - some setter do
invalidate the colors, some don't. Unify it by calling invalidate in
every setter.
Task-number: QTBUG-62452
Change-Id: Ia4f0bd16ea30e9659bc989ffc2b319892438b84b
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@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>
It was converted over ARGB32PM, when it should have been directly
converted to not lose accuracy, instead there was an unnecessary direct
ARGB32->RGB30 conversion, which was converted to the necessary type.
This also improves the selection of conversion over ARGB32PM or RGBA64PM
for ARGB32 and RGBA8888 by using 32-bit conversion when alpha is not
relevant.
Change-Id: I5990d8a23b2909d3910d8c1213fa46477742b052
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
You can save a "skeletal" document with list items to fill in later,
the same as you can do in HTML or ODF format. Reading them back via
QTextDocument::fromMarkdown() isn't always perfect though.
Fixes: QTBUG-79217
Change-Id: Iacdb3e6792250ebdead05f314c9e3d00546eeb9f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The markdown parser generates empty lists in some cases when a character
that can be used as a bullet is found on a line by itself.
cbEnterBlock() and cbLeaveBlock() are called symmetrically in such cases.
QStack::pop() on an empty stack triggers an assert, so push and pop need
to be done symmetrically too. But it's difficult to actually create the
list as soon as the MD_BLOCK_UL or MD_BLOCK_OL callback occurs, without
breaking the case fixed in 7224d0e427 (and
probably other cases). That's because QTextCursor::insertList() creates
a list item at the same time as it creates the list itself, and also
inherits block formatting from the previous block. We now insert empty
lists with empty items whenever the need for that is detected though,
and there's a failsafe to prevent popping in case something still goes
wrong with that logic. We aren't strict about reproducing the original
markdown when regenerating it via toMarkdown(), but it's getting closer.
Fixes: QTBUG-78870
Change-Id: Ided194ce7aec2710c60dbac42761ee4169ed9b78
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
If a font with only a family set is resolved with one that has been setup
with setFamilies() then the family needs to be prepended to the families
list after resolving. This is so that the font still prefers the one set
as just a family with no famillies set.
This also amends the QFontDialog test to account for this too.
[ChangeLog][QtGui][Text] Resolving a font that just has a family set
with families set will prepend the family to the families so that it
is still the first preference for the font.
Task-number: QTBUG-46322
Change-Id: Icc4005732f95b2b4c684e592b06b31e133270e44
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
In qmake syntax there should be a colon or curly braces following a condition.
Change-Id: Ibd989662aef6320cec8093e7c6103bf8362b8255
Reviewed-by: Liang Qi <liang.qi@qt.io>
