Re: [Interest] Getting "really old" Qt sources

This should do: git checkout v5.3.2 git submodule sync --recursive git submodule update --init --recursive best, Ulf ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest

Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?

I am not seeing it in 5.15.2, was it added later? Oh, sorry, I was mistaken. https://codereview.qt-project.org/c/qt/qtdeclarative/+/304078 did indeed not make it into Qt5. Otherwise you could actually use the syntax with versions also in qmldir. So in Qt5 the versions have to match. Maybe

Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?

Not possible as in this case it assumes the same version as the module that qmldirs belongs to Looks like qmlRegisterModuleImport() is also available (and undocumented) in Qt 5.15 and it does allow you to specify versions: https://doc.qt.io/qt-6/qqmlengine.html#qmlRegisterModuleImport best

Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?

I don't think it works, adding `import QtQuick.Layouts 1.15` to qmldir of that module produces an error  "import requires 2 arguments, but 2 were provided" In Qt5 you couldn't specify the version, yet. Try with only: import QtQuick.Layouts best regards, Ulf

Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?

On 5/6/24 18:12, NIkolai Marchenko wrote: Is there a way to automatically import qtquick.layouts while importing a custom module inside of qml file? If you control the custom module and are OK with anyone importing the custom module always also importing QtQuick.Layouts, then yes. There is

Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?

... Of course it only does that if you actually import QtQuick somewhere. Correction: You need to import QtQuick.Layouts, not QtQuick for QQuickLayout to get registered. best regards, Ulf ___ Interest mailing list Interest@qt-project.org

Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?

That means it's relying on some automatic registration somewhere, somehow. QQuickLayout has a QML_NAMED_ELEMENT macro which means it's picked up by qmltyperegistrar which does what it says. Of course it only does that if you actually import QtQuick somewhere. That's probably the difference

Re: [Interest] qt_add_qml_module() RESOURCES vs qt_add_resources()

Hi Ekke, not really sure what I'll have to do - will read again tomorrow and trying to understand ;-) BTW: this is the (qml) structure of my apps: qml/Main.qml     pages/MyPage.qml /xxx.qml     popups/MyPopup.qml     ... In QML these are 3 Modules: * A module called "qml"

Re: [Interest] controlling QML singleton lifetime from C++

Hi Stefan, I'd like to be able to replace that singleton instance over the course of the application's workflow, but I couldn't find any indication in the docs for whether that's allowed, or whether that might lead to undefined behaviour. There is QQmlEngine::clearSingletons(), but it's

Re: [Interest] qt_add_qml_module() RESOURCES vs qt_add_resources()

Setting NO_RESOURCE_TARGET_PATH removed the prefix and fixes the pathes for me. [...] engine.loadFromModule("Main_Module", "Main"); Indeed, if you make the module invisible, you cannot load from it. NO_RESOURCE_TARGET_PATH is one of the "NO" options. They are called "NO" for a reason: You

Re: [Interest] CMake - List Sources: qt_add_executable vs qt_add_qml_module

I can list all my other cpp SOURCES in qt_add_executable or in qt_add_qml_module, what is recommended in this case ? It doesn't really matter. My recommendation is to list all the C++ files that produce types exposed to QML in the QML module and all other C++ files in qt_add_executable.

Re: [Interest] QGraphicsView and OpenGL in Qt6

The (former) lack of QTreeView and problems in styling QtQuick Controls are not actually about the QML language. They are about QtQuick and QtQuick Controls. I feel that I have to again remind you all that those are different things. If you are willing to use private API, you can build your

Re: [Interest] sharing singleton instance between C++ and QML

which works fine. Then I wanted to clean the code up a little more, and removed the "public:", given that the above is a `struct`, so everything in it is public anyhow. And that's where it stopped working ! The Q_GADGET macro contains a "private:", just like the Q_OBJECT macro: #define

Re: [Interest] sharing singleton instance between C++ and QML

Dear Stefan, I don't want to patronize you, but I know the person who has to handle your bug reports if things go south with whatever architecture you come up with. Such things have happened before. So, sorry if that came across in the wrong way. Wrapping your C++ singleton into another

Re: [Interest] sharing singleton instance between C++ and QML

For the record it is actually possible (I proved it) to create multiple instances of the same singleton with only one engine using a singleton published from C++ if you concoct your C++ side, um,  poorly. But that's another matter for people stuck before C++11... I've fixed QTBUG-116432 if

Re: [Interest] sharing singleton instance between C++ and QML

The very common misconception I keep reading over and over is that C++ singletons should be the same as QML singletons. They generally aren't. You can shoehorn a C++ singleton into a QML one, but if you can avoid that exercise, you should avoid it. The usual way to declare a QML singleton is

Re: [Interest] Problems with qt_add_qml_module

Well ... maybe you want to read https://doc.qt.io/qt-6/qtqml-writing-a-module.html Actually, I like https://www.qt.io/blog/qml-modules-in-qt-6.2 better because it contains some history and motivation for why QML modules are what they are. For the actual examples, better refer to doc.qt.io,

Re: [Interest] Problems with qt_add_qml_module

The first argument to the `qt_add_qml_module()` function is *not* a new target to be defined by the call. You can also give it an existing target. See all our examples that first create an executable target and then attach a QML module to it. Furthermore, the `SOURCES` argument isn't a list

Re: [Interest] Problems with qt_add_qml_module

In our existing code we call `qmlRegisterType<...>(...)` in our regular C++ code (e.g., some shared libraries that the main application links to). I thought that, to be able to use those types in stand-alone QML code, I'd need to move these calls into plugins, or at least have some QML

Re: [Interest] Problems with qt_add_qml_module

Most of the context would be injected into the QML runtime from C++ via calls to `setContextProperty()`, as well as by defining additional QML modules from C++ (via `qmlRegister...()`). This is where your architecture fails. By using setContextProperty() and procedurally registering types,

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

Actually, funnily enough, Qt.fontfamilies is an order of magnitude faster than custom property wrapping the result of ::families. Dunno why.  5s vs 500 ms for the sue case Still, checking on .lncludes(name) in javascript is seemingly also an order of magnitude slower than sending family name to

Re: [Interest] Problems with qt_add_qml_module

I'm trying to create a QML extension module using CMake, and I've run into some road blocks. I want to create a QML module including a "plugin", based on my own code rather than an auto-generated plugin stub. My first question is why? The most important part of a QML module is generally a

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

doesn't QtQuickGuiProvider do the exact same thing with QfontDatabase::families? Yes, it does. It returns a QStringList. What I mean is that you don't need a custom C++ base class for your singleton if all you want to do is expose the font families in pre-wrapped form. The following is enough

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

The question though is whether this would be a singleton per qmlengine. If it will, then that's a nogo as the list of loaded fonts needs to exist once regardless of how much engines are running Singletons are created once per engine, even C++ ones. You should not subvert this. And you cannot

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

How is instantiating a new c++ instance each time faster than referencing a c++ side singleton?? This is not what I meant. I mean: // singletonbase.h class SingletonBase : public QObject { Q_OBJECT QML_ELEMENT // Not a singleton! Q_PROPERTY( ... ) public: Q_INVOKABLE ... };

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

So do I use `pragma Singleton` to wrap a c++ singleton into a qml one declaring such a var property? That would be one way to do it. I don't know what your singleton looks like. Maybe it can be defined in QML and instantiate a non-singleton type declared in C++ rather than referencing yet

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

On 10/23/23 16:37, NIkolai Marchenko wrote: > If you cannot port to Qt6 and compile the QML code to C++ Unfortunately qt6 broke too much of Qt Quick 1 that porting will require non trivial effort. Are you really still using QtQuick 1? It had been unsupported for years already before Qt6

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

So, should I send the value from qml to c++ to do a search there instead? It's the solution I ended up doing but I hoped storing something on JS side was possible to not cross language boundaries on each item initialization. If you cannot port to Qt6 and compile the QML code to C++, this may

Re: [Interest] How to avoid qml engine repeatedly copying and garbage collecting qstringlists?

Hi Nikolai, it would be interesting to see the QML code that produces this behavior. However, I can very well imagine what's happening there. This is likely the "value type reference" problem. The list is a "sequence type". It doesn't have an identity of its own but rather is only accessible

Re: [Interest] How to prevent large qml forms from hitting javascript stack size?

> Will it still add to total object count if this is used:? Due to the fact that we're reserving space for all objects in the compilation unit, the rectangle does count towards the total. Indeed the calculation could be improved here. We're not going to need this stack slot. Maybe we should

Re: [Interest] How to prevent large qml forms from hitting javascript stack size?

Loaders with a component specified inline add to the object count. Loaders with a URL don't. And yes, we need to allow loaders with a module/component pair so that you don't have to specify a URL. We will get there. best regards, Ulf ___ Interest

Re: [Interest] How to prevent large qml forms from hitting javascript stack size?

775k objects, the form is split into smaller pieces mentioned as Components to load when needed, but qml engine traverses it all completely and reserves full memory seemingly Finally, if you really, really want this, you can patch Qt to produce a QV4::ArrayObject on the JavaScript heap rather

Re: [Interest] How to prevent large qml forms from hitting javascript stack size?

775k objects, the form is split into smaller pieces mentioned as Components to load when needed, but qml engine traverses it all completely and reserves full memory seemingly You don't want 775k objects in memory all at the same time. You can use the various views (ListView, GridView, ...) to

Re: [Interest] How to prevent large qml forms from hitting javascript stack size?

In essence: when a form has a large amount of subforms and Components, then, in the internals of qml engine, it is parsed and every piece of it is assigned totalObjectCount which is accumulated recursively for big forms. Then, in qjsengine sources this happens:

Re: [Interest] Qt 6.5.2 and qmllint questions/issues

    void AddLogger(const QString& name, QObject* logger, QQmlContext* context)     {    logger->setParent(context);    QQmlEngine::setContextForObject(logger, context);    context->setContextProperty(name, logger);     } This is actually not a JavaScript global, but a

Re: [Interest] Qt 6.5.2 and qmllint questions/issues

I was not going to add them to jsroot.qmltypes. I was wondering if there was a mechanism to extend what is defined in jsroot.qmltypes. That is pretty much the same thing. jsroot.qmltypes represents the JavaScript global object. Since all of this is pure JavaScript, we can generally not say

Re: [Interest] Qt 6.5.2 and qmllint questions/issues

Another issue we are having with qmllint is adding type information for objects added to the global object in C++. We've used this to provide custom log and assert functions, but obviously the linter doesn't know about them. If they are added to qml/jsroot.qmltypes (along similar lines to the

Re: [Interest] Qt 6.5.2 and qmllint questions/issues

You can expose the type as both a value type and a namespace: struct TestGadget { Q_GADGET QML_NAMED_ELEMENT(testGadget) Q_PROPERTY(int value MEMBER value) public: enum class GadgetEnum { OptionA, OptionB, OptionC, }; Q_ENUM(GadgetEnum) };

Re: [Interest] Qt 6.5.2 and qmllint questions/issues

Rule of thumb is "one module: one directory, one CMakeLists.txt + uri must follow source directory structure from project base". Im my experience any derivation from that rule causes pain and suffering ;-) Or maybe I still don't fully understand the IMPORTS, OPTIONAL_IMPORTS. DEFAULT_IMPORTS,

Re: [Interest] Qt 6.5.2 and qmllint questions/issues

Hi Matthew, -- QtLocation -- The linter is unable to resolve types in QtLocation. Adding the following dependencies to qml/QtLocation/qmldir resolved the problem: depends QtQuick depends QtPositioning Thanks for catching this. See

Re: [Interest] Default stack size of QThread

As we donot set any stack size for QThread and it looks like it runs out of default stack size limit during long running operation. Hence would like to measure the cumulative stack variables used in a thread so as to set stack size of QThread accordingly. It is possible to measure stack

Re: [Interest] Qt Quick: no qmake support anymore?

Which begs the question of if it's worth it to bother with QML at all, or at least, when there is the option of something else like widgets. It has a more complex model of mixing the two worlds, it requires additional build system support, and the tooling support is also an additional layer

Re: [Interest] Qt Quick: no qmake support anymore?

It will come back in a future release: https://codereview.qt-project.org/c/qt-creator/qt-creator/+/473719 It is, however, not a good idea to use qmake for new QML-based projects. In qmake you don't have qt_add_qml_module

Re: [Interest] QML singleton properties are undefined if file placed in subdirectory

Qt 6.4.2 QML singleton's properties undefined if singleton QML file placed in subdirectory e.g "/qml" (${CMAKE_SOURCE_DIR}/qml/Style.qml) You should not place your QML files in a different directory than the module (as denoted by the generated qmldir file). Otherwise their implicit import is

Re: [Interest] Porting a previous qmake approach to cmake

Amir is trying to reproduce your problem. I can't figure out what is wrong there because I don't use macOS. In the mean time, you can also just load your QML modules from the resource file system. Then they don't have to be present in the bundle's file system. To do that on 6.4 add

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

Yes, there is. There's -Wl,--whole-archive for the Unix linkers. This should solve the problem for everyone except MSVC users. That option is not very attractive because: a, as you state yourself, it doesn't work on MSVC. b, it only works at the last link step, when the library is linked into

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

It works fine here. Please file a bug report with all the details (platform, Qt version etc). Also please state whether you are trying to run the example from the build directory or from some deployment. best regards, Ulf ___ Interest mailing list

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

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

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

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

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

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

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

- 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

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

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

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

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()

Re: [Interest] Scripting within Qt6 and QJSEngine

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

Re: [Interest] Scripting within Qt6 and QJSEngine

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

Re: [Interest] Scripting within Qt6 and QJSEngine

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

Re: [Interest] qt_add_qml_module and not embedding QML files

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.

Re: [Interest] qt_add_qml_module and not embedding QML files

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

Re: [Interest] qt_add_qml_module and not embedding QML files

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

Re: [Interest] qt_add_qml_module and not embedding QML files

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.

Re: [Interest] qt_add_qml_module and not embedding QML files

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