| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Restore the position of the single event point after event delivery.
Where possible, don't make a localized copy which explicitly shares
its data with the original anyway. Instead, access the original
directly.
Change-Id: I5efa44c336eddeef1a1ab00dc91e2d0f223ed31d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem()
doesn't need to call item->mouseUngrabEvent() because all grab changes
are notified via the connection from signal QPointingDevice::grabChanged
to slot QQuickWindowPrivate::onGrabChanged(). But in this case,
MouseArea only accepts the event, rather than taking the grab itself.
Therefore at the time the grab is "stolen", there was not yet any
grabber, because grabbing is done after delivery. But we still need to
inform MouseArea that it's not getting the grab it expects to get, so
that it can reset its pressed state. But we don't want it to be
redundant (other tests are counting events, and we don't want repeated
ungrabs to show up in those); so now we have to track whether the item
on which we're about to call mouseUngrabEvent() has already gotten it.
This illustrates another problem with the tradition of accepting events
and being unclear about what it means. Grabbing is one thing, ending
delivery is another.
Amends a97759a336c597327cb82eebc9f45c793aec32c9
Task-number: QTBUG-55325
Task-number: QTBUG-86729
Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a QQuickWindow is deactivated, visiting every item in the entire
scene to tell them the news isn't very efficient, especially considering
that the only item that overrode this virtual function has been
QQMouseArea, throughout the lifetime of Qt 5. If it's important to
cancel grabs of MouseAreas, then it's equally important to cancel grabs
of MultiPointTouchArea, pointer handlers, etc. It should be OK to
delete the virtual function since it was never documented, and marked
\internal, so hopefully no users are depending on it.
The existing tst_QQuickMouseArea::pressedCanceledOnWindowDeactivate()
test continues to pass, which proves that the WindowDeactivate event
still has the desired effect on MouseArea.
Change-Id: I0109370aba14096fb7777a83cf1b6763ac58013f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
| |
Change-Id: I3b2d1fbc4b62b501aa6ed748a692cb4bba261c5e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
-changes to Qt Quick QML Types and OpenGL support
-content from doc/src/qmlapp/applicationdevelopers.qdoc
Task-number: QTBUG-87156
Change-Id: I3384e5bfa070c891015e5aa4af2e2c0b2dae35cf
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
| |
Also don't mention qmlExecuteDeferred: That one is internal anyway
(albeit not explicitly marked as such yet).
Change-Id: Icef5fb4092b6a109613ae1f2e90fcff93d7c0b4b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
| |
Change-Id: If3640ef5cbb6df4b199b481410e79e94ea763645
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need to handle symbol clashes with QtQuick1 anymore.
[ChangeLog][QtQml] The functions qmlDebug, qmlInfo, and qmlWarning are
no longer available in the QtQml namespace. Use their counterparts in
the global namespace.
Fixes: QTBUG-88637
Change-Id: Ia74510bd711790cebf55de4cd668891712f6835e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to un-blacklist the test for QTBUG-60123. To that end:
revert 7b2e2117162594a2d0234bb02408f5b5a446488b and its followup
6933b7e8e6dc279a8eb34e1f4c60bc109dfb7d26. There is no detailed bug
report explaining exactly why those were done, just the comment on code
review: "This fixes the desktop components' combo box on linux
re-opening at random times", probably referring to a combobox popup
window in Controls 1. But when using QWidget::createWindowContainer()
in two different windows and clicking MouseAreas in each of them, it
turns out that this change of focus is causing the mouse grab to be
canceled. The grab should be naturally given up after mouse release;
canceling prematurely doesn't make sense.
The Qt 5 fix for this bug was e0c30279ec1fad88346ed3fb483bc3c672fdd01b
which tracked the grab on a per-window basis. It would be difficult to
do that again now (change QPointingDevicePrivate::setExclusiveGrabber()
to store a separate grabber for each window in which a grab occurred?
what could go wrong...) It seems odd to have the same QEventPoint
grabbed in two different windows at the same time, but popups need event
forwarding so maybe that was why (if a MouseArea triggers the popup,
should it stay pressed and keep its grab? the subsequent mouse moves and
the release need to be forwarded to the popup, so maybe something inside
the popup needs a grab, simultaneously or not). Anyway we don't have
actual popup windows in Controls 2 right now; and we know that event
forwarding for popups needs work in QtGui so that it will be easier when
we try again to have them in Qt Quick (QTBUG-68080). So perhaps the
original workaround has outlived its usefulness: popup event forwarding
needs to be handled at the lower layer, not in Qt Quick.
Task-number: QTBUG-57253
Task-number: QTBUG-60123
Task-number: QTBUG-86729
Change-Id: I56dbc3bb94f66a7f26f79a97bcb2f2bbc0b7aa92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing static builds, mkspecs/qml_module.prf embeds the qmldir
file and any additional foo.qml files into a generated Qt resource
file.
The resource name is called qmake_<qml_plugin_uri>.qrc.
In turn, certain Qt modules and plugins code call
Q_INIT_RESOURCE(<qml_plugin_uri>) to initialize the resources.
When Qt is built with CMake there were 2 differences.
Because the resource files are not compiled into the static libraries
but rather passed around as object files, there is no need to
call Q_INIT_RESOURCE() anymore.
The second difference was that the generated resource name for
resources containing the qmldir file was '<qml_plugin_uri>_qmldir'.
The differences in the CMake build caused issues when linking a
QtQuick3D example project with a static Qt.
That happened due to the mismatch of the generated resource name in
the Q_INIT_RESOURCE() call.
Unfortunately these calls can't be removed during the build system
transition phase because that would break qmake Qt builds.
To fix this, change the name of the CMake generated resource to match
the qmake name. This avoids the undefined symbol errors during
linking, but is actually a no-op! That's because the global
initializer in the linked resource object file will be called before
the manual Q_INIT_RESOURCE() call, effectively making the latter a
no-op.
Note there is one more difference regarding the CMake build. The Qt
CMake builds creates 2 different resource files, one for the qmldir
file (inside qt6_add_qml_module) and another separate resource for qml
files (inside qt6_target_qml_files).
qmake in comparison creates only one resource file for both.
In practice this shouldn't affect or break anything, because even if
there is no explicit Q_INIT_RESOURCE() call for the qml files
resource, the global initializer will still be called from the linked
in object file.
An issue might happen if there are qml files, but no qmldir file,
because then the qmake-required Q_INIT_RESOURCE() would not be called
due to the missing qmldir resource (as generated by CMake).
I think such a scenario is very unlikely if not impossible.
Task-number: QTBUG-88425
Change-Id: Ib12d93d0dae52785ba8182db6829f03524723ca7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After any call to qt6_add_resources we need to record info about the
resource object files. These will be embedded into the appropriate prl
files to ensure that any application built with qmake links in the
resources (only relevant for static Qt builds).
The implementation is a bit ugly, but it gets the job done for now.
It checks for the existence of an internal Qt function in the public
macros and calls it if it's available. That will only happen when
doing Qt builds. For regular app projects the functions will not be
called, but we don't generate .prl files for such projects either way.
Note that this comes with the same limitation as described in the
changes for fixing QTBUG-88425. Specifically, the functions will only
record resource object files for targets built as part of the current
CMake invocation (aka just one repo for non-top-level builds).
This handles the most common issues, but is not a complete fix.
Task-number: QTBUG-87702
Change-Id: If632fdf9867cec4b24b1c6136d23ee9d8b56e650
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
Change-Id: I4bb4a66b7ccca838e058962bbc297659b273c78e
Done-with: Fabian Kosmale <fabian.kosmale@qt.io>
Fixes: QTBUG-84416
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Change-Id: Id81fcbd8e6869239ad4625907819987463443d07
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
| |
-fixes qdoc warnings
Task-number: QTBUG-86102
Change-Id: I2e2a2f98d7127629bedc06612d6c6b4f7e57fb52
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collect content of 'qmldir' file that is generated by
'qt6_add_qml_module' and 'qt6_target_qml_files' functions, instead
of write content to file immediately.
Use 'cmake_language(DEFER CALL)' to call 'configure_file' write
whole 'qmldir', when finalizing CMAKE_CURRENT_SOURCE_DIR scope.
This way a reconfiguration will not rewrite the files,
touch the timestamps, and thus needlessly rebuild.
Task-number: QTBUG-88172
Change-Id: Idca68e4ceed13d0aa7eac443e769d5677557b880
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
QMutableTouch/SinglePointEvent can be publicly copy constructed from their
non-mutable counterparts, make use of that.
Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
was only possible if qml_network is disabled
Pick-to: 5.15
Change-Id: If8a8addc0aa5c4c768dd7df3aa4d627f82a78059
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
|
|
|
|
|
| |
Change-Id: Iba9f99f0fcdb7692ceadaec223d82e425f1e424b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to resolve the types for QML elements in two passes because only
after finishing the parsing we have the QML-declared methods and
properties available. We already need the base type before, though.
Also, there can be multiple methods of the same name. We need API to
access them.
It also turns out that the internal name of the "var" type has to be
QVariant in order to match reality. "var" properties and unnamed
arguments to JS functions are implemented as QVariant.
Change-Id: I541f11e96db72d832f4e4443d3a5d31079a56575
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I173e2ff05b3fc3bbe56df423abcbfc84bdc2a17a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
| |
In this case we need to pass a pointer to the return variant itself, not
to its data.
Change-Id: I86e468f106f29e1f1be8adee9882d465fd6da533
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon a QWindow destroy() and show() we can get to syncAndRenderer
with sync not requested. It will be followed by a full sync+render
request afterwards, but first we need to gracefully survive that
somewhat obscure initial round (obscure because the window is fully
usable, so we get a swapchain, but then we do not sync, so there is no
QSGRenderer created)
Exhibited by tst_qquickwindow::headless. It correctly showed a warning
on all platforms and rhi backends, but was only fatal on macOS and Metal
for some reason.
Fixes: QTBUG-88513
Change-Id: I0396b648af0fd2bef2964b79a28359a7f806530d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Scene graph changes are documented in the section further down.
Task-number: QTBUG-88152
Change-Id: I6362999e6830e05981e95af78b3d2f00b5e398e3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes tst_QQuickListView::touchCancel again. In this scenario, a
TouchCancel is sent, but gets turned into an UngrabMouse for delivery to
the MouseArea which is the current grabber.
We try to avoid calling QQuickWindow::mouseGrabberItem() because it's
too vague a question to ask (which mouse? or did you mean the synth-mouse
during synthesis from a touch or tablet event?); and now it acts different
anyway, because eventsInDelivery.top() is an UngrabMouse, which did not
include a pointer to the QPointingDevice until now. So now we turn
the UngrabMouse event into a QSinglePointEvent so that it's possible to
get exclusiveGrabber() and check that the grabber is not the same
Flickable. (Otherwise, the grabber that's getting ungrabbed is usually
the child receiver item sent to childMouseEventFilter().)
Task-number: QTBUG-86729
Task-number: QTBUG-74679
Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In QQuickWindow, we instantiate QQuickPaletteProviderPrivateBase, which
in turn instantiates its updateChildrenPalettes method, which then calls
QQuickItemPrivate::inheritPalette. However, QQIP is an incomplete type
at this point. Including qquickitemprivate_p.h would currently create a
cyclic dependency, and breaking that dependency might mean outlining
performance sensitive code.
Thus we instead (ab)use the fact that updateChildrenPalettes is virtual,
do nothing in the specialization for QQuickWindow and instead implement
the method in the same way as an override in QQuickWindowPrivate.
Task-number: QTBUG-88457
Change-Id: I49b357d7a67f1945a4d3c25e8cabd428d1454aa7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
| |
This is a single char16_t, not an array of them.
Pick-to: 5.15
Change-Id: I55d23ebb5f2abebd43cd4160a75d373706392ddf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that
has acceptTouchEvents() == true merely fails to accept one touch event,
that does not mean a mouse event should be sent.
Finish changing the default to false: handling touch events is opt-in,
just like handling mouse events; most items don't. And if you opt in,
then you MUST handle touch events, because you will NOT receive mouse
events as a fall-back.
Now that Flickable handles touch, filtering multi-touch events becomes
relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch
when Flickable grabs a stationary touchpoint at the same time as another
touchpoint is pressed, preventing a child PinchArea from reacting.
So there's a new rule: just as we start over with event delivery when a
new point is pressed, QQuickFlickable::filterPointerEvent() should also
not immediately grab when any point is newly pressed; it can afford to
wait, because it's filtering, so it will be able to see if one point is
dragged past the drag threshold later on.
When a parent (such as Flickable) contains only mouse-handling items
(such as MouseArea), the parent should filter the touch event if it is
able (if acceptTouchEvents() returns true). Flickable is now able to.
Filtering parents that are not able to filter touch events can still
filter a synth-mouse event as before. But filtering both must be
avoided: then we would have the problem that Flickable filters a touch
move, sees that it's being dragged past the drag threshold, and sets
d->stealMouse to true to indicate that it wants to steal the _next_
event; then it filters a synth-mouse move, and that's perceived as being
the next event even though it's just a different view of the same event,
so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we
rely on the delay caused by waiting for the next event: the MouseArea is
trying to drag an item and the Flickable wants to flick; both of them
decide on the same event that the drag threshold is exceeded. But
MouseArea calls setKeepMouseGrab() immediately, whereas Flickable
doesn't try to steal the grab until the next event, and then it sees the
keepMouseGrab flag has been set, so it doesn't do it. If Flickable
could filter the same event twice (once as touch, once as synth-mouse),
this logic doesn't work, so it's effectively "more grabby" than
intended. So it works better to have it filter only the actual touch
event, not the synth-mouse that comes after.
When the child has pointer handlers, we need to visit them, and
therefore we should let Flickable filter a touch event on the way.
tst_FlickableInterop::touchDragFlickableBehindButton() depends on this.
[ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must
explicitly call setAcceptTouchEvents(true) to receive QTouchEvents,
and then it must handle them: we no longer fall back to sending a
QMouseEvent if the touch event is not accepted. If it has additionally
called setFiltersChildMouseEvents(true), then it will filter touch
events, not any synthetic mouse events that may be needed for some
children.
Task-number: QTBUG-87018
Fixes: QTBUG-88169
Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Change-Id: I09e29b85949eac270c6cee711408b8a09dea79a8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copying/assigning polymorphic types is a code smell, use separate
instances instead in the tests. Those should perhaps be rewritten
to use a data driven testing approach, there's a lot of code
repetition.
In the test API implementation, first evaluate the parameters for
the event, then construct the event once with the correct values.
Change-Id: I2572772698cb0204f5ff950741b9fe3805fae15d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
QEvent is a polymorph type, and even though it has a copy constructor,
we shouldn't use it.
Use the pattern as in QQuickMouse/WheelEvent.
Change-Id: I26ab7b831e1e8dd156c32417f74bc7d800bcf71c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
As we generated qmltypes files (albeit empty), we also have to advertise
them in the qmldir files. Otherwise qmllint will complain, as that is a
common mistake in old modules where qmldir files were written manually.
Change-Id: I4c96610930d89558cd363b7f9db28ec6e21ed4d5
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I10d30d1ba83f8db9568cef18a32baac1627b2c17
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
| |
Change-Id: Iacfffdc774d5ea6980af7a29da07a82f17799e33
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the qt.quick.hover.trace category, the position is the most
important thing for now. The output for "q" is verbose and usually
there's only one window anyway, so just put the title last, in case
we need to debug a multi-window scenario.
Dealing with hover in multi-device scenarios is going to be interesting
one of these days.
Change-Id: I2b687085432ce2e02ca764b8b4669282e0180c54
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
| |
Otherwise we get lots of "unused" warnings from the compiler.
Change-Id: I7744715c476350dd3bba34500589cb1c62672c9f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-88471
Change-Id: Ifc023fdc82b728931ff88c0c634ad71e2b2995a2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
All other type names are actual C++ type names. Also, correctly resolve
qreal if its type is overridden at configure time.
Change-Id: Ia2a1b4309f94e8c72461ee69005b1bdee6337370
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
It's turtles all the way down. And now we can verify builtins.qmltypes
using qmllint.
Change-Id: I10c98ff8837c04838c3fd9803ef4ea0fd5d7bd0e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes apps using Qt.Window with static Qt builds when
deployed to a machine that doesn't have Qt installed.
This will need a counterpart fix in qmake land.
Change-Id: Ife11f9d1f1826e1188ef3dc3933af2f243860b6f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When no C++ sources are passed to qt_internal_add_qml_plugin (a pure
QML module), create a C++ backed Qt plugin anyway.
In such a case, generate a dummy plugin.cpp containing a
QQmlEngineExtensionPlugin subclass.
The class name is autogenerated from the QML import URI.
The class constructor will call the qmltyperegistrar generated
void qml_register_types_foo() function, to ensure the needed module
versions are registered for the QML module.
Change-Id: I19959dafdf0dc837c6037e7dc1d549b7420110a7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
That's a recurring thing.
Change-Id: I8dc049a559e337c70089dd1f81ff23bf7d2140fe
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
That is a noop and produces a warning.
Change-Id: I75787aee66b55522005247524140e3f3a7dd56ba
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
| |
Change-Id: I1dac3e33289516ec677d6db0d8d7cf1e02addc16
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
| |
Don't crash and make it work as expected.
Task-number: QTBUG-37491
Change-Id: I0b94fdfa0a79dd43b762b03b24e3415762eecd95
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
| |
There always has to be an empty last function. Otherwise we might access
invalid memory when loading them.
Change-Id: I5e7a784c14ac8a12450926b895664a98c03f85f1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Particles using DrawTriangles are taking pixel ratio into account,
while particles using DrawPoints used raw pixel sizes. Change points
to also scale based on dpr. This way particles with different
backends and performance levels remain the same size.
Task-number: QTBUG-88240
Change-Id: I3988a0ad8e741626a56a41b08aed0500e5be0c62
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
| |
Pick-to: 5.15
Change-Id: If63f4c59f18bc0754ce2e68e424f6efd0f512d30
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing QML files, we need to keep the enum values around as this
is the only place where we can find them (without parsing the same file
again, that is). With C++ types we don't strictly need them as they are
also available from the C++ header, but if the qmltypes file is nice
enough to provide them, we can use them. (Which will be for types that
are not actually C++ types, but rather types produced by registering a
QML file with qmlRegisterType()).
Change-Id: Ibcc93b30e523a00e1eeb80029943c48b83d0e1b5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
Makes no difference in this case, as it's UTC, but is terser and
perhaps slightly clearer.
Change-Id: I7de315def2f45ec4a12d2a682e5d1d7a4d0a3e6d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-88379
Change-Id: I6e2ea550d8f8972c5fdcdc21a5e3851992c591a5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|