We allow value types to be created
1. by calling Q_INVOKABLE constructors
2. by setting their values from properties of a JS object
Both have to be opted into by setting a class info. If opted into, these
options override the existing methods. When a a type can be created by
setting its properties, that implies you can also initialize it using an
invokable constructor. However, when given a JS object, the properties
method is used.
We keep this internal and undocumented for now. As the last try (the
create(QJSValue) methods and QJSValue ctors) was not that stellar, let's
first wait a bit and see if we're getting it right this time around.
Fixes: QTBUG-106480
Change-Id: I767230924afcba032d501846cc3263dad57b7bf0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This saves some space due to better alignment.
We cannot have more bits in the compilation unit anyway. If we were to
get a signal with more formal parameters than that, we just produce an
error now.
Change-Id: I02c329590b2d18337eca7441529b5cd4e19349f7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There was information missed in
ab287508d5, such as how to fail every
test function upon encountering a certain warning, and the fact that
all patterns are cleared at the end of each test function.
Pick-to: 6.4
Change-Id: Iaf19e8788373b06e8e46e3f7a056f71f354b40e7
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Opening input files in binary mode may cause file to be parsed
incorrectly. To prevent the crash, Check if element in container is within the range
of valid elements before accessing it. Note that qmllint will ignore the comment
directives and may not function correct in that case.
QTBUG-106813 should solve this.
Pick-to: 6.4
Fixes: QTBUG-106613
Change-Id: I1a5705474905a747fbcc4874c3ff2038f539f42f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Has an effect on the extreme qmlbench test cases.
Pick-to: 6.4
Change-Id: I6fc82ad342053fbe47d6837937705cd556b185ea
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
With qmlbench this gives an improvement (405->430) in
delegates_shadereffect.qml.
QQuickShaderEffectImpl is not needed anymore in Qt 6, because it
only has one implementation (unlike in Qt 5.14 and 5.15). Move it
all into QQuickShaderEffectPrivate.
Fixes an obvious bug as well: in propertyChanged the derefWindow()
call should be called with the old 'source' object, not the new one.
Change-Id: I13d2a3a9134368e3319e3967bfb994eb92866704
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
It crashes in the CI without providing any indication where.
Task-number: QTBUG-106714
Change-Id: I219fd6eec1fb14745acb154f8661edabb4c99a5a
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Instead of calling the methods to get the elements-to-be-appended and
the append-calls alternatively, put first all the elements-to-be-appended
on the stack before appending them all one after the other.
Instead of compiling list bindings right away into an append call,
collect all consecutive elements of a same list before printing all
append calls.
This requires knowing when all bindings are processed (else the last
listbinding are collected but never compiled), such that
this changes QmltcCompiler::compileBinding to accept lists of
bindings instead of single bindings.
Added private fields to QmltcCompiler to save the property of the
current list and the list bindings collected so far.
Fixes: QTBUG-106783
Change-Id: I75f71e828875e3d95540e6f33574bee7fa8bccbf
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
QmltcCompiler::compileBinding was getting big and unwieldy as it was
compiling any kind of binding in a big switch-statement all by itself.
Move the binding specific logic into separate helper methods and add
a method that calls the right helper method depending on the binding
type.
This change prepares the code for QTBUG-106783.
Task-number: QTBUG-106783
Change-Id: I900e182a82ae780186ad79a5cb5db31bd0548e33
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
With qmlbench this gives an improvement (322->386) in
delegates_shadereffect.qml.
Pick-to: 6.4
Change-Id: Ibcaa4fa6ce992a3100b4be72dc954191f6b07c85
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
...based on the window flags.
As the docs already describe, for full control one can assign cache
files explicitly to each QQuickWindow. (of course, that is not always
trivial esp. when working with the QML API but let's not go there now)
This does not affect that. The default, automatic cache however needs
to apply some simple guesses as to when it does not make sense to
bother with loading/saving the cache. Otherwise we'd end up with
silly situations, when using the default threaded render loop at
least, where showing/destroying a tooltip (if it's a standalone
window) kicks off file I/O for the pipeline cache, with likely
very limited benefits (and whatever it collects is lost later
when the main (last) window is closed anyway).
In addition, make some of the logs more readable by including
which QRhi and which QQuickWindow are the messages talking about.
This becomes pretty important in applications dealing with
multiple windows over their lifetime.
Change-Id: I9cabe3eb0db994e5c1d73ca071664ff1bf5f0d45
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
The bitmask values were wrong which led to flags not set/unset
possibly reported with the opposite value.
Add support for qDebug printing. This we will use in QSGRhiSupport
to improve logging but that needs to be a separate patch due to
some conflicts.
Add a minimal autotest as well.
Change-Id: Ib64f9f854e50224ec5f22b365c36b86208df9336
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
There is implicitly shared stuff in it (QShader) and in the
extreme qmlbench cases the free() would show up in the VTune
profiling results. No point in doing anything anyway apart from
clearing the variables list, the rest will be assigned new values
anyways.
Some improvement in qmlbench for delegated_shadereffect, up from
ca. 430 to 442 or something along those lines. (with parent patch
combined)
Pick-to: 6.4
Change-Id: I0d08a28fc6b91b75eb032fdfbd71d25ee6acde62
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Remove old and unused code in TableView that was
back in the days meant as an initial first step to
implement section resizing.
Task-number: QTBUG-106792
Change-Id: I84941bd6836e16751299e347abbbe9aa1813ade8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
`Q_GHS_KEEP_REFERENCE(${register_types_function_name});` emits
`-Wextra-semi`. however `Q_GHS_KEEP_REFERENCE` either emits to an empty
statement or `QT_DO_PRAGMA`, neither requires an extra semicolon
Pick-to: 6.4
Change-Id: I8887bbc39629a3186ea8a488d4b0989009107f3a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Majority of QML type compiler tests cannot be run on webOS due to
platform limitations, so this commit excludes them from the webOS
build.
Fixes: QTBUG-106114
Pick-to: 6.4
Change-Id: I9b1b56ec82aa28b314d039552f89fdb6d14d93ce
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The current implementation would not explicitly store if
hoverEnabled was set. Instead it would use acceptHoverEvents()
directly. The problem is that the latter will also need to be
set to false when a MouseArea is disabled, otherwise it will not
receive a HoverLeave event. But when doing so, we will no longer
know if hoverEnabled was set to true or false by setEnabled() or
by setHoverEnabled(). As such, when the MouseArea is enabled again,
we would no longer know if we should start to subscribe to hover
events or not.
This patch will therefore add en extra bool, hoverEnabled,
that lets us track the hoverEnabled state explicitly.
As a drive-by, also add some internal docs that explains
how a MouseArea differs wrt hover compared to e.g
HoverHandlers and other items.
Fixes: QTBUG-46460
Pick-to: 6.4
Change-Id: I34e078b3574030572bcf770750820959e98ecc4c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This caught my attention while reviewing a related fix
(4933bd6351)
Task-number: QTBUG-106594
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: Ie8c7fb2d9e504b14a924eca72a87295d8764cf39
Reviewed-by: Dominik Holland <dominik.holland@qt.io>
Otherwise it's rather impossible to find the issue in the QML code.
Change-Id: I894886feb58864503e6ffd2dd28626e68d623aae
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The current implementation would exit early if subtreeHoverEnabled
was false. The problem is that this can also happen if you set
hoverEnabled to false while an item is being hovered. And in that
case, we need to prune the list of hovered items.
This patch will therefore ensure that we only exit early if
subtreeHoverEnabled is false, _and_ no items are currently
marked as being hovered.
Pick-to: 6.4 6.2
Change-Id: I6086c7cbea07b0973db343a3f439810361c5d1b7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Like e43e17d9f8 but let's test the
MouseArea.enabled property too. Press Control-E to toggle the state.
Task-number: QTBUG-46460
Change-Id: I9923df31b298618b659b69e20e955ee8b89aaa9a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
It's important to set lastMousePosition with the correct scene position
in QQuickDeliveryAgent::event's QEvent::Enter case, not some
item-localized position.
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 (or actually left
unchanged in this case); 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 6.2
Fixes: QTBUG-35409
Change-Id: Ibe840f8ac7b91fd711fc0f4d4a90a24e0117791b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
So far, for each method call we had to allocate a new QObjectMethod as
we didn't have any lookup to cache the methods. Introduce a new lookup
for that and use it for all QObject methods.
Since QObjectMethod contains a pointer to the concrete QObject the
method was retrieved from, some more care has to be taken: If we are
going to call the method right away, we don't need the object since we
always have a thisObject and any further retrieval of the same method
will result in a call again. This enables us to cache the method for any
instance of the same class. When storing the method elsewhere, though,
we need to hold on to the object since you can defer the call or connect
a handler to a signal or similar. For such operations we do need the
object. We can still optimize a bit by re-using the method cache we
build the first time around.
Fixes: QTBUG-95628
Change-Id: I5991180c5e0234cdc179c2b78a43dafc9083e525
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Wherever we need an engine in there, we also have a managed value to get
it from. This relieves us from the requirement to drag an engine around
wherever we want to call toVariant().
Change-Id: Ib95d02b5fbf5eaa494214e337c9b700e97e5e0df
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously in Qt 5 there was an option to define iconSource property
in Controls 1 Menu. But it's missed in Controls 2, so it's not possible
to use icon for submenu item in Qt 6. This patch introduces icon group
property for the Menu so that it behaves and displayed the same as for
regular menu items.
[ChangeLog][QtQuick][Controls] Now it's possible to set icon for Menu.
This is useful for submenus, so icon will be displayed as for regular
menu items.
Fixes: QTBUG-79972
Change-Id: I4610d4b6d40c51b774b035e238e5e1ceea53a8a3
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
In qqmljsimportvisitor, print an error message and return false when a
top level component is visited.
Also, remove all the tests expecting qmltc to accept top level
components and add a test to see that the error is correctly emitted for
top level components.
Fix qmllint tests using top level components.
Fixes: QTBUG-106558
Task-number: QTBUG-106547
Change-Id: I101b42fc7499049fcebca18e7aeab57fa6705f81
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The resolution of inline components through QQmlType was failing and
therefore inline components were not allowed as signal parameters.
Apply the same fix as 2a37ff2f49 to signal
parameter-type resolution.
Test if signals with inline-component-typed parameters works, even if
the inline component is defined in another qml file.
SignalInlineComponentArg.qml is capitalized as it is used in
signalInlineComponentArg1.qml.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-106611
Change-Id: I2bbcee56025e6a319a3fea9b7aedf703afabe6b3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Compiler warns:
ignoring return value of function declared with 'nodiscard' attribute
[-Wunused-result]
Pick-to: 6.4
Change-Id: If10d41fad7dc77b36eecc8725de178b0908f32de
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The current documentation for the "enabled" property claims
that "This property holds whether the item receives mouse and
keyboard events.". This is not completely true. Hover events
have been enabled for disabled items for a long time, to
e.g show tooltips, also for disabled items. Since changing
this would cause regressions, and since hover events can anyway
be switched on and off with a separate, explicit, API, document
(and test) that this is how hover events actually work.
Task-number: QTBUG-30801
Pick-to: 6.4
Change-Id: I59409cbb33fb3e2275809156c245e28c21891bbc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This isn't needed for the autotest, but we sometimes use this qml file
for manual testing.
Control-h toggles the upper HoverHandler enabled state, and Control-m
toggles the MouseArea hoverEnabled state; that way it's possible to
test that hover feedback disappears even if the mouse isn't moved.
However, flushFrameSynchronousEvents() currently gets called only
if some items are marked dirty; so if we don't change the checkbox
appearance, _and_ we use only keyboard shortcuts to change the
enabled state, this demonstrates that we still have bugs: we don't
immediately update the containsMouse and hovered properties when
the respective objects have their hover processing en-/disabled.
While we're at it: stop using Loader, use named components instead.
Task-number: QTBUG-46460
Change-Id: Ib7aecf4788621a7d5cf0b9461ca56553610120ec
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Toggle setHasHoverInChild in sync with the handler being enabled.
This fixes a bug: if a HoverHandler is hovered, and somehow the
enabled property is programmatically set to false with no mouse
moveement and without any other scenegraph changes (i.e. no item
gets marked dirty and therefore flushFrameSynchronousEvents()
doesn't run), its hovered property now changes to false immediately,
as it should.
The DA will get less items to traverse, so this is also an optimization.
Pick-to: 6.4
Change-Id: I24be7d25ee15180fff010cc1c532266cd6e73ffb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
startup() waits for a notification from the worker thread, which does
this as its first action in run(). However, there is no data set up by
the worker thread that would require this kind of synchronization.
As the whole procedure is superfluous, simplify startup to only start
the QThread, and move it to itself (an anti-pattern to be revisited
later).
We also can get rid of the run() override, as the default implementation
does everything we need - namely starting the event loop.
Change-Id: I648778913893ebce9efc6aa61e38ed38cad0b0e7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We only have 4, so using a bitfield does more harm (needs shifting) than
good.
Change-Id: Iabcca2098a13bd5b9cb9a890209365e264e9b7b6
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
According to the documentation for HoverHandler::enabled, a
disabled hover handler will not accept any mouse events. It
therefore follows naturally that a disabled HoverHandler
should also not affect event propagation elsewhere.
This patch will change the implementation, so that
we don't deliver hover events to HoverHandlers that are disabled.
This also means that disabled HoverHandlers will no longer block
propagation to its siblings.
[ChangeLog][QtQuick][HoverHandler] Disabled hover handlers
will no longer receive hover events, or block siblings from
being hovered.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-106548
Change-Id: I7f2e459ba39f1e23cdb13bf94f8754e185dcd0c1
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We pass the system import path(s) explicitly. We don't want the tools to
guess them.
Task-number: QTBUG-106365
Change-Id: I529d5e79fa0331e6994be0d8a659d4a4556be1dd
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
(cherry picked from commit fecd60e62d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The settings that were previously only controllable via environment
variables get now a counterpart in QQuickGraphicsConfiguration. The
env.vars. stay since most of them are fully documented so must
continue to function as before. Now they just have a way to enable the
same from C++, on a per-QQuickWindow basis (if being per-QQuickWindow
is applicable, that is)
Most importantly, productize and document the pipeline cache save/load
feature.
This now has support both for specifying a custom filename for saving
to or loading from, and in case nothing is set explicitly it has an
automatic solution similar to the Qt 5 era GL program binary cache,
under the standard CacheLocation of the system. And it works for all
the graphics APIs, storing whatever the QRhi returns as the "pipeline
cache" blob.
With the default threaded loop the new cache control APIs are a grand
improvement: instead of having only the global environment variables
(QSG_RHI_PIPELINE_CACHE_SAVE/LOAD), one can now control
per-QQuickWindow from C++ where the pipeline cache is stored. This
allows sophisticated applications to support caching shaders/pipelines
for multiple windows in a sane way (i.e. with different cache files,
this way no conflicts and overwriting of each others caches happen).
It also allows pre-seeding (deploying the cache file to another
device, thus accelerating the very first run of the application
already) in a simple way: run with saving the cache contents to
whatever file is desired (even better, loading can still happen from
the standard cache location, so it is not necessary to start
revisiting all views and states to get pipelines/shaders compiled if
the application was used before), then ship the file and load
explicitly from that. (the usual caveats apply: the cache is ignored
if the GPU or driver version do not match; the exception being data
from D3D11 as that is freely reusable between PCs)
It turns out that having a nice API design is not ideal for the
'basic' render loop, but there is nothing we can do about it. While we
now have a way to control the pipeline cache storage per-QQuickWindow,
it won't actually work on a per-window basis with the basic loop
because that uses the same QRhi for all windows, and so the API
structure falls apart: having per-window settings that affect the
underlying QRhi is actually futile. (but given that QRhi is not public
there is no other choice really and for 'threaded' we still want a
proper per-window solution) This could be addressed in the future by
converting the basic loop to also use dedicated QRhis for everything
(which may involve some caveats). For now it is documented that the
basic loop will only take one window's settings into account when it
comes to the cache.
Note that there is no support for QQuickWidget. As the architecture is
totally different, with the QRhi infrastructure controlled by widgets
and the backingstore, that is out of the scope of Qt Quick to solve.
The biggest change is the automatic pipline cache which is on by
default, as long as no explicit filenames are given (it can be
disabled in some other ways as well (env.vars/app.attribute), but this
should rarely be needed in practice) This is expected to give a boost
to all applications on all platforms, although the gains will be small
on systems where the drivers employ their own persistent caches (which
is quite common these days, esp. on Windows and macOS). Nonetheless
there will still be small improvements, with milliseconds shaved off
of the total time spent on compute/graphics pipeline creation during
the lifetime of a QQuickWindow. Big improvements are expected to be
visible with D3D and Qt Quick 3D: the cache stores the DX bytecode
(Quick 3D's run time material shader building causes HLSL code to be
compiled at runtime) so apps using View3D are expected to benefit a
lot from this.
Task-number: QTBUG-103802
Task-number: QTBUG-106545
Change-Id: I01269424784b02114b88c4a712cf64512ff68ed7
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
This reverts commit 62ade27f05.
There is already another RESOURCE_PREFIX in this QML module.
Change-Id: I9afdb74c0aec11a604b9b49cc0baed2ec5795a0e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Chat Tutorial application was not able to find main.qml file when using
qmake. It was caused by cmake adaptation for using qt_add_qml_module.
The main.qml file is currently searched in the chapter directory.
To these changes also qmake configuration must be adapted.
Pick-to: 6.4 6.3 6.2
Fixes: QTCREATORBUG-27655
Change-Id: I1e92d806dbfeb17e613596f96fd24f53fb6eba1d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
QQmlTypeloader and QQmlTypeLoaderThread so far used to manually call ref
and deref on QQmlDataBlob pointers. Changing the refcount was necessary,
as the blobs were stored in various data structures which should keep
the blobs alive; namely the Message struct subclasses use in QQmlThread
and the NetworkReplies hash-map.
However, the whole setup was rather brittle; especially when it comes to
QQmlThread, where methods adding Message structs would increment the
refcount, and the actual callback stored in the Message would decrement
it. This would obviously cause leaks if the Message::call would not be
invoked (e.g. due to the QQmlThread shutting down).
By replacing the raw pointers with QQmlDataBlob::Ptr (which is a new
typedef for QQmlRefPointer<QQmlDataBlob>), we can avoid the whole
issue[1], and also simplify the code. Note that Message stores a
QQmlDataBlob::Ptr by virtue of inferring the type from its stored
method.
[1]: At least in theory; QQmlThread does not clean up its message list
on shut-down so far.
Change-Id: I6aaf5a9dcddfd38795059518ca2d3650072bcda3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Instead of handling member functions of different arity with dedicated
functions, simply use variadic templates and std::tuple. Moreover, move
the creation of the Message object into a dedicated helper method, so
that it can be shared between all methods.
Change-Id: I493afb2350e9cf47ea90b3532ae2a7da074d8083
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We can do all the necessary work in the ctor and dtor.
Change-Id: I64597022b1bcbb9604a590b188e67e1af59070c2
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ulf Hermann
Mitch Curtis
Semih Yavuz
Laszlo Agocs
Qt Submodule Update Bot
Fabian Kosmale
Alexey Edelev
Sami Shalayel
Richard Moe Gustavsen
Tim Blechmann
Janne Juntunen
Jan Arve Sæther
Volker Hilsheimer
Shawn Rutledge
Vladimir Belyavsky
Timur Pocheptsov
Bartlomiej Moskal