The QQuickWidget doesn't normally own the RHI; the QWidgetRepaintManager
does, via QBackingStoreRhiSupport. If the top level widget is destroyed,
so is its QBackingStore, and the corresponding RHI. But the QQuickWidget
may outlive its top level parent, in which case it needs to update its
cached reference to the RHI, and do proper cleanup before it goes away.
QRhiWidget already does the same thing, for the same use-case.
This was observed when recreating the top level QWidget via destroy/create
as part of the RHI widget compositor logic.
Fixes: QTBUG-119760
Pick-to: 6.6 6.5
Change-Id: Ic44449abcfe4271660a3ac4e132d0c4a71a21b65
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 0d342e8312)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QAccessibleQuickWidget delegates all calls to the QAccessibleQuickWindow,
which it had as a member that was initialized at construction time to
the offscreenWindow backing the QQuickWidget. Both are QAccessibleObject
subclasses, and QAccessibleObject stores the object it wraps as a
QPointer. The QAccessibleQuickWindow's object becomes null when that
offscreen window gets destroyed (for instance, when reparenting).
We might get called by the accessibility framework in that situation, as
we are clicking a button and the hierarchy changes.
To prevent crashes, we need to test for nullptr in QAccessibleQuickWindow.
However, that alone would leave us with a useless QAccessibleQuickWindow,
and in turn with a useless QAccessibleQuickWidget instance.
The QAccessibleQuickWindow is not directly exposed to the
accessibility framework, and all calls to it are dispatched through its
QAccessibleQuickWidget owner. We can't repair the QAccessibleQuickWindow
but we can replace it entirely if we manage it as a heap-allocated
object. Use a std::unique_ptr for that, which we can reset with a new
instance created from a new offscreen window in order to repair things.
We can now either test in all functions whether the window's window is
still alive. Or we can handle the destroyed() signal of the offscreen
window. The latter solution is a bit more involved, but generally more
scalable as we don't have to remember to check, and possibly repair, in
each QAccessibleQuickWidget function.
Pick-to: 6.5
Fixes: QTBUG-108226
Change-Id: Ib19c07d3679c0af28cb5aab4c80691cc57c4e514
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The subFocusItem state was forgotten because the old parent was deleted,
before its focused child was reparented.
The test doesn't pass on Android and makes the test process exit with
error. Since it prints warnings that indicate issues further down in
the RHI stack, we'll skip it for now on that platform.
Task-number: QTBUG-112696
Pick-to: 6.5 6.2
Change-Id: Ibb32a11564ff6fbb2091c241d508f12479b234b0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Renames the pressed() getter of the pressed property in QQuickMouseArea
to isPressed() to avoid overloading the pressed()-signal.
Signals should not be overloaded. Also, it makes code generation in
qmltc more complicated.
Task-number: QTBUG-110029
Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
A QQuickWidget contains a Quick UI, which can be expected to handle
touch events, and it handles touch events by forwarding them to the
QQuickWindow. So set the AcceptTouchEvents attribute and let the
Qt Quick delivery machinery deal with the touch-mouse synthesis
within the scene.
Also, Qt Quick's event delivery might return event points as ignored
after setting the exclusive grabber. Qt Widgets touch event delivery
logic doesn't care about exclusive grabbers, and relies on the event
points being accepted to make the widget that received the TouchBegin
an implicit grabber. QQuickWidget needs to translate those states back,
so accept all points that come back with a grabber.
Add a test that verifies that a button in a popup gets all events,
and that those events are translated correctly - without the fix,
the "clicked" test fails, as the release is delivered, but with
coordinates outside of the button.
Also test that we can have two QQuickWidgets where each gets one
touch point.
Fixes: QTBUG-101736
Pick-to: 6.5 6.4 6.2
Change-Id: I3a2bf05fd297ae4d72b6e236ecd8e5ddac37ce06
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8:
auto QtContainerClass = anyOf(
expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o),
expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o));
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container',
with the extended set of container classes recognized.
Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
In Qt 6, any QQuickItem that wants to handle touch events needs to
explicitly enable them by calling setAcceptTouchEvents(true).
This was anticipated in 1457df74f4
and ab91e7fa02
If an Item calls setAcceptTouchEvents(true), it will not receive
synth-mouse events, even if it calls ignore() on a particular
touch press event. So now in this test, when we want to test
synth-mouse events, we call setAcceptTouchEvents(false).
Task-number: QTBUG-86729
Task-number: QTBUG-101736
Pick-to: 6.4 6.3 6.2
Change-Id: I71d2f213bc62206c190c94de5e4d39ce17504a0d
Reviewed-by: Doris Verria <doris.verria@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This test does the following:
- QSKIP reparentToNewWindow() because it crashes on Android
- QSKIP enterLeave() because Android does not support cursor
- Fix resizeOverlay() and focusOnClickInProxyWidget() by using
QTestPrivate::androidCompatibleShow() that takes desired widget size
and position into account while showing on Android.
Task-number: QTBUG-100173
Pick-to: 6.3 6.2
Change-Id: I383d7d80ca645ca50c7a843d4906a99e1bb0d0ea
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Launching with QT_QUICK_BACKEND=software should never lead to doing
anything QRhi-related, neither in Qt Quick, neither on the Widgets side.
Fixes: QTBUG-101884
Change-Id: I0dc47e04a0d32904db04f32a1db109029f8f4b44
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
When it comes to examples, quickwidget has the direct OpenGL usage
removed because we want this example to be working with any graphics
API. qquickviewcomparison, which features direct OpenGL usage within
its Qt Quick scene, is renamed to a more descriptive name and is also
getting a doc landing page. It continues to be requesting OpenGL (via
QRhi) explicitly.
Change-Id: Iae5b835441f3af229e9746e14dedbe9d1a62b2b9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QQuickWidgetRenderControl::renderWindowFor() did not take the proxy
widget into account, making it impossible to give focus to items
inside a QGraphicsProxyWidget by clicking on the item.
This patch is based on a patch by Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>,
which fixed renderWindowFor(), but did not handle the case where a proxy widget
was in multiple views.
This version of the patch adds QQuickRenderControlPrivate::isRenderWindowFor(),
which allows all the views of the proxy widget to handle focus.
This patch also carefully preserves the non-obvious feature of the
previous implementation where all windows are considered to have focus
if QGuiApplication::focusWindow() == nullptr.
[ChangeLog][QuickWidget][Quick items inside a QuickWidget that is inside a
QGraphicsProxyWidget can now get focus by clicking.]
Fixes: QTBUG-91479
Pick-to: 6.2
Change-Id: I4a6fbbbeda2d14b5a6d8eb8218d5b14a3404d9c3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Previously each test would include and build sources from the shared
folder. Now we make those sources a library, build it once, then have
each test link to it instead.
We also take the opportunity to move some helpers that qtquickcontrols2
had added into the quicktestutils library where it makes sense, and
for the helpers that don't make sense to be there, move them into
quickcontrolstestutils.
We add the libraries to src/ so that they are internal modules built as
part of Qt, rather than tests. That way we can use them in a standalone
test outside of qtdeclarative.
Task-number: QTBUG-95621
Pick-to: 6.2
Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Unlike in the QWidget-based desktop world, Qt Quick scenes can
be rendered in a variety of ways, some completely offscreen
wthout any native windows on screen, whereas some (most notably,
QQuickWidget) work offscreen but in association with an on-screen
window that is not the QQuickWindow. Therefore, every time a
QQuickWindow is accessed, typically from QQuickStyleItem, it needs
to be considered if further resolution is needed.
For devicePixelRatio, there is a handy helper available in form of
QQuickWindow::effectiveDevicePixelRatio(). This picks up the dpr
from either the QQuickWindow or the QQuickWidget's associated
top-level QWidget window (or whatever window a custom
QQuickRenderControl implementation reports).
Elsewhere, where we need a QWindow in order to do native window
things, QQuickRenderControl::renderWindowFor() must be called to see
if there is another QWindow we should be using in place of the
QQuickWindow.
Pick-to: 6.2
Fixes: QTBUG-95937
Change-Id: I0690915d995ebb5f5cc0c48f565dfaf978e849ea
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>
Reviewed-by: Samuel Ghinet <samuel.ghinet@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>
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
...and fix up the docs.
The string-based setSceneGraphBackend() stays of course (the docs have
been enhanced, however). The GraphicsApi enum-based overload is now
renamed to setGraphicsApi().
Using the same name for both functions is a historical artifact, reflecting
the evolution (5.0 - 5.8 - 5.14). In 6.0 we can give it a more appropriate
name, since it does not have much to do with "backends" from the user's
perspective.
Change-Id: Id75dbf81f50a148797e5b5de9be4000153737473
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Also adapts to new NativeTexture format, where the actual
handle is passed around instead of a pointer to it.
[ChangeLog][QQuickWidget][Important Behavioral Changes] In
earlier versions, the returned value from QQuickWidget::quickWindow()
would persist for the life time of the widget. This is no
longer the case, so if you are connecting to its signals, make
sure you also connect to its destroyed() signal and update the
connections when it is destroyed.
Fixes: QTBUG-78638
Change-Id: I33cee8543ef1ff5d31555ed3ac18ba78c9c45102
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The evaluation callback does not have to perform the comparison anymore
and the shared pointer of the private is not used in the API anymore.
Also, the versionFunctions() has been moved out of QOpenGLContext
and renamed QOpenGLVersionFunctionsFactory::get().
QHash doesn't keep iterators stable under erase(), so clean up
the code relying on it, and avoid an intermediate QList at the
same time.
Task-number: QTBUG-74409
Change-Id: I90176be1067d88c8f2b1ea07198a06d432f5be9c
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
In a typical Qt Quick application, when a window is resized, the
contentItem of that window is resized with it, and then the root item.
QQuickOverlay in qtquickcontrols2 listens to size changes in the
contentItem (QQuickRootItem) via addItemChangeListener(), as a cheap
way (e.g. no signals) of knowing when to resize background dimming
effects. It resizes the dimmer item to the size of the window.
The first problem with QQuickWidget is that it only ever resizes the root item
when using the SizeRootObjectToView resize mode, and not the contentItem.
The second problem is that the root item is resized (via updateSize()) before
the window itself even has a size (which happens in
QQuickWidget::createFramebufferObject() via the call to
d->offscreenWindow->setGeometry()).
To demonstrate the second problem in detail, consider the following widget
hierarchy (written in everybody's favorite language: QML):
QMainWindow {
QQuickWidget {
QQuickWindow { // QQuickWidgetPrivate::offscreenWindow
QQuickRootItem { // QQuickWindowPrivate::contentItem
Page {} // QQuickWidgetPrivate::root
}
}
}
}
The QMainWindow starts off as 200x200. When the window is resized,
QQuickWidget::resizeEvent() is called. The first thing it does is call
updateSize(), which in the case of SizeRootObjectToView, resizes the root item
to 300x300. This causes QQuickOverlayPrivate::itemGeometryChanged() to be
called, and the dimmers are resized to the size of the window, but the window
still has its 200x200 size, as it is only updated later, when
QQuickWidget::createFramebufferObject() is called.
This patch fixes these issues by ensuring that contentItem and the window
itself are resized along with the root item.
As to why such manual intervention is necessary: from what I can see, it is
because it's an "offscreen" window. This means that
QWindowPrivate::platformWindow is null, and setGeometry() takes a different
path that presumably results in no QResizeEvent being sent to the QQuickWindow.
As QQuickWindow relies on resizeEvent() being called to resize its contentItem,
the contentItem is never resized. With a typical Qt Quick application, all of
this works as expected.
Change-Id: I7401aa7a9b209096183416ab53014f67cceccbe4
Fixes: QTBUG-78323
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The triggerUpdate call was incorrectly removed by merge 42f485231c
Fixes: QTBUG-68566
Change-Id: Ibf37d88315d3ef9879e6cb9728a1c4ef4655c72b
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
On eglfs platform input events are driven by libinput and
do not have window information as such. They are simply
delivered based on QGuiApplication::topLevelAt window selection.
In case of WebEnigne, QQuickWindow is returned as top level window.
QQuickWidget uses this QQuickWindow as an offscreen window,
however since 561b932 we fake 'visible' and 'visibility' values so
windows api in qml can use those properties. This ends up with broken
event delivery on eglfs, since window is offscreen and therefore
not really visible.
Make a minimalistic change to fix the issue, without braking
QTBUG-49054, which requires 'visibility' to have fake values,
and 'visible' will keep window as not visible for event
delivery system.
Fix encapsulation of setVisible(), prevent accidental window
creation when setVsiible() called from qml via binding.
The proper fix would require for example adding some new flag
to underlying offscreen window, which could be used
by event window selection mechanism or rework of qquickwidget
offscreen window parameters expose to qml.
Task-number: QTBUG-65761
Task-number: QTBUG-49054
Change-Id: I2a307ee5613771adf6d31f1c3cc4b4a25d7620df
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This happened if the "real mouse" was never moved, since moving the real
mouse caused it to update the internal
QQuickWindowPrivate::lastMousePosition. If the window never got any
mouse events, it would therefore fail to generate proper hover events.
However, if the window got exposed under a mouse cursor it would generate
a hover enter event. We therefore update lastMousePosition when that
happens also.
Change-Id: I77d9b1bd779a813756c4056b015f2e81664b6d36
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
In tst_qquickwidget::enterLeave(), retain the changes from
9d2a929fa4 rather than the cherry-pick.
Don't hard-code 5000ms timeout on qWaitForWindowExposed(): it's the
default anyway.
Task-number: QTBUG-64397
Change-Id: I67e4566c2c7f9e361a79e3a091436c3391f39786
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry-picked from commit 239b8f6ee8)
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Take the available screen geometry and window borders into account
when positioning windows and moving cursors.
Task-number: QTBUG-64397
Fixes: QTBUG-72305
Change-Id: Ia2b35a0deb144ab7194f7658d599888ff9d4a706
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected
behavior of QGuiApplicationPrivate::processTouchEvent, but had no
effect in Qt Quick. QQuickWindow also accepts the touch event
just to make sure that QGuiApplication will not synthesize mouse
from touch, because it would be redundant: QQuickWindow does that
for itself.
Now we make it have an effect in Qt Quick too: skip mouse synthesis
if it is set to false. This provides a way to simplify the
event delivery. If you set it false, then you cannot manipulate old
mouse-only items like MouseArea and Flickable on a touchscreen.
(You can of course use event handlers for that.)
[ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse
event synthesis in QtQuick by calling
qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false);
This will simplify and speed up event delivery, and it will also prevent
any and all interaction with mouse-only items like MouseArea and
Flickable on a touchscreen.
Task-number: QTBUG-52748
Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When pressing tab/backtab then the offscreen window needs to pass it on
to the item in case it will handle this for changing focus. If it does
not handle the event, it will pass it back for QWidget handling.
[ChangeLog][QQuickWidget] Tab presses are now passed on to the root
item to be handled first. When not handled by the root item, it will
be handled like a standard QWidget.
Task-number: QTBUG-45641
Change-Id: Ief0552ba496c87ab0b6e12aa8e67ef44b5a20ae2
Reviewed-by: Liang Qi <liang.qi@qt.io>
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Make sure events are delivered as expected and that synth-mouse
events have the right source().
Task-number: QTBUG-64241
Change-Id: I95a073ce0faea2111c8e1aca42fa44c1b529a6ec
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
QQuickWidget thinks of itself as a toplevel window, so it cannot process
the offsets in a parent window.
Amends 41293196b4.
Task-number: QTBUG-65800
Change-Id: I8c5dcb8f44a6cbdb58bcc956d8263e68d8180bec
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
By passing the enter and leave events to the offscreen window it will
enable mouse areas inside a QQuickWidget to know when the mouse has
actually entered or left the area if it is covering the whole item.
Task-number: QTBUG-45557
Change-Id: I670ebe30e367e919c73fed449bf2bed7ca42b5fd
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Some tests needed fixing
- Disabled tests too heavy for qemu
- Skipped tests requiring OpenGL without support from the platform
- Skipped tests requiring functionality on broken offscreen platform
- Skipped tests that take too long on qemu + software renderer
- Blacklisted tests for created bugs QTBUG-63049, QTBUG-63053
QTBUG-63055 and QTBUG-63057
Task-number: QTBUG-60268
Change-Id: I0346b0e436cf286d7d9cbc140acf324a4087cfb9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Test that it actually didn't grab a blank pixmap,
as happened with QOpenGLWidget in the past.
Change-Id: Iee8e7ff2f3fa2f2223a2a284fec96d96f62e36a6
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
This is now essential since otherwise these events are simply lost.
Amends 0dbc575c1a
Task-number: QTBUG-60988
Change-Id: Ib1d99d8fcd5bb92c9b52977796f2910f0fe71c48
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Right now many cases outside of text input fields are simply broken,
e.g. one cannot use a TableView or other controls with the keyboard.
Removing the seemingly unnecessary focusObject() solves all problems
since this way key events get delivered to the QQuickWidget which in
turn forwards to the QQuickWindow.
Directly routing into the QQuickWindow's focusObject(), which can be
any item in the scene is wrong since it skips a big part of
QQuickWindow's event handling logic.
Task-number: QTBUG-45757
Change-Id: Ie53b9003d156ab019fa4b9cf461e209990e738f7
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
QOpenGLWidget has offered a lot more fine-grained control over the lifetime
of the OpenGL context it uses for rendering. In practice QQuickWidget also
requires at least a part of this. To unify the behavior when it comes to
reparenting to a different top-level window, add the bail out condition for
AA_ShareOpenGLContexts to QQuickWidget as well.
[ChangeLog][QtQuick][Important Behavior Changes] QQuickWidget now behaves
identically to QOpenGLWidget when it comes to handling window changes when
reparenting the widget into a hierarchy belonging to another top-level
widget. Previously the OpenGL context always got destroyed and recreated
in order to ensure texture resource sharing with the new top-level widget.
From now on this is only true when when AA_ShareOpenGLContexts it not set.
Task-number: QTBUG-54133
Change-Id: Ifda0db76fdf71dae1b9606fb5d59cee6edc2f5a4
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
A common usecase appears to be to set variables in the rootContext
before loading a url in a QQuickWidget. We there need to ensure there
is a QmlEngine to set variables on when this is attempted.
Change-Id: I07aff2104313eeb3fab902ea3c6043c3c82c50f7
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QQuickWidget may be used with just a root item, and won't need a
QmlEngine in that case. So if one isn't given to the constructor, only
create one when one is needed for evaluating source.
Change-Id: I96cfe5e2473d5d53fc2d52d4646d36c43f4ccb8a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>