For qmake we have no choice but to ship the .qsb files, whereas with
CMake we now rely on qt6_add_shaders.
Pick-to: 6.2
Change-Id: I9bb64a3ffd01cda84fca5a0f7def270975bf71aa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Partially resolved property types will result in properties not being found as well and thus we should warn about them in the same manner.
Task-number: QTBUG-95740
Change-Id: I24bc2a7dfe03b25145618d5314494a49cb59eba3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
This is a pre-requisite to being able to make
qt6_qml_type_registration() an internal rather than public command.
Not all examples have been updated, only those that were using the
qt6_qml_type_registration() command.
Task-number: QTBUG-95093
Pick-to: 6.2
Change-Id: I3f1814a29af608461daa90477eca0aa2304eb9d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some examples were still using the old "add as ordinary resources"
approach for QML modules, others needed adjustment to the subdirectory
structure to better reflect the URI structure of the QML modules
involved.
Task-number: QTBUG-95144
Pick-to: 6.2
Change-Id: Ie3399410cf6df491eb1e7b4a589ca26c577d82a0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QPlatformInputContext::reset() function does not allow any further
input method events to be called. Therefore, clearing the pre-edit text
is the sole responsibility of the text input control.
This change modifies the QQuickTextInputPrivate::resetInputMethod()
function and calls QQuickTextInputPrivate::cancelPreedit() instead of
QInputMethod::reset() directly. The cancelPreedit() function will send
a QInputMethodEvent which clears the IM state (in addition of calling
QInputMethod::reset() function).
Also, rename the QQuickTextInputPrivate::resetInputMethod() function to
cancelInput, since it does not call inputMethod()->reset() directly.
Fixes: QTBUG-95461
Pick-to: 5.15 6.1 6.2
Change-Id: I6ab3b9dbe71956af72656e2a25a05d79603b34ea
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Inho Lee <inho.lee@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi>
This is how you retrieve the singleton at runtime.
Change-Id: I3b4d98d3242448e34fc984b85146f0c0bb37785e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@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>
On neither macOS nor windows will the color of the text on a
button change if it's checked or highlighted. We should always
use just palette.buttonText.
Pick-to: 6.2
Task-number: QTBUG-95593
Change-Id: Ifdedae5b775c6e65371340bc4f3a573c7a89376e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
This is handy for cases where you want to clearComponentCache().
Singletons may hold on to old types, and using them after
clearComponentCache() can produce surprising results.
Task-number: QTBUG-95788
Change-Id: I390ff78cf9be9c034573ae848c8ccefa6d6a8817
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
The regression was introduced with 2acb31641f
The problem was that when we entered
QQuickListViewPrivate::wantsPointerEvent(), the event was not localized
to the QQuickFlickable when mouse filtering was done.
Therefore, since the code assumed that the localPos was local to the
Flickable, it always ended up assuming that the point was within the
bounds of the header/footer.
Fixes: QTBUG-89409
Pick-to: 5.15 6.1 6.2
Change-Id: Ib595e61b7995241b58e3051da09139e1e1f13cba
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We also need to present alternatives that show how to do these interactions in a well-defined, tooling friendly way.
Introduces the concept of doing QML and C++ interactions via singleton or an initial property.
Pick-to: 6.2
Task-number: QTBUG-92970
Change-Id: Ibbb0224194c5406c17eb08538f320c2b2576b733
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The native styles are not suitable for customization. Add a few
lines to the documentation that explains why.
Pick-to: 6.2
Fixes: QTBUG-95593
Change-Id: I50418bee28986fdeeb0c309fa674b1e1f9a8ae52
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The current code assumes that the basename of the QML plugin is the
same as the CMake target it corresponds to. This won't be the case for
installed Qt packages due to the installed name including a namespace.
It also won't match when a Qt library infix is used. The current code
works around the former by trying to heuristically work out whether
a namespaced Qt target exists for the plugin. The Qt library infix is
more problematic because the plugin target name won't include the
infix whereas the plugin library basename will.
Address both of those issues by adding an internal option
INSTALLED_PLUGIN_TARGET to qt6_add_qml_module() which allows the
installed target name to be provided. When included in a qmldir file,
qt6_import_qml_plugin() will use that name, otherwise it will fall
back to using the plugin library's basename, as per the current
behavior. The option may become public in the future, but for now it
is only for Qt's internal use for the 6.2 release.
Fixes: QTBUG-95140
Pick-to: 6.2
Change-Id: I5a057c80b70ee802c0f0840e9eea2e579193d126
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The code generator needs to see the modulePrefix as a separate step in
order to generate sensible code. The savedPrefix we had before was not
exposed to the code generator. As an added benefit we can also check
that we don't refer to singletons as properties of objects this way.
Task-number: QTBUG-95822
Change-Id: Ia8992dba340bf0552e7647f0d66b441f1ac1b8c8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
- <limits.h> (aka <climits>) is needed for UINT_MAX macro constant.
- <limits> is needed for std::numeric_limits.
Without this fix, qtdeclarative failed to build on some platforms:
In file included from jsruntime/qv4regexp_p.h:62,
from jsruntime/qv4regexp.cpp:40:
../3rdparty/masm/yarr/Yarr.h:46:44: error: ‘numeric_limits’ is not a member of ‘std’
46 | static const unsigned offsetNoMatch = std::numeric_limits<unsigned>::max();
| ^~~~~~~~~~~~~~
Pick-to: 5.15 6.2
Change-Id: I7cc9f7bc6624a52c8659f09034ab16064da5fd2f
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Also check bindings that do not have any script expressions but only contain literal bindings for type mismatches.
Task-number: QTBUG-91633
Change-Id: I2ba477fbf34df4c7e6d0db88601617c7157c87b7
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This type is used by in various modules yet we don't define it anywhere. Thus this patch adds it to builtins.
Pick-to: 6.2
Change-Id: I7e4c678d6f71e852d43192d2b4b13776634aea3e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QQmlImportVisitor was accepting ctor paratemeters for the QQmlJSLogger,
creating own logger internally. This seems wrong since in that case we
kind of have separate logger for visitor and type resolver (among other
entities)
On top of this, the import visitor had a silent logging by default
(and the QQmlJSLogger is not silent on the contrary) which in fact hid
some issues that should've been reported by qmllint (but they weren't)
For consistency, the silent logger is still used. And the ultimate fix
would be to use FindWarningsVisitor instead of QQmlJSImportVisitor
as currently we do 2 AST traversals in qmllint
Change-Id: I4c54b76d130e7e8f31c90a148edc1c02f7e86ab8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Clazy gives a warning that it might detach. qAsConst makes it go away.
Pick-to: 6.2
Change-Id: I293fd5337bc02b3c492464400651358459cf4ab4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
A loop-local variable is often more efficient than a variable at
function scope; and avoiding it altogether is more compact.
Pick-to: 6.2
Change-Id: Iac88bc433ce640a52a6bd909c708711e294ecc59
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Check if the module provides a .qmltypes file. If so, we assume that
there are some C++ types to be imported.
Pick-to: 6.2
Change-Id: Iad15d9c834c9bcebd76a62926620902031493557
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Type resolution is a straightforward single pass procedure. In certain
corner cases it couldn't find/resolve a type if that wasn't already
resolved. This happens to be the case when importing and resolving QtQml
types (such as QQmlEasingEnums::Type)
As we assume that this only happens with enumerations, we can resolve
them first and only after perform full type resolution for imported
scopes. If in fact there are other affected members, then a proper
second type resolution pass would be required instead
Pick-to: 6.2
Change-Id: Ic9606ed8bd058a1ae981085ac3e47a6f6a95ed7f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The script bindings on grouped/attached properties were ignored before,
basically allowing bogus QML to pass qmllint
On top of fixing the property binding processing, better source
locations are also used instead of fairly random ones
Pick-to: 6.2
Change-Id: I1f34ce33c35e64e31879e872a8d87038f10ea897
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We shouldn't install metatypes json files for user created qml
modules without allowing the project to say where they should be
installed.
Instead we should introduce new API to allow extracting the created
json files so the user project decides where to install the files,
similar how we would do it for other artifacts like the qmldir file or
qmltypes file.
Because it's too late to introduce such API for 6.2, disable
installation of the files for user projects, but keep it for Qt
provided qml modules.
Once qt6_extract_metatypes in qtbase is fixed not to install the files
by default, we should remove the newly introduced internal options and
use a better mechanism for piping through when and where the files
should be installed.
Amends 1c4ba17015
Pick-to: 6.2
Task-number: QTBUG-95845
Change-Id: Id8f6cd6d06aa58d42c72f62ef7458cfaf244b2cd
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
All projects (including examples) have ported away from using
INSTALL_LOCATION and thus setting the QT_QML_MODULE_INSTALL_DIR
property as part of the work done in
1c4ba17015
Thus the work around to install the example metatypes files is not
needed anymore.
Furthermore qt6_extract_metatypes will be modified to not install
json files by default anymore because the public API should not be
handling that.
Remove the dead code.
Amends ee72ba1238
Pick-to: 6.2
Task-number: QTBUG-95845
Change-Id: I0cfb4424cb79a059a2ecc337c9e4603b09154c63
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
While migrating to QQmlJSTypeResolver in qmltc, some minor things didn't
match exactly with the currently used type resolver. I'm not planning to
submit those things just yet so it's easier to just make the class
subclassable by making its members protected
On top of this, decouple the QQmlJSImportVisitor from the type resolver
to allow arbitrary visitor to be used for document traversal. This would
anyway be needed for qmltc later on (it seems) as several qmltc-specific
visitor passes are needed, yet they aren't that useful for e.g. qmllint
Change-Id: I9fabcf6c0f2119b0d064bb27157b7085275e7665
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A project with an executable and a qml module attached to it fails to
configure when targeting iOS with CMake and Xcode with the error:
CMake Error in CMakeLists.txt:
The custom command generating
qmltestapp_cmake/qqc_test_qmltyperegistrations.cpp
is attached to multiple targets:
qqc_test
qqc_test_qmltyperegistration
but none of these is a common dependency of the other(s). This is not
allowed by the Xcode "new build system".
When generating Xcode build files, CMake wants the generation of files
to be driven by one common target rather than 2 separate targets.
We haven't found a nice fix for this yet, so to circumvent the error
we make the ${target}_qmltyperegistration custom target depend on the
main ${target} when using the Xcode generator.
A consequence of this is that _qmllint targets will now build
${target} when invoked.
Pick-to: 6.2
Task-number: QTBUG-95763
Change-Id: I79623423b3dc0727fe5fed3a871176b04a56a6d5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Make it potentially compile-able by adding required headers (though it's
not like it's really being compiled anyway), and add `override` keyword
for methods which are actually re-declared from pure virtual base.
Change-Id: I7b0c13de6a63aacdb082517ca586fb9db8c1087a
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The purpose of the added test is to verify the way CMake sets up things
like import paths for tooling, in particular qmllint and qmlcachegen.
The test also ensures the application can actually run, which confirms
it can also load the QML module associated with the executable as well
as separate QML modules that have dependencies between them.
Task-number: QTBUG-95144
Pick-to: 6.2
Change-Id: Ice22dc4c9336f0271829e3abc21913355dcbd811
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
For tooling to work when a QML module is associated with an
executable rather than a library, it still needs the standard QML
directory structure in the build directory. But the source tree
is often not structured that way for the .qml files that are part
of the executable's QML module. The NO_RESOURCE_TARGET_PATH option
allows the project to essentially keep the structure from the
source tree in the resources, but use the standard QML structure
in the build directory for tooling.
Task-number: QTBUG-95598
Pick-to: 6.2
Change-Id: I53145ced0e57d7ea4795bb5260dd464f6458f444
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When a QML module has a library as its backing target, try to walk back
up the directory tree in the build directory to find the base
directory. The QML module's target path needs to match the path to its
qmldir below that base directory. This will allow other QML modules
that use the same base directory to be found by tooling like qmllint.
We warn if the directory structure doesn't conform to this requirement.
Fixes: QTBUG-95144
Pick-to: 6.2
Change-Id: I1842ae35fc220847fb1cc36402b286e107969541
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It's still MIA. Material style has its own implementation but we
unfortunately aren't shipping any module with a reusable RectangularGlow.
Pick-to: 6.1 6.2
Change-Id: Ie14188c517ff31217e25dc428b400659e3d0613f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>