QML library

JamesKuyper

QML component library plugin "Qt Creator" qmldir C++

JamesKuyper

I want to do something that I assume is very ordinary. There will be one overall projects, and several application sub-projects which will share a fair number of QML components. I want to create a separate sub-project for those shared components, analogous to a C++ library (one of those will also be involved). Some of those components will be implemented in pure QML, others will be implemented in C++.
It seems that a QML module comes close to being what I'm looking for, but it requires creation of a qmldir file. What's surprising me is that I haven't been able to find a way of setting up a Qt Creator project that will automatically create and maintain the qmldir file for me. I would have expected such a feature. Is it actually the case that we're supposed to maintain them manually?
Also, what Qt Creator project type should I use for this purpose? Under Library, the most relevant project type seems to be Qt Creator Plugin. However, from the description and from the results when I created such a project type, such a project seems to be only for QML components implemented in C++. If I'm wrong about that, how should I organize any components defined using pure QML files to such a project?
I'm looking for existing conventions I can adopt for dealing with a very ordinary situation, not an innovative solution to an unusual problem.

raven-worx

@JamesKuyper said in QML library:

Is it actually the case that we're supposed to maintain them manually?

yes, since the features can be very complex and cannot be determined automatically (for example different files for different import versions etc)

Under Library, the most relevant project type seems to be Qt Creator Plugin.
Also, what Qt Creator project type should I use for this purpose?

QtCreator also provides a "Qt Quick 2 Extension Plugin" template (right next to the "Qt Creator plugin" entry?!)
Basically you must inherit from QQmlExtensionPlugin class and place the plugin in the QML plugin search path (e.g. in a folder matching your import url next to the binary or in Qt's qml directory)

KH-219Design

@JamesKuyper I don't know how many platforms you plan to support (and which ones), but the consultancy where I work created the following (large) "hello world" project to answer essentially the inquiry you are pondering:

https://github.com/219-design/qt-qml-project-template-with-ci

Another caveat: this is done using qmake, so if you had planned to use CMake, please ignore my comments entirely.

The top level pro file references a plugin project named libstyles

The libstyles plugin is where one can continue adding all the reusable qml:

https://github.com/219-design/qt-qml-project-template-with-ci/tree/a849fbba4fb51c5d8618284df0c70c26f4a229a2/src/libstyles/imports/libstyles

This "hello world" project is setup up for multiple platforms, which pragmatically might mean it is too bloated for your purposes.

Just to give one example, there is windows-specific code to move the plugin dll to the right spot: https://github.com/219-design/qt-qml-project-template-with-ci/blob/a849fbba4fb51c5d/build_app.sh#L83

(Sidenote: yes we run bash scripts on windows. fun stuff.)

So while I expect you would not wish to directly use the "hello world", you might be able to find solutions to any problems you have by simply looking at each pro and pri in the project.

KH-219Design

@JamesKuyper said in QML library:

one overall projects, and several application sub-projects

I just realized I may have misinterpreted "several application sub-projects". I was interpreting your use case to be one unified source code repository, where the single custom QML plugin DLL (or *.so) would be reused by perhaps multiple other libraries and executables in the outer project, but all under one unified project.

Another interpretation that I see now is one where you would "publish" or "ship" the custom QML plugin as its own independent product, and you might have multiple other source code repositories that all consume that QML plugin.

If you meant the latter, then I was probably off-topic to recommend my "hello world" as a resource. I apologize if that was off-topic. I have not attempted this latter use case of "shipping" a ready-made QML plugin for it to be used by wholly separate code repositories.

JamesKuyper

@KH-219Design: My message contained a typo: "one overall projects" should have been "one overall project".
This particular project does NOT need to be portable - it's targeted strongly to one particular platform. Every aspect of the user interface will be customized heavily for the characteristics of that particular platform (such as the size of the screen), and would unavoidably need substantial re-writes should we ever desire to port it to a different one.
We are using qmake, so that shouldn't be a problem. Both the system where the code will be built, and the system where it will be run, run Ubuntu Linux.
I'm writing this before I've had time to actually review your "hello world" project. I'll let you know if I have any questions about it.

JamesKuyper

@KH-219Design: No, there won't be any publishing of this code. We'll be the only users of it. It's specific to a particular controller that we'll be installing in our machines. High level design decisions are still being made: we might have different applications for different types of machines, or we might have one application that behaves differently depending what type of machine it's installed on. We might have multiple applications for the same machine type - but no one else will be using this code.

KH-219Design

@JamesKuyper thanks for that impeccable description of your setup. I do think, then, that you might want to borrow/copy parts of the structure of the hello-world.

(You would ignore/delete anything related to iOS, Android, etc... of which you would find a few scattered references. But those platform-specific parts of the inputted-to-qmake pro files would be inactive when building for Linux desktop anyway, so they'd be harmless if you failed to delete them.)

As I mentioned previously, libstyles is essentially one solution to your problem statement. libstyles is where I strive to put color-theme values and common icons and common custom QML controls to be used throughout the overall outermost project.

Then, both app.pro (an executable, with a main) and lib_app/lib.pro link to and access the content of libstyles, using the common added line in those projects:

include(../libstyles/libstyles.pri)

You could extend that to have as many executables and as many other libraries you want that all use the shared (and centrally-maintained) content from libstyles.

To make sure they build in the proper order (so that parallelized multi-core builds succeed), you would maintain your depends lines in proper order in the outermost project file:

app.depends = \
    lib_app \
    libstyles \
    util

lib_app.depends = libstyles util

Here are some other web links that helped me figure this out along the way: