[Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

d3fault d3faultdotxbe at gmail.com
Wed Jul 4 05:46:24 CEST 2012


QML is not interoperable with Qt/C++.

It claims to be interoperable, but it's really not.

QML can access everything from Qt/C++ (usually requires glue code), but Qt
cannot access everything from QML.

Examples:
a) Qt Graphical Effects
b) QML Desktop Components
c) [more to come, no doubt]

^every time a new piece of QML-exclusive functionality is announced and
touted as "Qt functionality", the divide in the community grows.

QML is ruining Qt's good name by introducing a "toy programming language"
mode and splitting the community in half by making new framework features
exclusive to that TPL mode.

QML is a _user_ application of Qt. It is a powerful product, potentially
profitable, and the users of it can even use Qt/C++ behind the scenes.
However, it does not belong in the Qt code base (perhaps as an Add-On?).

The IEEE defines 'interoperability' as:
"the ability of two or more systems or components to exchange information
and to use the information that has been exchanged."
The definition of 'exchange':
"An act of giving one thing and receiving another in return" <-- just
wanted to point out that the exchange in interoperability is two ways
QML only uses functionality that Qt/C++ provides. QML specific
functionality is inaccessible from Qt/C++.
Therefore, QML is not interoperable with Qt/C++ and should not be in Qt's
code base.

Another way of thinking about this: Imagine Nokia was pouring resources and
functionality directly into the python bindings (instead of upstream) and
then claiming the python bindings were "Qt". Oh, you like C++? You like
native? Too bad, now you have to use python if you want any of the new
functionality.

Now let's get out our conspiracy theory watches (so we can see how much
time we waste speculating): It's plausible that Microsoft directed Nokia
into purchasing Trolltech with the sole intentions of segregating the
community (divide and conquer) in the way described above. It makes me
giggle when people respond saying "The Nokia employees are devoted to Qt!".
I don't question their devotion for a second (the code monkeys working at
Nokia are on my team as far as I'm concerned)... but at the end of the day,
they do what they're told to do by the guy who writes their paycheck. Qt
in-house developer's boss: Nokia. Nokia's boss: Microsoft. The only
question that remains: does Microsoft play that dirty? (hint: yes). I hate
repeating myself (I do it often), but for anyone who can't figure out why
Microsoft would dislike Qt: Microsoft's primary revenue source is operating
system sales. They do so well with operating system sales because of their
use of vendor lock-in tactics. Applications made for Windows tend to not
work on other operating systems. Qt is changing that. Qt is platform
independent, as powerful as (if not more powerful than) Microsoft's .Net
lineup, with the added advantage of being 100% native. Qt is the biggest
threat to Microsoft's long-term survival.


So with all the noise that I'm making, QML is making more. Not only that,
it's siphoning resources and splitting the community in half.

d3fault

p.s. re: me not having any merit
>From http://qt-project.org/wiki/The_Qt_Governance_Model
"Decisions about the future of the Project are made through mailing list
discussion with the members of the community, from the newest User to the
Chief Maintainer."
That being said, I expect to be ignored because the vast majority of
contributors/deciders work within Nokia (and can't speak freely because of
it (they can still speak against the motion though. anyone else see the
problem with that? LOL 'Open Governance')). We'd need a lazy consensus
among 3rd party contributors beating out Nokia employees voting against...
and then we'd have to hope the Maintainers/Chief Maintainer doesn't
override the decision. Never going to happen. Fork sounds easier... but
that splits the community as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120703/000c1a38/attachment.html>


More information about the Development mailing list