WARNING: Flammable reply ahead.
On 9/21/2015 9:07 AM, Nurmi J-P wrote:
That would a massive improvement, but it boils down to the same
problem. It can only be like that if Qt and QML version numbers match.
We cannot sprinkle qtquick versions to the base classes in qtbase.
As a third party developer working w both commercial and (L)GPL versions
of Qt, for me QML versioning has been an enigma at best, and a hindrance
at worst.
The original intent, I'm told, revolves around "compatibility", but in
reality, it's closer to an API contract (so you're actually better off
at thinking about it as dynamic linking to a .so file than anything
else). This, however, in a QML context, makes little sense, for the
following reasons
1. Theory: "use the lowest version you need". Practice: "use latest and
greatest, otherwise you'll always be lost"
- The documentation doesn't mention when an element/attribute was
introduced (or if it does, it's the Qt version which does not relate to
the import version)
- The documentation will always want you to import as called in the
latest version of Qt
- Autocomplete helps a bit by listing all the available versions,
but still, no idea as to which one of those is which Qt (or which ones
you used previously)
- There is no version check/fallback mechanism for QML imports at either
compile or runtime (no, having a separate QML files for each Qt version
is not a solution), which makes availability-driven incremental feature
enablement impossible. On the C++ side, you can at least if/ifdef for Qt
versions.
2. Import versioning is crude, there is no * or +, you have to aim for
exact versions
3. import statement versioning gets out of sync - after a while, it
invariably degenerates into a mishmash of versions as the projects
evolves through newer and newer versions of Qt
4. No way of verifying what Qt version you're actually compatible with
(even if you keep around older versions of Qt, the dynamic nature of QML
means you have to test extensively if something is actually working
100%). Plus remember - you're importing *API* contracts, not
implementation (if a bugfix in Qt 5.6 fixes something that inadvertently
breaks your app, importing 5.5 will not "save" you).
4b. To make it worse, the is no way of checking of QML version
compatibility at qmake time (you have to "know" what Qt version you need)
5. Suffers from versioning logic inconsistency compared to the C++ side.
Bumping QML API versions in vain is a no-no, while the C++ side bumps
regardless (modules don't claim they are 5.2 or 5.3 just because there
were no changes introduced in the given module's API - they're all Qt
5.latest)
The only use-case I can think of where the whole import versioning
scheme makes some remote sense is:
- Custom QML pugins (as those might have release cycles unrelated
to Qt)
- Platforms where you're sentenced to using a system-provided Qt
(say, apps that want to go into the public repos of Linux distros)
- FOSS projects where, for whatever reason, people might compile
with outdated Qt builds
Whichever it is, my experience is - controlling QML compatibility
reliably is a world of pain.
Long story short:
I use a patched Qt(creator) that a) doesn't check versions (implicity
does "use latest"), and b) compiles QMLs in QRCs so it appends that
"latest" version numbers available to the binaries. If I compile with Qt
5.5, and people try to use it with <5.5 I'm on the mercy of the
forward-compatibility gods anyways.
As a developer, if I could, I would introduce a syntax that would either
abolish QML versioning altogether (or relegate it to the level of Qt
Versioning). Ideally, I'd like to see
import QtQml
import org.custom.plugin 1.3
forcing me to specify anything else does not help - by the time that
import QtQml statement is evaluated, I already compiled, linked and ran
a certain version of Qt. If I didn't check up to that point either on
the qmake or cpp level what I can do with that QtQml (and I need to be
compatible with something that is not latest-greatest), I'm doing it
wrong anyway.
Best regards,
Attila
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
