My second advice is more for Ulf - despite your best efforts to educate people in how QML modules have changed the way we should think about our QML organisation since Qt 5, people still have trouble grasping these points:
a) what is a QML module anyway? You say whaaaat? Yes, people are still on Qt5 with a Qt5 mindset. It took me ages to work out how to retrain my thinking - and it does for others too. But I would add it is well worth it and does make life a lot easier when you set it up. Alexandra Betouni's recent #QtStories article leans into exactly this point (it's a great read and I absolutely echo her observations and sentiments). b) the thing Ulf and I spoke about in Berlin, which was the very basic fundamental structure of a relatively simple app where all the modules are defined under the "recommended" structure which is guaranteed to work without any fiddling. This is a great starting point for learners, new projects and so on. However... c) For many people, like those here, are not starting from an ideal place of legacy and in Ulf's words, already using and relying on "degenerate modules". While this is unfortunate, it happens and Qt5 allowed that to happen. So when we move things to Qt6 we have a number of steps to consider. 1) moving to CMake 2) formally defining the QML modules in CMake 3) fixing all the QML so it works within the rules 4) going back to CMake to fix the module definitions according to the *allowed* additional properties having considered their exacting requirements and rationale. This has been my own experience so I know what I'm talking about and understand both the pain and the frustration and have vented myself at "why doesn't it work like I expect" and poor Ulf has copped my wrath on more than on occasion. However, I am educated now and we are still friends. d) Ulf write a great little blog series about QML Modules back around Qt6.2. But when you look at those now, some of the information there is dated although the principles are sound. So Ulf, with your inimitable fashion of freely advising not to use foot guns and with your unique sense of humour, would you be prepared to write an updated blog - yay verily may I suggest work with Ash Walton and get it up on the Qt Academy? I would suggest and recommend it as absolute mandatory reading for anyone. I'd even go as far to say "did you do that course" as a first response. There would be some simple steps to cover based on just reworking that blog series: 1 - how it used to be in Qt5 (and why it needed to change) 2 - What is a QML module 3 - Plugin and Backing targets (most confusing for some) and when to link to what given static or shared configurations 4 - simple application structure 5 - a nod to the resource prefix and the new load component main.cpp bootstrap. 6 - a reasoned example (image provider) where you have to use one of the NO options and how a "do it yourself" plugin class looks like.and works in practice. 7 - alternative workarounds for where your source structure cannot match the default expected structure, but how to at least exchange bullets for liquorice in your foot gun if you have to (like me - I don't like the taste, but I don't eat with my feet). 8 - the code model is gleaned from the build folder NOT the source folder. 9 - you don't need to write qmldir or qmltypes 10 - how to declare singletons and internal types. 11 - if you are feeling sadistic you could also cover singletons and ownership but don't be cruel. There's obviously scope for breaking this up into a learning path with several short courses inside building on the last. I really think this would be gold in the hands of the reader in helping them get past this quite large code and paradigm change into a world of much more power, flexibility and productivity. I do hope you get your project into the shape you need. It does sound like but of a pickle at the moment but it is not going to be difficult to get you straight so do not fear or get frustrated. We will get you there! ________________________________ From: Mike Trahearn <mtrahe...@topcon.com> Sent: Saturday, February 17, 2024 9:30:27 AM To: Ulf Hermann <ulf.herm...@qt.io>; interest@qt-project.org <interest@qt-project.org> Subject: Re: [Interest] qt_add_qml_module() RESOURCES vs qt_add_resources() I have been watching the progression of this... Ulf is right. I've had this out with him many times inw writing and in person due to our out "strange non conforming" repository setup. However in our case, we do not reak any of the proper QML Module boundaries so once we apply the various allowed properties of our modules to match our structure, the build system, code model, the qmlls, qmllint qmltc, qmlsc - they all work exactly as prescribed. My first advice is this (which would also agree with Ulf): if you don't adhere to the proper QML module structure (which may I gently suggest, you haven't) then you will have these issues you describe. ________________________________ From: Interest <interest-boun...@qt-project.org> on behalf of Ulf Hermann via Interest <interest@qt-project.org> Sent: Saturday, February 17, 2024 6:06:58 AM To: interest@qt-project.org <interest@qt-project.org> Subject: 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" with an addressable component "Main" * A module called "qml.pages" with an addressable component "MyPage" and an internal component defined in xxx.qml * A module called "qml.popups" with an addressable component "MyPopup" If you put all the components into the same module, and then add any custom attributes (singleton or revision) to either MyPage or MyPopup, you're in for a surprise: The attributes will not be applied if you use the component from another .qml file in the same directory. For example if you made MyPage a singleton and then used it from xxx.qml, it would give you a confusing error message. This is because MyPage would be imported via the implicit import of xxx.qml, which knows nothing about the module you've declared one directory up. The implicit import does not contain the information about singletons. This is why it's generally a good idea to make the implicit import the same as the module a component belongs to. I have understood, though, that nobody wants to follow this rule. I'll come up with some technical solution that allows you to declare either a module spanning multiple directories or a collection of modules, each with its own directory. with a single CMake function call. The earliest possible version for that to surface in is 6.8, though. best regards, Ulf _______________________________________________ Interest mailing list Interest@qt-project.org https://urldefense.com/v3/__https://lists.qt-project.org/listinfo/interest__;!!Nbma_1s!sg8zFNfWm_RbvERXLo9exzm2qb8Q5hC7t-EDvCALmuMaLLePXS9fWtdxeyvrXNW3sk1U6l3MAPBpBw7bprbUFg$ Confidentiality Notice: This message (including attachments) is a private communication solely for use of the intended recipient(s). If you are not the intended recipient(s) or believe you received this message in error, notify the sender immediately and then delete this message. Any other use, retention, dissemination or copying is prohibited and may be a violation of law, including the Electronic Communication Privacy Act of 1986.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
