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

2022-01-14 Thread Konstantin Shegunov
On Fri, Jan 14, 2022 at 1:58 PM Ulf Hermann wrote: > 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. > I must

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

2022-01-14 Thread 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

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

2022-01-14 Thread Konstantin Shegunov
Well, I did find out what the problem is, and how to work around it. So I'm posting for further reference to anyone that may stumble onto this. On Fri, Jan 14, 2022 at 8:09 AM Ulf Hermann wrote: > No. You can store a pointer to the type registration function somewhere > in order to prevent the l

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

2022-01-14 Thread Konstantin Shegunov
On Fri, Jan 14, 2022 at 8:09 AM Ulf Hermann wrote: > If you want the QML engine to find your module, you need to follow > certain conventions around the paths. > My resistance to this is the self-containment of the given project/target. I don't mind following the convention(s) for the paths insi

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

2022-01-14 Thread 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 targe

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

2022-01-14 Thread Konstantin Shegunov
On Fri, Jan 14, 2022 at 7:18 AM Ulf Hermann wrote: > 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. > Perhaps that's how it's suppos

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

2022-01-14 Thread 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.

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

2022-01-14 Thread Konstantin Shegunov
On Fri, Jan 14, 2022 at 6:16 AM Ulf Hermann wrote: > Is the place where the module's qmldir ends up reachable via the QML > import path? 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 ou

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

2022-01-14 Thread Günter Schwann via Interest
Hi, I did come across some similiar issue. And my solution was to add the resource as import path. qmlEngine->addImportPath(":/"); In case you don't have NO_PLUGIN, tou probably need to link to the generated "TscUiplugin" as well. Regards -- Guenter Schwann Viking Software http://www.vikin

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

2022-01-14 Thread 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

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

2022-01-14 Thread 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 perceiv

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

2022-01-14 Thread Konstantin Shegunov
Hi, I've been continuing to experiment with the Qt6 QML capabilities and I hit the following problem. I have a shared library with a couple of qml files, but for some reason I don't get them installed and when I run the application I get the module not installed error. While trying to figure out w

Re: [Interest] QML: ApplicationWindow's child strange parent

2022-01-14 Thread Nils Jeisecke via Interest
Hi, On Fri, Jan 14, 2022 at 12:35 PM Alexander Dyagilev wrote: > What does it mean? Why parent is NOT appWindow? Isn't it should be? > Is it a bug? Am I missing something? see https://doc.qt.io/qt-5/qml-qtquick-controls2-applicationwindow.html#contentData-prop "If you assign an Item to the con

[Interest] QML: ApplicationWindow's child strange parent

2022-01-14 Thread Alexander Dyagilev
Hello, I'm getting "non-valid" parent in my object. I have the following code: ApplicationWindow {    id: appWindow    MyItem {} } MyItem's code: Item {   id: root Component.onCompleted: {     console.log("appWindow:", appWindow);     console.log("parent: ", root.parent);