Re: [Interest] The willy-nilly deletion of convenience,, methods

[Ulf Hermann]

On 3/24/21 2:21 PM, Christian Gagneraud wrote:

On Thu, 25 Mar 2021 at 01:22, Roland Hughes  wrote:

You forgot customer abandonment

death of OpenSource LTS

Qt 6 being useless

QML needing to be ripped out.


Is there life on Mars?


I'm from Mars.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Extracting available imports from QML plugins for package dependencies

[Ulf Hermann]

Hi Fabian,

In general, you should bug your upstream to provide a qmltypes file for 
each module. They know best what types they want to expose in what 
version and under what URI. I do understand that upstream may be less 
than delighted, though ...


Modern QML applications generate their qmltypes files at build time via 
CONFIG += qmltypes. Those qmltypes files should be installed alongside 
the qmldir file. They contain information about URIs and versions. The 
qmldir file, in turn, should have a "typeinfo" entry that points to the 
qmltypes file.


If you have an old project that doesn't provide a qmltypes file, you can 
indeed run qmlplugindump to generate qmltypes from a given binary. 
Indeed you currently have to give it the latest version it's supposed to 
expose. It should also list any older versions in the "export" entries, 
though. However, qmlplugindump might have bugs. Technically, it's also 
deprecated. Yet, I would still accept the occasional bug fix, or a 
change that makes the version argument optional. This way it could list 
everything without requiring the maximum version to be known beforehand.


Finally, the lack of information about the maximum acceptable version is 
a deficiency of the qmltypes format. We should add an entry about it in 
the top level scope. It wouldn't be too hard to teach qmltyperegistrar 
or qmlplugindump how to generate that.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtQuickCompiler and QtQuickControls2

[Ulf Hermann]

Hi,

We've recently added the "prefer" directive to the qmldir format. With 
it you can specify a preferred location for QML files to be loaded from. 
Usually this will be in the resource file system. Files in the resource 
file system can be pre-compiled with qmlcachegen.


Therefore, during development provide the QML files both as files in the 
file system and as resources, so that tooling can find them. When 
deploying, you don't have to provide the files in the file system 
anymore. The QML engine won't load them anyway.


Our CMake build system automates this, but the relevant bits are not 
public, yet.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Ulf Hermann]

One thing I noticed contributing to this effect is that it is apparently
difficult to pass objects of "medium" complexity through the glue layer > 
Simple stuff like integers and strings are fine (enums already get
interesting...), really complex stuff like QAbstractItemModels can be fine,
but for "two strings, an enum and an optional QDir" you already have to make
up your mind whether this is more like "three strings and an int" or more
like "something that needs moc". This contributes to an effect that I
consider self-censorship when it comes to selecting appropriate data
structures for the backend: If I know I can only expose certain types to the
frontend, I am tempted to used these types in the backend, not necessarily
the ones best suited one for the task. If the only tool is a hammer, ...


There is a difference between value types and object types in QML and 
that difference is closely related to the difference between types you 
would pass as pointer vs types you would pass as value in C++. For all 
of this you do need moc. Basically, any QObject derived class is an 
object type, and any Q_GADGET is a value type. The choice between those 
is about as difficult as it is in C++.


You can use any Q_GADGET as value type in QML these days:

struct MyMediumSizeValueType
{
Q_GADGET
QML_ANONYMOUS

// I'm not sure whether plain MEMBER actually works.
// Maybe you need a WRITE (and that would be a bug in QML).
Q_PROPERTY(QString oneThing MEMBER oneThing)
Q_PROPERTY(QString secondThing MEMBER secondThing)
Q_PROPERTY(QDir thirdThing MEMBER thirdThing)

QString oneThing;
QString secondThing;
QDir thirdThing;
};

Enums in value types are not supported because of naming requirements. 
Enums need to be part of uppercase-named types, and only object types 
and namespaces are uppercase-named. However, you can either expose an 
existing Q_GADGET as namespace using QML_FOREIGN_NAMESPACE (potentially 
in addition to exposing the same struct as value type) or you can move 
the enum to a suitable place if you're designing the whole thing from 
scratch for QML.


Named value types are still somewhat black magic, but we'll get to that 
soon-ish. You can use QML_ANONYMOUS and the QML "var" type for now. You 
can also have a QML_ANONYMOUS type as Q_PROPERTY of a C++ class, under 
its C++ name.


QDir is problematic because it does not expose any of its members as 
Q_INVOKABLE or Q_PROPERTY, and it's not a Q_GADGET. Your best bet is 
creating a wrapper type that does all these things. In that wrapper type 
you can also encode the "optional" nature of it. A pre-defined value 
type for QDir would be a candidate for our new QtCore QML module.


So, yes, QML is designed to use the metatype system. If you want to pass 
data to QML, you have to declare the types. Once, you have done so, it 
can be very easy to pass data back and forth in a structured way. The 
type declarations can live in their own headers, and they can be purely 
declarative, such as the example given above. While such declarations 
add some lines of code, they do not add a lot of complexity.


Granted, we have promoted other, worse ways of connecting QML and C++ in 
the past. In particular context properties. And, despite my recent 
efforts to clean this up, there are still some holes in the type system. 
For example named value types or (civilized) construction of value types 
in QML. However, on the plus side, you do not need to call 
qmlRegisterFooBar and figure out all the parameters to that anymore.


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Ulf Hermann]

You know that I do appreciate your work to make QML easier to use. However,
I am still not convinced that a custom language (especially one that does
not fit _that_ seamlessly to C++) is needed at all.


Well, that's the main point then. Any language that does the object 
composition in a simpler way than connecting n+1 signals and slots is 
going to require some way of telling it what types are available. If 
you'd rather keep connecting signals and slots in C++, by all means do 
so. I'm all in favor of having a public C++ API for QtQuick.


However, please recognize that the classic way of setting up a widget 
hierarchy usually includes a lot of new and delete, as well as 
initialization of properties and connecting the same properties' change 
signals to the same setter functions you used for initialization. There 
are a lot of ways to mess this up that simply aren't possible in QML. 
Plus, the actual code that _does_ all this (in contrast to the code that 
just declares types) will be much simpler and easier to read in QML. 
That is the other side of this particular trade-off.


regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Porting custom QML plugin to the Qt6

[Ulf Hermann]

Hi Jakub,

nice to hear someone is trying the fancy new QML type registration!


[...]
I spotted, I believe, the most important changes. QQmlExtensionPlugin 
being changed to QmlEngineExtensionPlugin, QML_ELEMENT added in Qt 
5.15.X and removal of QQmlExtensionPlugin::registerTypes.


Technically, QQmlExtensionPlugin with its cruft is still there, but 
indeed you shouldn't use it. The new CMake API will default to 
auto-generating a minimal optional plugin. The actual meat of the QML 
types will then be in a backing library that you can directly link into 
your application. This way it won't have to load the plugin at all.


Then I noticed stuff about QML_IMPORT_NAME, QML_IMPORT_MAJOR_VERSION and 
'CONFIG += qmltypes' that are supposed to be added to the .pro project 
files. And, although, docs are silent about CMake, there is handy 
example located at:
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/qml/qmlextensionplugins/CMakeLists.txt?h=6.0 


Well, yes, the CMake API is in tech preview right now, and it will 
change quite a bit.



[...] > omitting, for the moment, the "QT_QMLTYPES_FILENAME
imports/TimeExample/plugins.qmltypes" as I was typically generating 
.qmltypes manually using the supplied qmlplugindump and some associated 
CMake hackery.


Don't do this. qmlplugindump is deprecated. qmltyperegistrar can 
generate better qmltypes files.



[...]

But! My includes are not available under  but 
rather under "IzLibrary/SomeBeautifulHeader.h" as denoted by my 
target_include_directories:


# include directories for target
target_include_directories(
     IzLibraryPlugin
PUBLIC
     $
     $
PRIVATE
     ${CMAKE_CURRENT_SOURCE_DIR}/private
)

So, my questions (for now :P) are:
Is this the intended behavior or have I fubared something and not added 
"something, somewhere" in my CMakeLists.txt?


This is expected. You need to make the headers for your QML-exposed 
types available in the include paths for the generated code to find it. 
An -IIzLibrary should fix this. Anything else would be a series of never 
ending headaches, considering the different paths of your sources and 
generated files in source, build, and install directories. Also, the 
metatype information is generated by moc and moc doesn't know where your 
"reference" path should be.



Is there a documentation for the qt6_* cmake functions?


Not yet. The CMake API is being redesigned right now. Don't expect 
anything to stay the same.



Is the stuff "qt6_add_qml_module" important or can I skip it?


That will indeed be the way to add QML modules. However, what you 
currently see there is not very useful.


cheers,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Ulf Hermann]

If I came from Mars that still wouldn't give me the right to abuse, 
insult or demean other people on this list.


You clearly did not read the secret Martian amendment to the code of 
conduct. Roland has. We're neighbors.


Anyway, the amount of popcorn I have ingested reading this list tells me 
that the time for a nice permanent ban and a fruit basket has come. And 
gone.


I would like a new mailing list that focuses on technical aspects, like 
"how do I use Qt in such and such way". Any question of licenses, 
general politics, the importance of functional safety, fruit baskets, 
etc can stay here on the old mailing list. I will even occasionally read 
it and enjoy my popcorn, but no one interested in more productive 
conversation should be forced to.


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML Singleton and QTimer?

[Ulf Hermann]

Hi,


GuiApplication::GuiApplication(int argc, char*argv[]):
QGuiApplication::QGuiApplication(argc, argv)
{
m_hardwareInterface = new HardwareInterface;
qmlRegisterSingletonInstance("com.company", 1, 0, "HardwareInterface", 
m_hardwareInterface);
}


qmlRegisterSingletonInstance() is dangerous if you create your singleton 
in a different thread than the one the QML engine runs on. The QML 
engine expects to be able fiddle with internals of those objects via the 
metaobject system.


It also does surprising things when you have multiple QML engines: The 
first one to access it grabs the objects and all others only see null.


It also does not play ball with qmlRegisterTypesAndRevisions() the way I 
had intended. You cannot register an instance before the type because 
the type will then get rejected. You also cannot register an instance 
after the type because there is no way to hook into the type 
registration procedure without providing some kind of callback. If you 
could provide a callback, then that would be pretty much the same as 
providing a factory function, though.


The whole qmlRegisterSingletonInstance() was a mistake, sorry about 
that. It's too easy to shoot yourself in the foot with it and there is 
no way to make its type visible at compile time. You should really use 
the QML_SINGLETON macro and let the QML engine handle the life cycle of 
the object. The QML engine will make sure to create and destroy it on 
the right thread. qmlRegisterSingletonInstance() will be deprecated 
before Qt 7.


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (Q)Plugins and QML/Quick

[Ulf Hermann]

Hi,


The problem to discuss:

  * An application that wants to be extendable via plugins.
  * These are found and loaded at runtime.
  * Not all of them are used at the time.
  * The plugins require non-trivial UI, that they ought to "bring
themselves".
  * During the runtime of the application one plugin can be disabled and
another one enabled, and their respective UI should be replaced in
the application window.
  o Ultimately, think that they can be chosen on a combo-box.


[...] 


Now, the question: How would you approach the same problem in QML? I've 
read around that creating objects for the Quick engine is an 
anti-pattern. So, do you have examples, or suggestions, how to achieve 
this kind of design?


You're talking about QML modules. There is a new blog post about those 
[1], and I'm just writing another, more in depth one, about the same topic.




[1] https://www.qt.io/blog/introduction-to-the-qml-cmake-api


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (Q)Plugins and QML/Quick

[Ulf Hermann]

Maybe I missed something, but this seems more like a solution to manage 
QML resources and modules that you know about at compile time.


The QML import path allows you to combine modules compiled separately in 
the context of different projects.


I'm talking about a runtime problem. Lemme try to explain with some 
simplified code. Allow me to leave a link to some markdown and syntax 
highlighted stuff:


https://gist.github.com/ruilvo/43365e67f6d3ea472531738fd5a52793


Do not start with something as low level as a plugin. Think of your code 
as logical units, defining different parts of your UI. Then create a QML 
module for each. The plugins are automatically generated. You don't have 
to care about them. Using "import Some.Module" in QML will load them as 
necessary.


You only need to make sure the QML engine knows about the relevant 
import paths. If you use the default directory layout as shown in the 
blog post, the default import path will be enough.


Otherwise you have to call QQmlEngine::addImportPath(). This is likely 
what you have to do if you want to combine modules from different projects.


You say that "import mytype" is not possible. However, there must be 
some starting point in your application. You need to have code that 
specifies a first plugin to load by file name. This can instead be 
phrased as a module URI. If you insist on not having an entry point 
main.qml, you can dynamically generate a two-line QML document and load 
it via QQmlComponent::setData():


// given moduleName and elementName:
QQmlEngine engine;
engine.addImportPath( ... );
QQmlComponent component(&engine);
const QString qml = QStringLiteral("import %1\n%2{}").arg(moduleName, 
elementName)

component.setData(qml.toUtf8(), QUrl());
QObject *myQmlObject = component.create();

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (Q)Plugins and QML/Quick

[Ulf Hermann]

But my goal is to not know about the types beforehand at all. It's 
basically the "copy the dll to the application folder and it'll 
magically show up as an option" pattern. The goal is to provide an 
extensibility framework, like eclipse, or web browser addons. Not just 
using a type defined elsewhere.


There is Loader [1]. You can define some convention on where the entry 
point to a module is to be found, and construct a URL for Loader out of 
that. Then you can scan the relevant QML import paths and record the 
available modules. The result can be presented as a menu.


Mind that loading a QML file directly from the host file system prevents 
you from using the pre-compiled byte code in the plugin. Therefore, the 
entry points should probably only do a named import of their module and 
instantiate some other type made available that way.


[1] https://doc.qt.io/qt-5/qml-qtquick-loader.html
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Ulf Hermann]

As of last month, 1.26% of all laptops and desktop computers
worldwide were still running on the 19-year-old OS. That’s a greater
proportion than much younger operating systems Windows 8 (0.57%),
ChromeOS (0.42%) and Windows Vista (0.12%).


The only thing one has to do to keep these systems "secure" is not 
connect them to the Internet.


In that case, using e.g. Qt 4.8.7 (slightly younger than Windows XP) for 
those systems should be fine, too. Why do they need the latest and 
greatest Qt for something that old?


Yes, Qt 4.8.7 is not supported anymore, but if you don't care about 
security, what do you need the support for? You're going to say 
"safety". Yet, let me remind you that MS are not fixing safety critical 
bugs in XP anymore, either. So that game is already lost anyway.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Ulf Hermann]

Long story short: You can have a Qt 5.15 LTS. You just have to pay for 
it. You can even have Qt supported on obscure outdated platforms, as 
Volker mentioned. It's just even more expensive. The price is high 
because there is a lot work involved in making this happen and the 
number of customers requesting it is small.


There are other toolkits for which the cost of such maintenance is 
lower, mainly because they didn't evolve so much since the days when XP 
was the latest and greatest. Some toolkits are even written from scratch 
with mainly backwards compatibility in mind. You will understand that 
there is a trade off involved here. If you want to be compatible with 
everything in the world, you can't add many new features.



1) On rare occasions patient killing bugs like this one get fixed.

https://bugreports.qt.io/browse/QTBUG-12055 



This has very little to do with "security" unless one puts application 
stability under the security heading.


That's exactly the safety (not security) argument I was expecting. The 
patient killing bugs in the underlying OS and drivers etc will not be 
fixed anymore, though. So even if we had decided to support XP with Qt6, 
you still wouldn't have gained much.



2) Updated hardware support.


I wouldn't trust a hacked together system with 3rdparty drivers and 
outdated software monkey-patched to work with my shiny 4k monitor to be 
free of patient killing bugs. Or, I would only trust it if all that 
stuff is carefully tested to be compatible with each other. Such testing 
and bug fixing is expensive. Here we're back at square 1.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Ulf Hermann]

I doubt you get a paid-for 5.15 LTS under an Open Source licence,
so no, this is not comparable a̲t̲ ̲a̲l̲l̲.


I did not compare to anything. Roland listed a number of open source 
projects with LTS versions _after_ I wrote this.


If you want to discuss the issue of "I want a supported open source LTS 
of Qt for recent systems", then I suggest you continue one of the 
existing threads on this topic. This one here is about outdated systems.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Ulf Hermann]

There are no patient killing bugs in the underlying OS or the previously 
used drivers. Those only exist in the new drivers, new OS patches and 
new Qt code. All of the new code has to be written following 62304 SDLC


Although I doubt that Windows XP or the new graphics drivers are free of 
patient killing bugs, I have to admit that you have a point here: If MS, 
AMD, NVidia etc. went through the certification process with their 
software, we can trust their software as much as we can trust anything 
in such a system.


Now, what you probably want from Qt is a package that eliminates most of 
those 5000+ bugs and that can itself be certified or at least accepted 
in the approval process. The way to get there might be as follows:


1. Define a the feature set you need from Qt.
2. Turn off all unnecessary features using -no-feature-xyz on the 
configure script (possibly defining more features in order to be able to 
turn them off).
3. Wade through the bug database and sort out the bugs that remain valid 
for such a stripped down Qt.

4. Deal with those bugs in whatever way the approval process mandates.
5. Port the resulting Qt to your target platform.

I might be wrong with those steps because I don't know the approval 
process. Yet, I'm sure there is some pragmatic way to produce what you 
want. You may want to share your ideas on what it actually takes.


While all of this is possible, it obviously is a lot of work. If you 
want to do the work yourself, let's discuss the details here. If you 
want to pay for such work to be done, you may want to get in contact 
with the Qt Company. If you want to lament about such a specialized Qt 
not materializing out of thin air, you got my sympathies, but you may 
not get everybody's sympathies here. If you want to repeat that no one 
you know is using Qt anymore, that won't be necessary. We've read it 
often enough.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Can QML compiler optimize switch into array indexing?

[Ulf Hermann]

Hi,

Let's look at the QML snippet again:


enabledBorders: {



switch (control.edge) {



case Qt.BottomEdge:



return PlasmaCore.FrameSvgItem.TopBorder;



case Qt.RightEdge:



return PlasmaCore.FrameSvgItem.LeftBorder;



case Qt.TopEdge:



return PlasmaCore.FrameSvgItem.BottomBorder;



case Qt.LeftEdge:



default:



return PlasmaCore.FrameSvgItem.RightBorder;



}



}


What the QML interpreter and JIT do on such a thing is quite sad:

1. Lookup "Qt" and figure out it's a singleton.
2. Lookup "BottomEdge" on "Qt" and figure out it's an enum
3. Resolve enum to number
4. Compare

... and so on for all the cases. Once the right case is found, it does:

1. Lookup "PlasmaCore" and figure out it's a type namespace (probably?)
2. Lookup "FrameSvgItem" on "PlasmaCore" and figure out it's a type
3. Lookup "TopBorder" on "FrameSvgItem" and figure out it's an enum
4. Resolve enum to number

The lookups are cached, so the second and any following executions of 
the same piece of code are faster. Yet, it's still quite far from what 
it could be. The problem here is that the QML engine initially doesn't 
know what all the names mean and has to figure it out at run time.


This is a case where the QML-to-C++ compilation will truly shine because 
we can do all of the lookup at compile time if we know all your types. 
Then the generated code collapses into a few comparisons on plain integers.


This is why you have to declare your types in your header files using 
QML_ELEMENT and friends, and use qt_add_qml_module to declare QML 
modules in CMake.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Can QML compiler optimize switch into array indexing?

[Ulf Hermann]

I now saw your nice blog post about this at [1], saying "You should
not call qmlRegisterType() and friends procedurally anymore.".

I then saw that there's no pointer in the docs for qmlRegisterType and
friends [2] to QML_ELEMENT.


There are quite a few links from the qmlRegisterType() family of 
functions to their macro counter parts. For each one there is a "See 
also" below it and the macros are documented on the same page.


The general documentation on how to define QML types from C++ can be 
found at [1]. It only mentions the macros.


[1] https://doc.qt.io/qt-6/qtqml-cppintegration-definetypes.html

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Binding::restoreMode buyers guide

[Ulf Hermann]

The question is all about QtQml 2.15 Binding type. The infamous missing
unexported `restoreMode` property sure makes our lifes slightly harder
than it should be (by generating warnings if left out); but when it
comes to choosing an appropriate value for it -- I am totally lost.


The short story is: Always set it to RestoreBindingOrValue and adapt 
your code as appropriate. All the other options are hacks introduced for 
backwards compatibility.


In previous versions of Qt, there was no restoreMode and the behavior 
was broken. Therefore we first introduced a switch you can use to opt 
into the sane behavior and then made the sane behavior the default. You 
can still explicitly select the insane behavior, but don't.



Note that documentation doesn't come with any examples for restoreMode.


Because you shouldn't use it anymore.


Also, any reason as to why Binding is `setValue(const QJSValue &)`, but
QQuickPropertyAction is `setValue(const QVariant &v)`? I mean, QJSValue vs
QVariant differences.


This is also a historical artifact. We've changed the type as a fix for 
QTBUG-78943 . Since 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/305210 that "fix" 
may be obsolete as we don't magically convert strings to colors anymore.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML type hints and their problems

[Ulf Hermann]

a, Use type annotations on all JavaScript functions in QML files. 
Period. It helps tooling, gives you better diagnostics from qmllint and 
qmlsc, helps you understand your code better. There are no downsides.


b, In this particular case we could be more lenient, but what if that 
was actually an unrelated "contains" method? Mind that you can shadow 
those methods by inheriting or by mixing C++ and QML. If we get the 
wrong one, we can probably still JavaScript-coerce the argument to point 
and the return value to bool, but the result will be a mess and rather 
hard to debug.


c, The change that introduced the containment masks, 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/211550 , only 
intended the contains() functions to be defined in C++. Later, starting 
with https://codereview.qt-project.org/c/qt/qtdeclarative/+/249400 , 
we've added type annotations for JavaScript functions. Using those you 
can now define typed functions in JavaScript and they are treated the 
same way as C++ functions. So, be happy that this works at all ;)

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Javascript: regex: no /s flag support?

[Ulf Hermann]

On Thursday, November 25, 2021 11:47:19 PM MSK Alexander Dyagilev wrote:

I'm trying to:

var re = new RegExp('someregex', 's');


This does not produce a QRegularExpression but rather a JavaScript 
regular expression. Unfortunately those are slightly different. See 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Javascript: regex: no /s flag support?

[Ulf Hermann]

And the 's' flag was apparently added in ES2018, which QML does not 
support, yet.


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Ulf Hermann]

So, did I stumble on a bug?


Indeed that sounds wrong. You should not need to include qqmlprivate.h 
manually. We've moved the registration macros from qqml.h to 
qqmlregistration.h, but apparently not all their dependencies. Including 
qqml.h instead of qqmlregistration.h should work.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Ulf Hermann]

https://codereview.qt-project.org/c/qt/qtdeclarative/+/383175 may have 
fixed this. It forward declares some of the types.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Ulf Hermann]

On a side note, I was wondering, why these, contrary to other Qt 
headers, don't provide cpp style naming?


Where do you see the lack in cpp style naming? What name is wrong?

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Ulf Hermann]

I didn't mean the name's wrong, simply that I read 
 in the docs instead of  or 
something akin.


 would import a class called "QQmlRegistration". There 
is no such class in that header. It's a collection of macros. The 
correct form is .


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Ulf Hermann]

To be frank it's been an annoyance for me that gadgets can't be 
instantiated the same way the QObject can within the QML document/tree. 
Is there a good reason to disallow this or is it simply not implemented? 
Am I missing some odd use/corner case why it's not a good idea?


It's not implemented yet, and there are some questions surrounding the 
desired syntax.


We already have group properties. So, if you have a property font of 
some value type, you can already do this:




MyObject {

font {

pointSize: 14

bold: true

}

}



That is very similar in syntax to what you would do with a full value 
type construction. Therefore, the extra syntax required for full value 
type construction seems some
what redundant. I've chosen the familiar "font" value type as example 
but you can do the same with custom value types.


What is missing is value types as default properties and value types in 
lists and JavaScript objects. Yet, declaratively putting QML types in 
lists and objects is already a rather buggy affair with object types. 
This needs to be fixed first.


Then there is the issue that you cannot have named custom value types at 
all so far (you can have anonymous custom value types, though). All of 
the currently available named value types are hardcoded. That has to be 
fixed eventually.


Finally, we will probably run into some grammatical ambiguities when we 
allow lower-case names on the left side of "object" intializers.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Ulf Hermann]

Yeah, but my beef with it is that I must derive from QObject for that, 
don't I? I can live with not having notifications for the fields, is 
what I mean.


font is explicitly _not_ derived from QObject. That's the whole point of 
value types. Value types, however, cannot exist as root objects. They 
need to be a property of something.


I just have a stupid struct with 2-3 fields, that I'd love to initialize 
within the document tree. I did some hacking around and did provide this 
out of the parser (just ignoring the warning about registering value 
types with capital letter), but I was wondering if I missed some subtle 
problem. The whole idea of just having the god factory I find 
distastefulness and somewhat harder to read/reason about. Currently this 
is what it looks like for me:


property var person: Character {
name: qsTr("Personname")
age: Age {
years: 1
months: 0
}

Simulation.onAdvanced:{
age.months++
}
}


Well, yes, you need to declare the "person" property in C++ for now 
because you cannot have named value types. Once we get named value types 
(and some grammar fixes) you can do the following:


property person person {
age {
years: 1
months: 0
}
}

Simulation.onAdvanced: person.age.months++.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Ulf Hermann]

Person is a `QObject`, the `Age` is a gadget I've exposed from C++.


Then it's easy. If the "age" property is declared in C++, already today 
you can do the following (just like with font):


property var person: Person {
age {
years: 12
months: 4
}

Simulation.onAdvanced: age.months++
}
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Ulf Hermann]

Well, it does work, albeit I'm not convinced if it's better/efficient 
enough.

In any case, if you're interested we can pick up on gerrit, just say so.


Sure, if you have something on gerrit let me see!

However, value types with upper case names is something I probably won't 
allow. All our existing value types are lower case, and as they're so 
different from object types, this is a _really_ handy way to discern 
them already on a syntactical level.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Ulf Hermann]

Is the place where the module's qmldir ends up reachable via the QML 
import path? If you're linking the library into the application, you may 
just add :/ to your import path so that it's loaded from the qrc file 
system right away. Be aware that some linkers just drop the linkage if 
they perceive it to be "unused", though. Otherwise, if the module ends 
up in C:/foo/bar/Tsc/Ui/, then you need to add C:/foo/bar/ to the import 
path.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Ulf Hermann]

Otherwise, if the module ends 
up in C:/foo/bar/Tsc/Ui/, then you need to add C:/foo/bar/ to the import 
path.


Well, unless your executable is in C:/boo/bar. Then you don't need to do 
anything. But apparently that's not the case.


The executable would be at the root of the application-specific import 
path if you were following the recommended directory layout.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Ulf Hermann]

I don't know. I have the generated qmldir in 
the C:\Programming\tsc\build\debug\TscUi directory, which I think should 
be correct. I haven't messed with the output paths at all.
The application goes to a neighboring directory 
in C:\Programming\tsc\build\debug\TscApp


Well, no, that doesn't work. If your module is called Tsc.Ui, then it 
needs to live in a directory called Tsc/Ui/, not TscUi/. That's the 
reason why the explicit file system import path doesn't work either.


I can see that the .rcc contains a couple of cpp files corresponding to 


There may be multiple generated .rcc files.


QDirdir(":/Tsc");

constautolist=dir.entryInfoList();

for(constauto&entry:list)

qDebug()<

I guess your linker ignored the linkage because you don't "use" any 
symbols from the linked library. You need to do the plugin linking trick 
with Q_IMPORT_QML_PLUGIN.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Ulf Hermann]

Perhaps that's how it's supposed to work, but I'm not intending to mess 
around with the target output paths in cmake. It simply makes no sense 
to me.


If you want the QML engine to find your module, you need to follow 
certain conventions around the paths.


You can create a separate CMake target just for your QML module if you 
like that better. Then you don't have to mess with the existing target's 
output path.


By far the easiest way to deal with all this is keeping the QML modules 
in directories named by their URIs already in the source tree. Then it 
will just work automatically.



extern void Q_DECL_IMPORT qml_register_types_Tsc_Ui();
qml_register_types_Tsc_Ui();


You should _not_ manually call the type registration. This is private 
API and it _will_ break.


So is this the "correct" way to do it with my setup with NO_PLUGIN, 
then? I can live with the manual call, I'm just wondering if that's the way.


No. You can store a pointer to the type registration function somewhere 
in order to prevent the linker from dropping the dependency.


I recommend the "custom directory layouts" section of 
https://www.qt.io/blog/qml-modules-in-qt-6.2


best regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Ulf Hermann]

In my case to make 
extra sure I exported a dummy global symbol from the dll. If I don't do 
anything with it - nothing works. If I print it with qDebug() in the 
application code, the library is loaded and registration code and all 
works just as expected.


Indeed. And instead of the dummy symbol you can just use the existing 
type registration function for that. As you've found out, "just store 
it" is not enough. You have to "do" something with it. Sorry for being 
inaccurate there.


The way we work around the issue in the generated plugin code is storing 
it in a volatile pointer. That's terrible and also not guaranteed to 
work, but it works in practice on all compilers we support. If you 
figure out a better way, please let me know.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Inject a QML enum from C++ at runtime

[Ulf Hermann]

I imagine I'm not supposed to do such stuff, but is it at all possible 
to provide a QML enumerator at runtime from C++?


Why does it have to be an enumerator? To me it sounds like the values 
should be properties of a singleton. The code accessing them needs to 
know a fixed set of names after all.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Inject a QML enum from C++ at runtime

[Ulf Hermann]

Well, the number of names isn't fixed is the point - they're loaded at 
runtime and will change (increase) from time to time.


Then an enumerator won't really help you. The point of an enumerator is 
that each entry is a constant.


If the names and values can change at runtime, you should use a 
QVariantMap or a JavaScript object.


If for each version of the program the set of names is fixed, and only 
the values change, then properties on a singleton are the better choice.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML notify dynamic property changes from C++

[Ulf Hermann]

Hi Konstantin,

I have exposed some dynamic properties through QQmlPropertyMap to the 
QML engine and that works well. However I need to change the values from 
C++ and want to notify the bindings about the property change from 
there. Is there a way to do it?


QQmlPropertyMap::setValue(key, value) should trigger the change signal 
of the property. That, in turn, should update any QML bindings that 
depend on the value. If it doesn't work, please post a bug report with a 
minimal example project.


Mind that "QVariant &operator[](const QString &key)" is broken in that 
way. It cannot possibly notify if you change the value through the 
reference it returns.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML notify dynamic property changes from C++

[Ulf Hermann]

Hi,

Do you possibly mean QQmlPropertyMap::updateValue, because I don't see a 
setValue method in the documentation. Either way it doesn't appear to 


Sorry, it's called:

void insert(const QString &key, const QVariant &value);

Gadgets cannot send signals or notify about property changes in any way. 
But QQmlPropertyMap is not a gadget. In order to further examine this we 
would need a minimal example to reproduce the problem.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML notify dynamic property changes from C++

[Ulf Hermann]

On a related note, I'd suggest including an iterator/const_iterator for 
the QQmlPropertyMap for convenience, and also it could possibly handle 
this sort of value change in a more streamlined manner.


QQmlPropertyMap is not our focus for new features. It's most important 
downside is that we cannot see the properties at compile time. 
Therefore, any QML code that uses it cannot be compiled to C++. However, 
feel free to post changes to https://codereview.qt-project.org and I 
will happily review them.


best regards,
ULf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML issues after deployment

[Ulf Hermann]

Hi,


just lately I started integrating QML features into my Qt6 app
(related to web browsing). This works fine so far, however, after
deployment via macdeployqt I receive this error upon bootup:

module "QtQml.WorkerScript" is not installed


There can be many reasons for this. The most likely one is that the
macOS deployment tooling doesn't see the dependency between QtQml and
QtQml.WorkerScript. You may be able to work around it by explicitly
importing QtQml.WorkerScript somewhere. Can you please create a minimal
example project and post a bug report at https://bugreports.qt.io ?

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Support for Qt 5 & Qt 6 in QML app

[Ulf Hermann]

Hi,


I need to migrate a Qt 5 application with QML ui to Qt 6 without
losing Qt 5 support. What is the best approach here? Version-specific
resources? File selectors (by the way is it even possible to select
QML files based on the Qt version?) I mean it is clear that
platform-specific code/imports needs to be wrapped into
platform-specific components, but what is the best way to select the
right component?


File selectors are generally not a great idea as we cannot know ahead of 
time what they will evaluate to at run time. What concrete problems are 
you facing? Most QML code written for Qt 5 should still work with Qt 6.


You can use qmldir imports to select between different modules based on 
Qt version. By constructing your qmldir files from the build system you 
can change what your module imports at compile time. Unfortunately we 
don't have a good API for defining QML modules in Qt5. The only thing we 
have there is CONFIG+=qmltypes in qmake. You need to write build system 
code that generates or copies the qmldir file into place.


qmldir imports have a number of quirks in Qt5. They pretty much only 
work when the import statement is in a qmldir file of a QML module that 
also defines some other types. The other types have to be implemented in 
C++ and there must not be any *.qml files in the same module. In Qt6, 
qmldir imports are less of a pain.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML required property in view delegate - bug?

[Ulf Hermann]

Which raises the error "ReferenceError: model is not defined", as 
documented. Is there a way around this?


Just add the the "noise" property as another required one and don't 
access "model" in the delegate. You can do that where you assign to the 
"text" property. This way it doesn't require you to change SomeDelegate 
itself. Required properties in delegates are all-or-nothing. You cannot 
mix them with the traditional way of injecting model data into the context.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML required property in view delegate - bug?

[Ulf Hermann]

I agree with the doc for the "first level" of properties, but is it also 
by design even if the required properties are in a sub item, as in my 
2nd example (where the delegate itself doesn't have any required 
properties)? It is this case that seems a bug to me.


Indeed that is a bug. Thanks for reminding me. I've created 
https://bugreports.qt.io/browse/QTBUG-103479

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5 -> 6: In QQmlEngine, Qt.Checked, etc. are no longer available

[Ulf Hermann]

Thanks for pointing this out!


 .import QtQml 2.15 as CoreQML
 console.log(CoreQML.Qt.Checked)

yields:

  At line 2: ReferenceError: CoreQML is not defined

Is that something I should report as a bug? I'd appreciate any other potential 
workarounds.


The .import dance as shown above only works if the JS file is itself 
imported from a QML file. Otherwise any .import statement simply does 
nothing. If that's a bug then it has been a bug for a long time. It 
should probably just be documented to work that way. If you're importing 
the JS file from a QML file, then most likely QtQml is already in scope, 
which makes the whole thing pointless.


There are some interesting aspects to the availability and members of 
the Qt object in Qt5 and Qt6:


With QJSEngine, you generally don't get a Qt object at all. You can 
trigger the creation of the Qt object by installing 
QJSEngine::TranslationExtension, though. In Qt5 that gives you an object 
with pretty much only the "uiLanguage" property. In Qt6 you get a Qt 
object with all properties and methods, but without the Qt namespace enums.


With QQmlEngine, in Qt5 you always get the complete Qt object, while in 
Qt6 at first you get the same thing as with QJSEngine and the 
translation extension. Once the QtQml module is imported, you get the 
namespace enums, too.


Now, how did this happen?

In Qt5 if we have a QQmlEngine, each and every Qt namespace enum value 
is added as a property to the Qt object, keyed by a newly created 
QString, wrapped into a JS string, and the whole thing every time you 
query one of those enums (until you query something that doesn't exist). 
You may guess why I've removed this particular piece of code.


In Qt6 once the QtQml module is in scope, the "Qt" name refers to 
something else: The QtQml module exposes the same Qt object as a 
singleton also named "Qt", with an extension that is the Qt namespace. 
Singletons rank above the global object in precedence. That's the secret 
sauce on how the enums are added.


If you want to work around the problem, there are a number of ways to 
extend the JavaScript environment. For example:


QJSEngine engine;
engine.installExtensions(QJSEngine::AllExtensions);
engine.globalObject().setProperty(
QStringLiteral("QtNamespace"),
engine.newQMetaObject(&Qt::staticMetaObject));
engine.evaluate(QStringLiteral("console.log(QtNamespace.Checked)"));

You may also want to use QJSEngine::registerModule() if you're working 
with ECMAScript modules.


Finally, I just came up with this neat trick:

QJSEngine engine;
engine.installExtensions(QJSEngine::AllExtensions);
QJSValue qtObject = engine.globalObject().property("Qt");
QJSValue qtNamespace = engine.newQMetaObject(&Qt::staticMetaObject);
qtNamespace.setPrototype(qtObject);
engine.globalObject().setProperty("Qt", qtNamespace);
engine.evaluate(QStringLiteral("console.log(Qt.Checked)"));

This pretty much gives you the Qt5 Qt object, probably at a lower cost.

I haven't checked how fast the above is, but it probably doesn't 
repeatedly create strings for all enum values in the Qt namespace.


Now, it wouldn't be all that hard to do the above prototype trick 
already when adding the Qt object to the JS global object. I need to 
check if it opens new compatibility pitfalls, though.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5 -> 6: In QQmlEngine, Qt.Checked, etc. are no longer available

[Ulf Hermann]

This is very promising, but unfortunately I could only get it to work
with QJSEngine and not with QQmlEngine. With the latter, the Qt
object stubbornly still only provides various functions.


Indeed, in QQmlEngine the global object is frozen. You cannot replace
its properties. Apparently you can still add to it, though. But see
https://codereview.qt-project.org/c/qt/qtdeclarative/+/418536/1 for a
possible solution.

I would also like to know how you trigger the QQmlEngine warning signals
and methods from pure JavaScript. Those methods could just as well be
moved to QJSEngine if they make sense there. However, so far they're
actually meant for QML warnings.

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5 -> 6: In QQmlEngine, Qt.Checked, etc. are no longer available

[Ulf Hermann]

Right, normally when evaluating a script, any error can be caught and reported however 
you wish, but this does not work when the script execution is trigger through a signal 
connection. In this case, when using QJSEngine, errors are always printed to the standard 
out, whereas the QQmlEngine allows reporting these through its "warnings" 
signal.


Well, I would like to see a bug report with a minimal reproducer for 
this. How do you produce a signal connection in pure JS?


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Small survey on necessary Qt Container size

[Ulf Hermann]

I think Andre's point is that you should not use Qt containers for such 
large amounts of data, but rather some other data structure better 
suited for your case (most trivially, std::vector instead of QList).


The implicit sharing of Qt containers is a nice trait that enables you 
to write more concise code as long as it's feasible to copy the data 
when needed. If that is not feasible (i.e. billions of elements), the 
equally implicit detach on write will come back to bite you.


However, I guess there are a lot of people who consciously or 
unconsciously ignore this particular bit of advice and "just" never copy 
a large container unless all of its copies remain const forever. Is that so?


Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] "Proper" Date Locale support?

[Ulf Hermann]

I'm working with localization of dates. There is a standard JS API:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString#Using_options

But QML defines it's own Date:
http://doc.qt.io/qt-5/qml-qtqml-date.html

The difference being the MDN refers to an "options" object, and Qt uses a 
format string. With the update to a newer V8 engine, will we get the options behavior?


The QML Date type extends the JavaScript Date object. So, the locales/options variant of 
toLocaleString() would have to be implemented in the JavaScript engine, which is not V8 
but our own "V4". Be aware that the QML Date's toLocaleString() method hides 
the JavaScript method of the same name in QML Date objects. So, in addition we'd have to 
somehow autodetect the arguments format when the QML method is called.

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QJSEngine vs. (deprecated) QScriptEngine performance - old thing winning!

[Ulf Hermann]

QJSValue result = qmlEngine.evaluate(item.m_expression.sourceCode());


I guess you are mostly profiling the JIT compiling, not the actual evaluation. 
In order to get realistic results you should keep the compiled representation 
of the expression around, e.g. as a JS function. From the docs:


QJSValue fun = myEngine.evaluate("(function(a, b) { return a + b;})");

> QJSValueList args; args << 1 << 2;
>QJSValue threeAgain = fun.call(QJSValue(), args); regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QJSEngine vs. (deprecated) QScriptEngine performance - old thing winning!

[Ulf Hermann]

The usage scenario fits my needs, that is the reason to evaluate exactly this 
way.

I mean - should the QScriptEngine be deprecated, the QQmlEngine/QJSEngine 
should also have ways to utilize some form of JIT/preparse. Even in the first 
pass where JIT cannot be effective (or when I parse just the text expression) 
QScriptEngine beats newer and more shiny QJSEngine a lot. That is confusing to 
me and my point - why is QJSEngine offered as replacement of QScriptEngine when 
it is so much slower?


QJSEngine does not cache the compilation results if you just pass in plain 
strings. I also don't think QScriptEngine can do this here (but I haven't 
checked). QScriptEngine might be clever enough to automatically use the 
interpreter rather than JIT-compiling such small expressions. You can set the 
QV4_FORCE_INTERPRETER environment variable to force QJSEngine to use the 
interpreter rather than the JIT.

In any case it's a waste to parse the expressions from strings over and over 
and to not use the JIT. If you care about performance, you should try to parse 
the expressions only once.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QJSEngine vs. (deprecated) QScriptEngine performance - old thing winning!

[Ulf Hermann]

QJSEngine does not cache the compilation results if you just pass in plain 
strings. I also don't think QScriptEngine can do this here (but I haven't 
checked). QScriptEngine might be clever enough to automatically use the 
interpreter rather than JIT-compiling such small expressions. You can set the 
QV4_FORCE_INTERPRETER environment variable to force QJSEngine to use the 
interpreter rather than the JIT.

In any case it's a waste to parse the expressions from strings over and over 
and to not use the JIT. If you care about performance, you should try to parse 
the expressions only once.


Uhm ... the secret here is that you keep a QScriptProgram as the m_expression 
of your label item, which is basically a JS function compiled for QScript. So, 
of course, if you take the source code from that and then recompile it for 
QJSEngine on every iteration it will be slower than if you evaluate it straight 
away in QScriptEngine. If you instead kept a QJSValue with the same expression 
written as a JS function, QJSEngine would probably be much faster as 
QScriptEngine would have to recompile on each iteration.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QT plugins memory footprint and the debugger

[Ulf Hermann]

Looking at the source of qt, the problem is identical(though it is protected 
against runaway exceptions). The MinGw debug plugins of qtquick are quite large 
and use the same mechanism to load plugins. If, as in my case, the 
initialization of the program allocates considerable memory ( but tbh, not 
excesively so, there is plenty left) QT (and by extension QT quick) can run 
into problems; in debug mode, using MinGw. This wasnt the case in 5.2 so I must 
assume that code of loading plugins was changed in between.


MinGW maps the debug symbols into memory when loading libraries, which on 32bit systems 
quickly eats up your address range. One trick that worked for me is compiling everything 
(including Qt) with "-separate-debug-info". This will put the debug symbols 
into separate files that aren't mapped at run time. The debugger will still read them.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] SCXML Statemachine donedata event

[Ulf Hermann]

Connections|{|
||target|: stateMachine|
|onEventOccurred: {|
|console.|log|(event.name)|
|}|
|}|


From QML you should use the EventConnection QML type. About like this:

EventConnection {
stateMachine: stateMachine
events: ["done.state.*"] // or ["done.state.somespecificstate", 
"done.state.someotherstate", ...]
onOccurred: console.log(event.name)
}

From C++ you can do the following:

statemachine.connectToEvent("done.state", [](const QScxmlEvent &event) {
// do something
});

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] SCXML editor in QtCreator

[Ulf Hermann]

Hello Wolf,

Thanks for trying the SCXML editor. Your feedback is appreciated.


I have tried out the SCXML editor plugin for the QtCreator. My first
impression is very positive. The editor creates nicely looking state
chart diagrams. There are only two downsides I have found so far:

1. Events are currently not visible in the diagram.


The event names are shown as labels for the transitions they trigger. Can you 
elaborate a bit on what you expect?


2. As far as I see it there is currently no possibility to add UML-like 
comments.


You can add meta data to states. Right click on some state and select 
"Metadata". That allows you to add arbitrary text attributes. They don't 
interfere with the functionality of the state machine.

regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML Debug API

[Ulf Hermann]

Hi Nils,

> I have read that QML offers a binary debug protocol that is used by 
> several tools to to gain insights into QML applications. I read about 
> this interface here: http://doc.qt.io/qt-5/qtquick-debugging.html
> It is stated that: "The Qt QML module provides services for debugging, 
> inspecting, and profiling applications via a TCP port."

In fact you can also use a local socket or (with restrictions) the 
native debugger as connection mechanism.

> I'm planning to build my own tool on top of that API. I searched around 
> for the description and details about this protocol for a while but 
> couldn't find much beside the qtdeclarative git repository which seems 
> to contain the implementation.
> 
> Do I have to reverese engeneer the API from the source code or is there 
> some form of documentation that I wasn't able to find?

There is private API for interacting with the various debug services. 
Take a look at src/qmldebug in qtdeclarative. The code results in a 
static library called QtQmlDebug. You can either link against that (with 
the usual caveats of using private API), or you can use the code to 
figure out how the protocol works.

There is QQmlDebugConnection to establish a connection to the target 
application, QV4DebugClient for JavaScript debugging, 
QQmlEngineDebugClient and QQmlInspectorClient for QML debugging, 
QQmlProfilerClient for profiling, QQmlEngineControlClient for 
synchronizing the profiler in case of multiple QML engines, and 
QQmlDebugMessageClient to receive debug messages through the connection. 
I'm thinking about adding QQmlDebugProcess to QtQmlDebug, so that you 
get an easy way to start a process and directly connect to it. That 
class so far is in tests/auto/qml/debugger/shared in qtdeclarative.

If there is demand for this, I would consider making it public. It 
probably needs some more cleanup, but generally the client interfaces 
look good.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Changes to Javascript runtime in 5.12

[Ulf Hermann]

Hi René,

> In JS libs before 5.12, I've always used a closure approach to not
> leak a bunch of private variables onto the global module object. This
> results in a layout much like so:
 >
> (function(lib) {
>   ... closed vars can be declared here ...
> 
>   lib.bar = function() {
> return "baz";
>   };
> })(this);

You can still pass an empty object to your anonymous function and 
extract the interesting bits of that into the JS file's global scope 
afterwards. Or you can declare a number of vars outside the anonymous 
function and assign functions to them from inside. Both options are 
indeed a bit uglier, though.

This looks like a regression in Qt 5.12, but I will need to take a 
closer look at it. Did we ever document anything about the semantics of 
the "this" object in JavaScript libraries?

best regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Overriding list properties in QML at initialisation

[Ulf Hermann]

Hello,

> If I create a class with a QQmlListProperty and then initialise it with 
> an array in some QML file, then subclass the QML type in a second QML 
> file and try to override the array there, when creating an instance of 
> the child class, the list contains the arrays concatenated instead of 
> the overriding array.

That's the expected behavior of the default property, e.g. children in 
QQuickItem. Arguably, it should not extend to explicitly setting any 
other list properties.

> In the following example, I would expect the list to contain 2 elements 
> instead of 5. What are your thoughts? Should I fill a bug report and try 
> to provide a fix?

Yes, that would be nice. Keep in mind that the default property should 
still behave the old way, but only if you actually use it as default 
property. The details can be discussed in the report, though.

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML and sensitive data

[Ulf Hermann]

> Cheap hack #1: assign both fields new values once validated, say "*" 
> and force screen update before navigating away.

No. Strings are immutable in QML (and JavaScript). The old string will 
still be in memory at that point. And no, it's not a QString. 
const-casting and overwriting from C++ wouldn't do, even if it didn't crash.

Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML and sensitive data

[Ulf Hermann]

Hi,

> Just in case if someone will be looking for solution - I've managed to
> eliminate all the sensitive data from memory on closing particular QML
> screen without sacrificing existing architecture. The secret is pretty
> simple: just avoid situations when QString-s gets copied into JS
> strings:
> 
> 1. Do not use QJsonArray as the model for QML, use QVariantList as the
> replacement instead. At least because QVariantList of QVariants of
> QStrings allows an access to QString if required.
> 2. Use Quick Controls 2 because they are implemented in C++ and thus
> doesn't result in creation of JS strings
> 3. On destruction of Quick Controls pass properties like 'text',
> 'displayText' etc to C++ where const_cast and nullify
> implicitly-shared buffer.
> Bonus: QJsonDocument provides nice 'rawData' function allowing to
> cleanup its internals if required.

I can _not_ recommend this approach. The string may get copied 
internally in many places. Bindings may be evaluated as JavaScript, 
necessitating a JavaScript string representation. The visual 
representation of the string may be generated at some point, passing the 
string through layers of rendering code. The string has to be assembled 
from input somehow, potentially by re-allocating and expanding a buffer 
as you type. The old buffer will not be erased, and the input events may 
be allocated and deleted on the heap, without erasing them before 
deletion. You can _not_ be sure that the string is completely erased 
from memory after theses steps.

And obviously const_cast'ing and nullifying a string is not thread safe. 
If you are running a threaded render loop, for example, you may just 
have created a race condition.

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Binding based on typeof doesn't work any more

[Ulf Hermann]

> But still: Why has the behavior been (apparently) changed at all in the 
> first place? Or is it a bug after all?

It does sound like a bug. Can you please open a bug report at 
https://bugreports.qt.io ? I would like to know

* What is the last version of Qt your example worked correctly with?

* What version of Qt broke it?

* What is the value of "typeof Controller" in the case where it should 
show the empty string and in the case where it should show the actual 
value for the good and for the bad version of Qt.

* What type is Controller.successfulSteps

* If Controller.successfulSteps is an integer, does the following work?
text: typeof Controller === "undefined" ? 0 : Controller.successfulSteps

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Stepping into Qt sources (Qt 5.14, MinGW 64-bit)

[Ulf Hermann]

> Stepping into -O2 builds (-O3 for QtCore and QtGui) is painful at best. The
> debug information we provide is not usable for more than getting backtraces to
> help the developer solving issues.

Stepping into optimized builds is kind of an annoyance but, at least for 
me, it is much less of a pain than you make it sound. When I'm are 
looking for the kind of bugs that only occur in release builds, due to 
some race condition or some optimization/UB my code didn't account for, 
it is _very_ handy to have the debug symbols for the officially 
distributed builds. Also, the above mentioned backtraces alone are worth 
every single byte of debuginfo we provide. Therefore, debug symbols for 
release builds are important and QTBUG-81354 needs to be fixed.

Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML property lint suggestion

[Ulf Hermann]

> I'm here watching Ulf's QtWS19 QML talk and had a thought... I might
> be dumb or crazy (either are equally likely) but, the other day I
> added a property called 'data' and completely broke my application.
> It was to store data I received. However QML also declares a property
> 'data' which is essential to Qt. But I never got an error or warning.
> So my suggestion is to have some warning (or error?) like "declared
> property 'data' shadows an existing property"

You probably mean QQuickItem::data(). It is not QML that came up with 
the name, but rather QtQuick. It would be appropriate to make that 
property FINAL in Qt6, so that you do get a warning when trying to 
shadow it. I don't think we can change the name at this point, but 
adding an alias might be possible.

Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will Qt6 end this enum issue? (or even 5.15?)

[Ulf Hermann]

Hi Jason,

you should open or find an existing bug report that describes your 
problem and notify me about it. Then we have a more persistent place to 
discuss this, and someone might feel inclined to fix it. Also, I'm 
always happy to accept patches and I can give advice on how to navigate 
the code in that particular area.


regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] How to set a QJSValue with functions as a context property in QQmlContext?

[Ulf Hermann]

Is there a way to set a QJSValue as a context property in QQmlContext and
retain function properties?


You should not do this. Context properties are invisible to any tooling 
or static analysis of your QML code and add significant complication to 
the name lookup logic. The fact that you can inject names into QML this 
way is one of the few reasons why we need to version our imports. In Qt6 
we aim to move away from this.



I am loading a .js file with QJSEngine::importModule(). The result is
QJSValue object containing all exported functions and properties from the
module.

 // file.js
 export function someFunction(someArg) {
 return someArg;
 }
 export someVar = "value";

 // importing code
 QJSValue module = engine->importModule("/path/to/file.js");

Now I want to evaluate JS code snippets with my modules installed. I need
fine-grained control over contexts and my real-world application uses a
context hierarchy. So I use QQmlExpression and set my imported module as a
context property:


Why do you need to do this with contexts? I would suggest a singleton to 
hold the QJSValue, or a QML file that imports the JavaScript itself. In 
both ways you get a declared name as scope for your script, which avoids 
the name injection.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] How to set a QJSValue with functions as a context property in QQmlContext?

[Ulf Hermann]

I am not loading QML documents at all nor do I need QML tooling here. This
is pure JS. I have a bunch of JS code snippets to evaluate. The snippets
expect certain properties to exist, but they do not necessarily share the
same context. Some of them do though.


OK, that does paint a different picture. The feature you are asking for, 
then, is for QJSEngine to allow defining ECMAScript modules from C++, 
that can be imported in your JavaScript files via standard ECMAScript 
"import" statements. I would not be automatically opposed to such a feature.


However, as all of your code seems to be JavaScript anyway, why don't 
you write everything as real ECMAScript modules in the first place? 
AFAICS the C++ code in your example is only used for plumbing. Is that so?



The final goal is to port the scripting backend of Qbs from QtScript over to
the V4 engine, but I am still at the very beginning. Although Qbs files look
like QML, we are not using the QML machinery. Instead, we use only the QML
parser to decompose the document structure and retrieve items and property
declarations/assignments. The resulting code snippets (property assignments)
are then evaluated in different contexts. We have different context levels,
e.g. a document context for imported JS modules, a product context for
properties related to the current product, and a property context where we
provide properties like "base" referring to the base class value.


import * from "documentFooBar"
import * from "productA"
import base from "propertySomething"

The respective .mjs files would be modules that set up the required 
stuff in JavaScript. You can also put import statements into any 
dynamically evaluated JavaScript snippets.


The nice thing about importing things explicitly is that the JS engine 
knows what is there already when compiling.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] rebooted QtWebKit for Qt4??

[Ulf Hermann]

It is sad to see people miss the necessity for hardware accelerated UI
that QML addresses; Qt widgets backing onto QPainter was extremely
problematic to accelerate and the Qt company addressed this with
scenegraph/QML.


It's actually QtQuick that implements the scene grah and provides 
accelerated rendering of user interfaces. If you're willing to use 
private headers and deal with some inconvenience, you can use much of 
QtQuick from C++, without any QML (I don't recommend it, though).


QML is a general purpose language for composing object hierarchies. It's 
well suited for composing user interfaces, as they generally follow a 
pattern that maps well to the language's purpose. However, you can also 
use the QML language for other applications.



Feel free to hate on QML, just be aware you appear to be missing the
driving impetus behind it which was not fashion but necessity.


Feel free to hate on anything, but maybe first figure out what the thing 
you are hating actually _is_ ...


... it seems to be a common problem these days.

best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML/C++ interaction in Qt6

[Ulf Hermann]

- Allow QML to access public properties of classes, even if these public 
properties do not use `Q_PROPERTY`

- Allow QML access to classes that are neither `QObject`, nor `QGadget`


This is not planned right now. Note that we rely on moc to generate the 
class descriptions that QML uses. Therefore, we need constructs like 
Q_OBJECT, Q_GADGET and Q_PROPERTY to make things visible.


best regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML/C++ interaction in Qt6

[Ulf Hermann]

Will Qt 6 still use the Meta information to access Qml properties or
it rely more on compiled C++ now? I guess it still the same as
before. Is the properties declaration of Qt for MCU (Qml lite or
soemthign like that) be available (syntax wise, template)? That would
leverage soo much redundent code to expose properties with get/set
and changed event. That will be a slim fast for code that expose to
Qml (to Meta data actually, Qml use the meta data) and maybe event
make that layer disapear one day.


Registration of C++ types for QML in dev is largely unchanged from 5.15.
You get the QML_ELEMENT etc. macros we introduced in 5.15 to make the
registration as painless as possible. The indirection through the
metatype system is necessary for the case of dynamically interpreted
QML. We can generate C++ code from your QML to directly access your C++
types, but if you want to execute that same QML in interpreted mode,
those C++ types need to be visible to metatype system in order to be
accessible.

Also, the new property system is being introduced. If you provide a
BINDABLE property, you may be able to skip the READ, WRITE, and NOTIFY
methods in the future. This is still being worked on, though.

best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML/C++ interaction in Qt6

[Ulf Hermann]

On 9/14/20 5:29 PM, Jérôme Godbout wrote:

Oh,... now that's a deal breaker... I guess I will have to stick with
the old method for a while, having 1 plugins per modules to be expose
will need some major refactor over here. I have subrepos who have a
single .pri and might expose a few modules and some modules are
partials between subrepos. I gather my .pri to build for some targets
and platforms specific subrepos might add stuff to it.


You can also phrase your modules as C++-only static libraries and link 
them all together into the application. Mind that tools like Qt Creator 
or qmllint may have a hard time figuring this out and might not give you 
a meaningful analysis of your QML code. You will need to manually 
install your .qmltypes files into the import path or merge them together 
into a single one in the application directory. There is no "link" step 
for .qmltypes files (yet).



The idea seem good, but the result doesn't scale too well and ain't
flexible. Is the old way will still work into Qt 6 then?


You can still manually call qmlRegisterType, but if you want qmllint and 
a future QML-to-C++ compiler to see your C++ types, you shouldn't.


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML/C++ interaction in Qt6

[Ulf Hermann]

You can also phrase your modules as C++-only static libraries and
link them all together into the application. - That will depends on
which C++ library your modules depends on. Not all code can be
legally made static, this restriction, seem rather short sighted.
Hope they change this.


Well, yes, you can _also_ link all those static libraries together into
a dynamic one, but the effect is largely the same.

And, linking some static libraries into your application does not make
the application static. It's just a way of grouping related code and
having separate build system projects for each group. That's what I'm
after as it allows you to declare multiple module URIs per binary.

However, as said before, this functionality still needs some polishing.

best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtPlugins statically linked not loading

[Ulf Hermann]

Hi Nuno,

> This is the .pro
> [...]
>  LIBS += 
> /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick.2/libqtquick2plugin.a
>  LIBS += 
> /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Window.2/libwindowplugin.a
>  LIBS += 
> /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Controls/libqtquickcontrolsplugin.a
> }

You probably have to add the following somewhere:

LIBS += /path/to/libqmldbg_tcp.a

Then you should be able to to link the final library or application also with 
QML debugging enabled. Mind that this way your application has the QML debug 
server built in and whenever you start it with the right arguments or call 
QQmlDebuggingEnabler::startTcpServer() it will open a debug port and accept 
connections from anywhere. With a dynamically linked Qt you have the option to 
delete the plugin in order to prevent this.

regards,

-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtPlugins statically linked not loading

[Ulf Hermann]

> When I built Qt statically I had used this line:
>
> configure -prefix /Users/nsantos/Qt/5.4/clang_32_static -platform 
> macx-clang-32 -commercial -release -static -nomake examples -nomake tests 
> -opengl desktop -skip webkit -skip multimedia -D QT_QML_NO_DEBUGGER
>
> I had to use -DQT_QML_NO_DEBUGGER because there was an issue when linking a 
> project using QtQml:
>
> Undefined symbols for architecture i386:
>   "QTcpServerConnection::QTcpServerConnection()", referenced from:
>   QQmlDebugServerThread::run() in libQt5Qml.a(qqmldebugserver.o)
> ld: symbol(s) not found for architecture i386
>
> Do you think there is a relation between these two problems?

This is exactly what I'm talking about. As you seem to specify all the plugins 
manually anyway, you may want to drop -DQT_QML_NO_DEBUGGER and specify the 
qmldbg_tcp plugin in the .pro file, as that contains the implementation of 
QTcpServerConnection. Unless, of course, you don't want to do any QML debugging 
and profiling. In that case you should stick to -DQT_QML_NO_DEBUGGER.

-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtPlugins statically linked not loading

[Ulf Hermann]

> macx:{
>  CONFIG += lib_bundle shared
>  QTPLUGIN += qcocoa *qmldbg_tcp qmldbg_tcp_qtdeclarative*
I guess this doesn't have any effect on static builds. I'm no qmake expert, 
though. Also, there is only one of them. It's called qmldbg_tcp.

>  QMAKE_POST_LINK = mv -f $(TARGET) 
> $$PWD/../vstbuild/32/$$join(TARGET,"","",".vst")/Contents/MacOS/$$TARGET
>  OTHER_FILES += Info.plist
>  LIBS += 
> /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick.2/libqtquick2plugin.a
>  LIBS += 
> /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Window.2/libwindowplugin.a
>  LIBS += 
> /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Controls/libqtquickcontrolsplugin.a
Apparently you've put some important plugins here. You could try adding the 
qmldbg_tcp one here, too.

-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtPlugins statically linked not loading

[Ulf Hermann]

On 06/01/2015 06:10 PM, Thiago Macieira wrote:
> On Monday 01 June 2015 15:01:14 Ulf Hermann wrote:
>> You probably have to add the following somewhere:
>>
>> LIBS += /path/to/libqmldbg_tcp.a
>
> but like I said, he shouldn't have to. That's a bug in QtQml that it uses
> qmldbg_tcp without linking to it.

This is a static build. There is no dynamic linking. The only way to make this 
work would be to build the plugin into QtQml. Actually it used to do this, 
until fac14e459734936320003c3e593481c9cb6079e5 - which explicitly avoided it 
with the following reasoning:

> commit fac14e459734936320003c3e593481c9cb6079e5
> Author: Pasi Petäjäjärvi 
> Date:   Fri Oct 24 11:31:38 2014 +0300
>
> Don't embded qmldbg_tcp plugin to libQt5Qml in static build
>
> Embedding qmldbg_tcp sources to libQt5Qml causes multipled
> definitions of QTcpServerConnection symbols with static
> build on Qt Quick 2 applications. Qmake can resolve
> dependencies to static plugins applications use, so no
> need to embed this to libQt5Qml.
>
> Change-Id: I18c5e44b9ac3de4ef8be29cc5944de3527566b3c
> Reviewed-by: Fawzi Mohamed 

Now, I really don't know what qmake magic he is referring to here and where the 
multiple definitions came from. Maybe qmake is supposed to automatically add 
libqmldbg_tcp.a to the linker command line.


-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [QGV] Asynchronous painting of millions QGPathItem

[Ulf Hermann]

Hello,

I had a somewhat similar, but not quite the same problem when building the 
timeline view for the QML profiler in Qt Creator. It's currently usable with up 
to about 1 million events in the timeline and you can zoom and scroll it. There 
might be potential for further optimization. I used the Qt Quick SceneGraph API 
to directly work with OpenGL geometry. The scene graph nodes are built on 
demand and then cached and recycled when applicable. You can check out the 
result in the Qt Creator sources in src/libs/timeline.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Again trouble with SCXML donedata

[Ulf Hermann]

Hello,


[...]

EventConnection {

stateMachine: p.stateMachine

events: ["done.state.Leave"]

onOccurred: {

console.log("done: " + event.name + " [" + event.data + "]")

}

}

[...]



done.state.* events are internal. You can expose them using this snippet of 
scxml:







It requires the ecmascript data model and knowledge of the possible parameters, though. Also, 
 is sent with the done.state event of the parent state, not the done.state event 
for the  itself. That is, you want to listen for done.state. 
here, not done.state.Leave.

(I'm just realizing that the ftpclient example that comes with 5.8 is actually 
invalid scxml. If it wasn't, it would be a great example for how to forward 
events. So, don't look at it until it's fixed.)

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 2017

[Ulf Hermann]

Another alternative of course is to use some other client-server protocol such 
that only the “model” of MVC is on the server, and UI rendering instructions 
are sent across the network instead of actual rendered graphics.  For example 
load QML over the network and run it locally.  For some reason we aren’t 
putting much emphasis on that as a primary use case yet, but I wonder if 
anybody in the field is doing much of that?


It's called "The Web" and there are many reasons to hate it. However, one thing the 
relevant people in the field got somewhat right (IMO) is the level of coupling between the 
"model" and the rest of the application.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Crash with Qt application that use OpenGL

[Ulf Hermann]

ps: i had a chat with a mozilla developer some time ago: they never use
desktop opengl on windows, but only use ANGLE with a fallback to
software rendering, if the application crashes on customer's machines.


You can force Qt to use Angle by setting the QT_OPENGL environment 
variable to QT_OPENGL=angle. Then detect if it crashes, by registering a 
signal handler or similar (sorry, Qt cannot do that for you). If it has 
crashed the last time set QT_OPENGL=software. There you have the same 
behavior.


See also http://doc.qt.io/qt-5/windows-requirements.html for more details.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML debugger doesn't work for big cmake-based project

[Ulf Hermann]

On 08/11/2017 04:48 PM, Alexander Ivash wrote:
> On launching debugger I see 'QML debugging is enabled. Only use this in a
> safe environment.' but don't see 'Waiting for connnection...', so it
> looks line debugger is not completely initialized. 

Does your application do anything complicated before creating the first QML 
engine? The line is printed and the debugger is initialized once the first QML 
engine gets created. If that takes forever, Qt Creator might assume that there 
is no QML engine and give up.

cheers,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML debugger doesn't work for big cmake-based project

[Ulf Hermann]

On 08/11/2017 05:01 PM, Alexander Ivash wrote:
> But then way don't I see 'waiting for connection... ' ? 

Because it only starts waiting for connections once a QML engine exists. Before 
that there is nothing to debug anyway.

> Also, If what you say is true, then is it possible to increase this timeout ?

No, but you can press "Retry" on the connection failure message box that Qt 
Creator gives you.


Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] SCXML and datamodel sharing in Qt Quick and C++

[Ulf Hermann]

> 1. I use scxml compiler and expose compiled machine to Qt Quick.
> 2. I use ecmascript as datamodel type. I create data entries in *.scxml file.
> 3. I need to repeat those values on Qt Quick side and assign to 
> StateMachine.initialValues so that they will be reset everytime machine 
> starts - without it even when default values for data entries in scxml file 
> are set - they are not reset.
> 4. To change model entries (and the same evaluate transition conditions that 
> have those entries in cond attribute) I need to send custom, external event 
> from Qt Quick (let's call it DATAMODEL.CHANGE), which contains dictionary. In 
> scxml I handle that event by assigning all entries of that dictionary to  
> corresponding datamodel entries.

You cannot really stop and "deinitialize" a statemachine. If you set running to 
false, it is paused and will continue from the point where it stopped when you 
set it to true again. So, in order to reset the data model you have to destroy 
and recreate the state machine.

> Is it possible by any way to define model once and share it between scxml 
> state machine, Qt Quick, C++ side?
QScxmlStateMachine has a property "dataModel" which can be accessed from the 
outside and you can manipulate properties on that. However, the respective 
methods are not Q_INVOKABLE, so for QML you'll have to wrap that in some other 
type. The lack of proper QML API for this may be a bug. In any case, sending an 
event to the state machine is a cleaner way to do this, as otherwise the 
machine will not know that the value has changed and will not react to the 
change until some other event happens.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] ASSERT: "m_engines.contains(engine)" in file qqmlenginedebugservice.cpp, line 802 qqmlenginedebugservice.cpp: 802

[Ulf Hermann]

What needs to be done to get rid of this assertion (is it possible at
all or QmlDebugger is always expect single QQmlEngine? )


You can have multiple QML engines attached to the debugger, but the 
current assumption is indeed that they all live in the GUI thread. This 
can probably be fixed, but are you sure that you don't hit any other 
limitations with this? For example, the type loader also does 
interesting things with threads and locking.


br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QT SCXML: How to access Event parameter from State?

[Ulf Hermann]

> In the example above, how would we get access to Event parameter for "state1" 
> and "state5"?

You can access the event currently being processed via the data model. The 
EcmaScript data model has a readonly property "_event" and the C++ data model 
has a method scxmlEvent(). The null data model doesn't handle events, so 
without a data model, you can't access them.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Interest Digest, Vol 79, Issue 19

[Ulf Hermann]

> When I said "most machines are little-endian", I was referring to machines Qt 
> runs on and, therefore, would use QDataStream. The fact that the default is 
> big endian is short-sighted. It should default to little-endian.

We could change the default. All it takes is a new QDataStream::Version, isn't 
it? (And whoever prefers big endian can then still setByteOrder() on the data 
stream).

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qmlscene install problems (was: Interest Digest, Vol 82, Issue 5)

[Ulf Hermann]

This thread has gone so far south, we need to add some corrections ...

First things first: You probably don't need qmlscene. The only project type 
that currently needs qmlscene to be available is the "Qt Quick UI Prototype". 
Unless you are working with such projects, you can ignore the warning.

>>> I just installed Qt Creator 4.5.2 from kubuntu apt sources.
>>> It installed qmlscene + qt development files at the same time.
>>> I can see clearly there is a qmlscene executable right next to qmake in 
>>> the same directory: /usr/lib/qt5/bin
>>> How do I get rid of the "no qmlscene installed" warning?

This may not be the place where Qt Creator expects qmlscene on your system. For 
example, on my system I have a /usr/bin/qmlscene, which is not an actual 
qmlscene binary, but belongs to a package called "qtchooser". qtchooser wraps 
different Qt versions on demand. The same holds for qmake itself, actually. On 
my system, just calling /usr/bin/qmake results in an error, because qtchooser 
defaults to Qt4 and I purposely don't have a Qt4 environment installed. Qt 
Creator will actually query the qmake that belongs to your Qt for the binary 
locations, and it has some heuristics on which one that might be. For me that 
results in something like:

# /usr/lib/x86_64-linux-gnu/qt5/bin/qmake -query
[...]
QT_INSTALL_BINS:/usr/lib/x86_64-linux-gnu/qt5/bin
[...]

Qt Creator will list the results of that query in the Qt Version options in 
Build & Run settings (press "Details" there). You can check if there is a 
qmlscene in the path given there, and if not, search the package database for 
one.

So, it turns out I have another qmake (and qmlscene) in 
/usr/lib/x86_64-linux-gnu/qt5/bin/ which are explicitly the right ones, and 
which I can invoke manually if I actually need them. Qt Creator autodetects 
those. I could also configure qtchooser to use them.

>> I've been using Creator from distro repos for a while in the past, and 
>> quite often this would result in some weirdness or breakage. I recommend 
>> installing Creator using the online installer instead.

You can just install the package that contains the right qmlscene binary for 
your Qt version. Debian has a separate package called "qmlscene". I don't know 
how that works on Ubuntu. In fact the online installer won't get you very far, 
unless you are willing to also use a version of Qt obtained via the same online 
installer. This whole thing is a problem of your Qt version and indeed possibly 
of Ubuntu messing up the paths. It's probably not a problem of Qt Creator.

> 1) Some fool used qml to create the welcome screen thus first introducing the 
> problem. qml should never be used for anything.
> 2) The 12 year old boys who crow about being "maintainers" of packages do 
> little in the way of actual maintenance and testing. They simply remove 
> anything someone complains about or which doesn't compile.
> 3) Ubuntu doesn't test shit. They rely on the YABUs (Yet Another uBUntu) to 
> provide fixes for them
> 4) Virtual Machines tend to hose QtCreator, or at least historically did.
> https://bugreports.qt.io/browse/QTCREATORBUG-958> [...]

And none of that has anything to do with qmlscene being installed or not, or 
how Qt Creator deals with it. Also, the qmlscene utility and the QML language 
are two rather different things. The welcome screen (used to) be written in 
QML, but Qt Creator doesn't use qmlscene to run it. So, all of this rant is as 
misplaced as it is unnecessary. The only thing that may be remotely relevant is 
the comment about Ubuntu's testing practices, but the information we have here 
is far from being conclusive on this being an actual problem. The author should 
be sorry for wasting everybody's time.

best regards,
Ulf Hermann
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qmlscene install problems

[Ulf Hermann]

On 07/23/2018 07:55 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> El lunes, 16 de julio de 2018 08:12:25 -03 Ulf Hermann escribió:
>> This thread has gone so far south, we need to add some corrections ...
> [snip] 
>> So, it turns out I have another qmake (and qmlscene) in
>> /usr/lib/x86_64-linux-gnu/qt5/bin/ which are explicitly the right ones, and
>> which I can invoke manually if I actually need them. Qt Creator autodetects
>> those.
> 
> Mind you this is a debian-specific patch:
> 
> <https://salsa.debian.org/qt-kde-team/qt/qtcreator/blob/master/debian/patches/
> always_autotect_qt_versions>

If I read that correctly, the patch takes care of updating system provided Qt 
versions when they are installed or uninstalled. The initial detection of "the" 
system-installed Qt Version should also work with stock Qt Creator, via 
"qtchooser -l". You may want to push a clean version of this patch upstream. 
Automatically adapting to system configuration changes seems desirable to me.

Ulf

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qt_add_qml_module and not embedding QML files

[Ulf Hermann via Interest]

Is there a way to not embed QML files into the Qt resource system when 
using qt_add_qml_module() ?


We can only pre-compile files embedded into the resource file with 
qmlcachegen. That's why we strongly recommend using the resource file 
system. You can, of course still manually write your qmldir files and 
handle the build process manually like in Qt5. It's definitely not 
recommended, though.



Or at least, not generate the "prefer :/..." line in the qmldir file ?


The "prefer" line is vital. If you drop it, the module still looks like 
it would use the pre-compiled code in the qrc system with all the nice 
optimizations you get from compiling functions and bindings to C++. Yet, 
the QML engine will actually load the files from the host file system 
and ignore all of the goodies. Don't do this.


Having the prefer line makes it impossible to load QML files from disk, 
preventing any kind of live reloading of QML.


If you're using Qt Creator's "QML preview" feature, it should try to 
match your qrc paths to the source paths in your project. As the engine 
then runs in debug mode, it can live-replace the contents of the QML 
files. There is also a command line "qmlpreview" tool.


If the QML preview feature somehow got broken in Qt6, please file a bug 
report. It is mostly used by Qt Design Studio, and Qt Design Studio 
likes to use "qmlproject" projects without cmake.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt_add_qml_module and not embedding QML files

[Ulf Hermann via Interest]

I cannot use qmlpreview, as I usually need to have the full application 
running.


You can run any application through QML preview. In Qt Creator (in 
contrast to Qt Design Studio), the option is a bit hidden: There is a 
"QML Preview" Option in the build menu. Use that to start the 
application. You can then right click on any QML file in the project 
tree and "Preview file".


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt_add_qml_module and not embedding QML files

[Ulf Hermann via Interest]

I did not know about that, it looks nice.
But... it does not work with my application, it gets stuck at "QML 
Debugger: Connecting to socket"


You probably have to enable QML debugging and profiling in the build and 
run settings.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt_add_qml_module and not embedding QML files

[Ulf Hermann via Interest]

You probably have to enable QML debugging and profiling in the build
and run settings.

It is already, and it works.
I can set breakpoints in QML and it works as expected.


Can you try to construct a minimal example that reproduces the problem 
and create a bug report?


One significant difference between QML debugger and QML preview is that 
the debugger uses a TCP connection while the preview uses a local 
socket. The QML profiler also uses a local socket. Does that work?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt_add_qml_module and not embedding QML files

[Ulf Hermann via Interest]

2. The app is primarily widgets, but we use QML inside QQuickView, 
inside container widgets. So when the app starts 3 or 4 QML engines are 
created.


That is a problem. The preview can only handle a single QML engine so 
far. You should see the following error message:


" QML engines available. We cannot decide which one should load the 
component."

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Scripting within Qt6 and QJSEngine

[Ulf Hermann via Interest]

Hi Filippo,

the equivalent to Q_OBJECT for value types is Q_GADGET. So, your data 
structure would look like this:


struct DataPoint
{
Q_GADGET
Q_PROPERTY(double x MEMBER x)
Q_PROPERTY(double y MEMBER y)

public:
double x;
double y;
}

Now, depending on what you want to do with that in JS it may or may not 
work. I'd need some more details there.


NB: In QML (as opposed to JS) you can register named value types these 
days. There is the QML_VALUE_TYPE macro. In QML value types can be 
constructible and/or structured, offering different ways to create them 
from JS expressions. Finally, in QML, value types can be stored in 
lists. You can have "property list" if you use QML for your 
scripting.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Scripting within Qt6 and QJSEngine

[Ulf Hermann via Interest]

That is an intesting question because it somehow pin points something 
that is
not clear to me. Perusing the documentation, I saw that QQmlEngine 
derives from

QJSengine. I cannot figure out which is best to employ in my use case:
scripting a QtWidgets C++ application. Can I use QML as a scripting 
language in

a currently C++-only program ?


Sure, you can. QML, the language, is independent from any UI technology. 
Most people use it with Qt Quick, but no one forces you to use Qt Quick. 
When using widgets you'll have to do some more "boring" work yourself: 
There is no pre-made QtWidgets QML module, but you can certainly 
register the types you're interested in into your own modules using 
QML_FOREIGN.


Mind that structured and constructible value types will only be 
available from Qt 6.5 on. You can use the snapshot builds already for 
prototyping, though.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Scripting within Qt6 and QJSEngine

[Ulf Hermann via Interest]

I think that QML/JS is not viable for scripting of QtWidgets since
public functions are not available when registering Qt classes as
types (only slots and Q_INVOKABLE functions next to properties).
Without the public class functions only very basic functionality is
exposed to the scripting engine. For custom classes one has of course
control over what will be exposed but one can not change this for
existing QtWidget classes (except when changing source code).


"Not viable" is a bit harsh. There are limits to this approach, but
people have done it before. See for example
https://www.kdab.com/declarative-widgets/ . If you want to create the
whole widgets UI declaratively in QML, you're probably going to hit some
major road blocks. However, it doesn't sound like that was the plan
here. If you just need some additional functions exposed to C++, you can
create your own proxy types with additional Q_INVOKABLEs.

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qmake to cmake - error: redefinition of 'unit' const QQmlPrivate::CachedQmlUnit unit

[Ulf Hermann via Interest]

list(APPEND QML_FILES
 resources/qml/Browser.qml
 resources/qml/BrowserBank.qml
 resources/qml/BrowserButton.qml
 …


Are there more files called "Browser.qml" in the same module? That 
doesn't work. Your QML components need unique names.


Or is there some qt_target_qml_sources() or similar, repeating the same 
QML files?


In general, I think we need a bug report with a complete example.

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qml Linting Error - Warnings occurred while importing module "QtQuick.Controls":

[Ulf Hermann via Interest]

Warning: QtQuick.Controls uses optional imports which are not supported. 
Some types might not be found.


This is not an error but a warning. Indeed the compiler will not compile 
your code to C++ because it doesn't know which of the optional imports 
(ie styles) will be active at run time. You can import one specific 
style, for example QtQuick.Controls.Fusion instead of QtQuick.Controls. 
Then the compiler will know what to expect, but you won't be able to use 
a different style at run time anymore.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qml Linting Error - Warnings occurred while importing module "QtQuick.Controls":

[Ulf Hermann via Interest]

- Have an option to disable the warning for those who want to support multiple styles in 
one executable (but still want compilation outside of controls). You said it is possible 
to "disable the compilation for this specific file", but I'm not sure if that's 
the same thing as disabling the warning for the whole codebase, which would be preferable.


As described in https://doc.qt.io/qt-6/qt-add-qml-module.html you can 
turn the compilation to C++ off per target with the --only-bytecode 
option to qmlsc or qmlcachegen. qmltc and qmllint are opt-in anyway.



- Add instructions to the warning that mention how to fix it if they're OK with 
only supporting one style, or disable it.


The message is a generic warning you will get for any optional imports, 
not only for QtQuick.Controls. If you don't like to see this warning, 
you can turn it off in most cases:


* qmllint currently has no way to output this warning.

* qmlcachegen is silent by default and suppresses all warnings.

* qmlsc outputs warnings, and also this one, by default, but you can 
just turn off the qt.qml.compiler.aot logging category if you want it to 
be silent.


* qmltc will fail on any missing type information, including this one. 
That's unavoidable. It cannot create a sensible C++ object structure if 
some part of it is invisible.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What is the right way of creating a static lib that has qml resources with cmake?

[Ulf Hermann via Interest]

With the following approach two libs are created:

libshared.a and libsharedplugin.a

I just want to have a single target called libshared.a with all the qml 
resources embedded.


You can add NO_PLUGIN to your qt_add_qml_module, but be warned: The 
linker will be clever and omit your type registrations. You have to 
prevent that in some other way then. The usual way to prevent it is 
Q_IMPORT_PLUGIN on the generated plugin.


And you should not add your QML files with qt_add_resources. The most 
important thing qt_add_qml_module does is adding your QML files.


best regards,

Ulf

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What is the right way of creating a static lib that has qml resources with cmake?

[Ulf Hermann via Interest]

If you state STATIC in qt_add_qml_module (without a qt_add_library or 
similar that makes it dynamic) and then it builds a dynamic library, 
that's a bug. Please file a report at https://bugreports.qt-project.org 
with a minimal reproducer and state the version of Qt you are using.


If it does build a static library but the library doesn't contain 
qInitResources, that's on purpose. You need to do the plugin linking 
dance which uses additional .o files ("object library" in CMake lingo) 
to pull in the resource initialization. That's because linkers 
"optimize" the resources out if you don't. We can't do much about this.


See also https://doc.qt.io/qt-6/qt-import-qml-plugins.html and 
https://doc.qt.io/qt-6/qqmlengineextensionplugin.html#Q_IMPORT_QML_PLUGIN


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What is the right way of creating a static lib that has qml resources with cmake?

[Ulf Hermann via Interest]

I will try to reproduce the problem basing myself on this. In case I 
need to submit a bug report what is the category?


Add "build system: CMake" and "QML tooling".
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest