If the variant contains a string or image, try to encode the QString or
QImage, respectively, according to the specified mime type. If it's
neither, or if the mime type is not supported by known encoders, then
generate a warning.
To make the code unit-testable, move the QQuickDragAttachedPrivate into
a private header that we can include in a new test case. Verify that data
that matches the mime type results in correctly populated QMimeData, and
that mismatches produce runtime warnings.
[ChangeLog][Qt Quick][Drag] The attaching type Drag supports more mime
types in the mimeData property, which is now of type 'variantlist'
instead of 'stringlist'. Qt Quick Drag validates the type of the data
against supported mime types, and generates warnings in case of a
mismatch. If the type of the data is ArrayBuffer (i.e. a QByteArray),
then the data is accepted without any validation.
Task-number: QTBUG-71922
Change-Id: I82789086fed9c7bc399183e76ffb83b819df440f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Currently ObjectShow event is only sent when the visible property
changes from false to true, but for items with the notification
accessible role, a screen reader like Orca needs to receive an
ObjectShow event to read the notification, so also send the event after
a component is initialized.
See also: https://gitlab.gnome.org/GNOME/orca/-/merge_requests/134
Pick-to: 6.4
Change-Id: I626594b65ffe4d0582dcee9f489df0c2c63e53b7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Split the huge blob-section "Arguments" describing the arguments of the
qt_add_qml_module command into groups (as \section2 elements).
Sort the newly obtained groups around to have the probably most needed
ones on top and the more special cased ones on the bottom.
Add an example where DEPENDENCIES entries are needed, such that it is
easier findable and understandable when it is typically needed.
Fixes: QTBUG-107092
Change-Id: I52ff94d038645e1383c56f6ff384b55627e800b5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Add a foreign declaration to QEventPoint such that
qml compilers can work correctly with it.
Also fix the links to eventPointer in the
documentation, and duplicate the list of
properties of the C++ api.
Fixes: QTBUG-107624
Change-Id: I11c4a4a416a40d40fc7ce45d7f894406035a6d87
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
If you place a TableView in e.g a StackLayout, it will
have a zero size until it becomes the active view the
layout. If the delegate then has a binding that e.g
looks like:
implicitWidth: TableView.view.width
it will fail, since the width of the view is zero at time
of creation, but at the same time, never updated again
once the view becomes visible (and resized).
This patch will therefore ensure that we do a relayout
each time the view is resized, since having such a
dependency in the delegate (or in the columnWidthProvider)
must be expected to be quite common.
Pick-to: 6.4 6.2
Change-Id: I92f4f51f6b6c634c2627716c41ea4971fb8d1653
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
If an item is being destroyed, don't remove its children from the child
list one by one (which requires O(n) traversal of the child list).
Instead, clear the list at once, after all children have executed the
removal routines.
Also, there is no need to mark the an item that is being destroyed as
dirty for each child that gets removed.
Change-Id: I52c8564a54132b9bc358847bc59d06e11d420d6c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
If a QQuickItem is in the QQuickItem destructor, then it is both unsafe
and unnecessary to emit property change notifications. Connected code
can no longer rely on the state of the emitting object - if it was
originally a subclass of QQuickItem, then those subclass destructors
will already have run. And the QQuickItem destructor will also have
partially run, leaving the object in an undefined state.
Add a flag that we set to true at the top of ~QQuickItem, and don't emit
visibleChildrenChanged, parentChanged, visibleChanged, and
childrenChanged for items that are partially destroyed already.
[ChangeLog][Qt Quick][QQuickItem] QQuickItem no longer emits change
notifications for the parent, children, visible, and visibleChildren
properties while it is being destroyed.
Task-number: QTBUG-107850
Change-Id: I36ea98842c89ad89fcc1c4a328d138f66f2a0446
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
These signals get emitted by the QQuickItem destructor for the item under
destruction, but also for the visual child items, as they get removed
from the parent. Connected code that references parent objects might
crash.
We can't block those signal emissions as code relies on them to remove
pointers from data structures, and for items that are not also QObject-
children we have to emit the signals anyway as they will not get
destroyed, and their properties do change.
The best we can do is to document that it's potentially dangerous to
operate on visual parent objects in code connected to those signals.
Note that the visibleChanged signal does not get reliably emitted when
a parent in the visual hierarchy gets destroyed.
Pick-to: 6.4
Task-number: QTBUG-107850
Change-Id: I87913658818ec9491a4c4e799d9c553de44ea9c2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Those tests were skipped because of QTBUG-45655, but that was resolved
years ago. d14b5fbad3 re-enabled some
Linux testing, which seems OK; and tst_qquicktextedit::embeddedImages
has been OK too.
Reverts 4789a29967
Task-number: QTBUG-45655
Change-Id: I9272d5d589e9d3fa167c4afdcbe21be87a0015fe
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Since lists are allowed as property types, you should be able to pass
them as arguments to methods, too. For now we only handle QML-defined
methods, implemented by adding JavaScript functions to your QML
elements. The usual type coercion rules apply if you pass JavaScript
arrays to such methods. That is, it usually works.
We now resolve properties with the "list" flag to their actual types
(QQmlListProperty or QList) already when populating the QQmlJSScope, and
store the list types as members of QQmlJSScope rather than as a special
map in QQmlJSTypeResolver. This allows us to do the same to lists passed
as arguments and simplifies some of the type analysis.
Fixes: QTBUG-107171
Change-Id: Idf71ccdc1d59f472c17084a36b5d7879c4d959c0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QQmlComponent already has support to load sub-objects in a QML file
(which is necessarry for the QtQml Component type).
We repurpose the same code path to load inline components. However, we
need to remember that we are dealing with an inline component (instead of
a Component), as the QmlObjectCreator requires a specific flag to
correctly instantiate the inline component in that case.
Everything else is however handled by calling QQmlComponent::load with
the URL of the outer type.
Except for one additional gotcha: The QQmlType of the inline component
might only contain a placeholder id if the outer component has not been
loaded so far (as we cannot possibly know the object's id inside the
file without compiling it). To get the correct id, we force synchronous
loading if we detect that we've gotten a placeholder type (id <= -2).
In the future, we might want to remember either the URL or the QQmlType
to avoid forcing a synchronous load. Then we could set "start" to the
correct object id in beginCreate.
Change-Id: I20209e9389d0a64d2a07c2fb1bc9cbc430668040
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We can reduce the size of the class by using QBiPointer to internally
store what previously has been two pointers and a flag.
The only draw-back is that we now have to manually manage the memory.
Mark the type as uncopieable to reduce the amount of boilerplate we
need; we still need to support moves as we store ConstructionState in a
vector.
Change-Id: I99329bbfda3f7147d475c1574a20a54719d2f7bd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
And move all functions out of the class body to make it easier to see at
a glance which methods are defined in the class.
Change-Id: I2c64b3220b31bed1a1322ddba7010ede6b2452ab
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
This allows for a more natural handling of the case where there are no
required properties, and will enable further refactoring of
ConstructionState.
Unfortunately, we lack a way to mark pointers as always non-null in Qt,
else we could mark all required property pointers originating from
QQmlObjectCreatorSharedState as such.
Change-Id: Icaccb27654130fb57daf924bb44a70a5cf114fed
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Instead, access it directly via state. Also, introduce a
hasUnsetRequiredProperties helper function to simplify a few checks,
and a addPendingRequiredProperty heper function to indicate places where
we actually insert new entries to the list.
This is a preparation to further refactor the handling of required
properties in QQmlComponent.
Change-Id: I25f5ef45be0b3508cf5b0f82a666d33610d5810d
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Add support for handling required properties in types created via
QQmlComponent::loadFomModule which are backed only by C++. We check all
properties in the QQmlPropertyCache for their requiredness; we could
also attempt this via the QMetaObject, but the assumption here is that
for a QML object we want the property cache anyway in the near future.
Reducing the size of the ConstructionState which now stores the
RequiredProperties is left as an exercise for another commit.
Change-Id: I2e6f67f809ac2cbddbe2b28614ed98cee066fc61
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
As a drive-by, let AnnotatedQmlError's ctors take the QQmlError by
value, and move-construct it into the member.
Change-Id: I4c7aea5a966cfdb45abdc74ee352d5dd41b73aba
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is a preparatory step to decouple accessing required properties
from the existence of a QQmlObjectCreator (which will not exist when
existing pure C++ types).
Task-number: QTBUG-97156
Change-Id: I5323b018022e99f9ebf9be61d6f9a75b8a5dad48
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
loadFromModule is conceptually similar to loadUrl, except that it does
load the Component from a QML module URI and a typename instead of an
URL.
One big difference is that it allows loading types registered in C++,
which is not possible via URLs, as those types do not have any.
The implementation piggy-backs on the existing functionality of the
QQmlTypeLoader: We first add the URI as an import. Then we resolve the
QQmlTypeModule matching the URI.
For a C++ registered type, we can already find the existing QQmlType
there. As we don't store the QQmlTypes for composite types theree, we
might however not find the type, even if it exists. To handle that case,
we then use QQmlImports::resolveType. This is not too costly, as import
and module resolution get cached.
For composite types, we then retrieve their URL, and simply fall back to
loadUrl. This could be optimized, but is done in the simplest way for
now. For C++ registered types, we store the QQmlType in the component
instead.
Doing that allows us to use QQmlType::createWithQQmlData in
QQmlComponent::beginCreate.
Compared to loadFromUrl there are a few additional failure modes:
attempting to load singletons, querying non-existing modules, or asking
for non-existing types in a module. Those all result in component
entering an error state.
The API ignores revisioning – it is questionable whether we want to
support it, or if we can live with only resolving to the latest version.
Adding support for it at a later point would be easy; one would simply
need to pass a QTypeRevision through the various APIs.
There are two remaining tasks after this patch: We do not validate
required properties for C++ types with this approach, and we cannot load
inline components. Both will ba addressed in follow up patches.
Task-number: QTBUG-97156
Change-Id: If3ed74a499f49c668524d917089a0c237c4ddaf8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
An application might listen for e.g the leftColumnChanged signal
and query the position to the delegate items in the new left
column. But for this to work, be sure to layout the items (and
basically finish loading the column) before emitting the
signals, so that leftColumn(), rightColumn(), topRow() and
bottomRow() return the correct values.
Change-Id: I0e64bd2b240b0dac03120a944815ee2e5e43a6a0
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The additional targets for variables and properties weren't used.
The \target for qt_deploy_qml_imports was just replicating the \title
(which already defines an implicit target of the same name). Define
a target for the qt6_deploy_qml_imports variant instead.
Change-Id: I407fec0d8b1ad837a53f702e62b1133bb0fb2814
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This patch will add support to TableView for resizing rows and
columns by dragging between the cells.
To achieve this, a custom pointer handler (QQuickTableViewResizeHandler)
is implemented. This handler can detect if the pointer is hovering
between the cells, and if the user starts a drag. This information is
used to call out to the new setColumnWidth()/setRowHeight() API for
adjusting the row and column sizes while the user is dragging.
The pointer handler is careful to make sure that you can only start to
resize by dragging _between_ the cells. If the drag starts elsewhere, the
solution will fall back to normal contentItem dragging/flicking instead.
Resizing is off by default. The user can enable it by setting the
resizableRows/resizableColumns properties. In addition, an API that
lets you query the state of the resizing has been added.
[ChangeLog][Quick][TableView] Added resizableColumns and
resizableRows properties to enable resizing by dragging between cells.
Change-Id: I05d4170f30b8c6461a5877c2b831a1ab044d2b5b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Make sure that Reference is also a top-level element, and just list
the list of examples there, instead of a separate section. Move Licenses
and Attributions a bit up, so that Reference is the final section.
Pick-to: 6.4
Change-Id: I2fa78f32a6994d7276bf37f5949348424383ff68
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
So far we have "normal", "low precedence", and "implicit" imports.
Normal imports were ordered in document order, later imports overriding
earlier ones. Low precedence imports were ordered in intractable
confusion, and implicit imports were added last, with the actual
implicit import first, and any dependencies of it after it in
intractable confusion.
Since that gives us problems when QtQml is split into an empty "meta"
module and a number of dependencies, we have to clear out the confusion.
Following the principle that direct imports have higher precedence than
indirect ones, we can give each import a precedence number, depending on
whether it is implicitly imported or not, and how much the importer has
recursed to reach it. Ordering the imports by that number results in a
less confused structure, more accessible to reason.
Also, module imports were added in different order depending on whether
they were revisioned or not. Add them always in the same order.
[ChangeLog][QtQml][Important Behavior Changes] The precedence of imports
that expose different types for the same name has changed. Previously
the algorithm was rather confused. Now, the rule of thumb is that
more direct imports override more indirect ones. That means QtObject
imported directly from QtQml is of higher precedence than QtObject
imported from QtQml via QtQuick. Where that still leaves ambiguities,
imports later in the document override imports earlier in the document.
Any explicit imports and their dependencies always override the implicit
import and its dependencies.
Task-number: QTBUG-105240
Change-Id: I5f95f6bb8367087b9d977cb01f434d01bb402a3e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
MADV_WILLNEED is only advisory. The kernel may ignore it anyway. Any
subsequent access to the pages in question will trigger them to be
re-populated.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-107774
Change-Id: I8d70003502fdeb3e53c169b28ea6826801d47c74
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If QRhi is destroyed, the rhi member of QQuickWindowPriavte must also
be initialized. Otherwise, it remains a dangling pointer and causes
segmentation fault
Pick-to: 6.2 6.4
Fixes: QTBUG-108252
Change-Id: Ic1b003d28da0fd1163f80a913d9ca3b4a8bb1e1b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Details: Move value for velocity less than 0 should consider size of
item, for getting correct position for next item, bias should not be
considered with press position when QWheelEvent::phase() gives us
NoScrollPhase because it is possible to use value saved last time
(last wheelevent with press position)
Fixes: QTBUG-98979
Pick-to: 6.2 6.4
Change-Id: I825033c958602032f699f2c207b0a4312dd96c8c
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
When scaling with fractional values, aliasing can occur. Use the same
approach as BorderImage and respect the smooth property of
NinePatchImage. This property comes from QQuickImageBase, which sets it
to true by default. We change QQuickNinePatchImage's default value for
it to false, but this can be overridden by setting
QT_QUICK_CONTROLS_IMAGINE_SMOOTH to 1.
As NinePatchImage is not public API, and users would have to set the
smooth property on every image (where some items contain multiple
NinePatchImages), it's better to have one place to set this for all
controls.
[ChangeLog][Controls] The Imagine style now supports smooth scaling for
9-patch images when the QT_QUICK_CONTROLS_IMAGINE_SMOOTH environment
variable is set to 1.
Fixes: QTBUG-107989
Pick-to: 6.2 6.4
Change-Id: I250a041f87c0270d67af191168f7bcfbf6237925
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Running qmllint on extending-qml examples raises a plenty of warnings
due to a missing dependency declaration to QtQuick. Simply add it. Also
add FINAL to all properties exposed from C++ to disable (possible) property
shadowings.
Pick-to: 6.4 6.2
Fixes: QTBUG-106602
Change-Id: I7b12a804f8f3ca64bd8f2f312a9e53dfe02b0a4c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just forwarding the innermost error message won't tell the user what
actually went wrong.
This will become significant (and tested) when we restructure the QtQml
module to be a pure forward.
Task-number: QTBUG-105240
Change-Id: I83e6ef1e8d5d7d28c0588117c8f1cd522dd082b4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We need to do the subscript lookup before generating the arguments since
the arguments may change the array.
Fixes: QTBUG-106708
Change-Id: Ia3a0dd34c6ed8d39e86ad20911a632d691826322
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The items that reject drag events (specifically onEntered in DropArea)
should not be retriggered with DragEnter event until entered once again.
Fixes: QTBUG-74496
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I241a6004da6382685be89fe8a001b98dfde5c8a2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
At least until we get to do more testing on macOS 13.
Task-number: QTBUG-106703
Change-Id: I1203959f114c8c9577f55818e31820ba99ea143f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Use the generic way of collecting qml imports for both Android and
desktop platforms.
Amends 2dd17fdf70
Pick-to: 6.4
Fixes: QTBUG-106940
Change-Id: Ie7888d5848d10f25da7712042a009ae639e5a43c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The history of this mechanism goes back to early 5.0 days probably,
when the case of showing multiple QQuickWindows was not always
considered. Using a single data storage is not only unsafe when
it comes to threading (if using the threaded render loop), but
seems to cause visible rendering errors if certain conditions are
met. (the problem is not strictly caused by emptying the list of
QSGMaterialType pointers when a window goes away, that's safe in
itself, but rather there is a chance of collisions then if 'new'
gives the same pointer afterwards, breaking the uniqueness
contract; or something along those lines)
This is now solved by locking and making the storage per window,
using the QQuickWindow as the key.
Pick-to: 6.2 6.4
Fixes: QTBUG-107818
Change-Id: I4f94c4bccb43c4db246aff02e0b809cc9f106e39
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
QMimeData::setData expects the provided data to contain the correctly
encoded QByteArray, so if the variant contains a QByteArray, then take
it as is to avoid data loss.
If the variant is not already a byte array, then we ideally would make
sure that the mime type (i.e. the key of the map) and the QVariant's
type are compatible (image/png with a QImage works; text/plain with a
QImage does not). This changes behavior and needs to be a follow-up
commit.
Fixes: QTBUG-71922
Pick-to: 6.4 6.2
Change-Id: I9b9f10fd332e1f9568f6835a69a1c359457f823c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Volker Hilsheimer
Fushan Wen
Laszlo Agocs
Sami Shalayel
Richard Moe Gustavsen
Shawn Rutledge
Ulf Hermann
Fabian Kosmale
Inho Lee
Kai Köhne
Qt Submodule Update Bot
Andreas Eliasson
Bumjoon Park
Evgen Pervenenko
Mitch Curtis
Semih Yavuz
Santhosh Kumar
Thibaut Cuvelier
Alexey Edelev