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

[Daniel Kreuter]

On Tuesday, July 03, 2012 08:46:24 PM d3fault wrote:

> 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.


While reading your post it seems, you didn't work with QML yet, did you?

Try to solve a problem using QML and then try to solve the same problem with 
QWidgets, f.e. take a multimedia application with fancy animations. You will 
realize that it would be much harder in QWidgets than using QML and you will 
need more lines of code in C++ to do just the same as in QML.

And when you can make it in QWidgets and the performance etc is much better 
than in QML (which I suppose won't be the case and if so, it would be hard to 
maintain code in QWidgets) then you can come back here and complain about to 
remove QML from Qt's code base.

And the interoperability you describe, I don't get your point here. I'm using 
QML at work and I'm able to communicate with my Qt code and vice versa without 
any big struggle. Works just fine as if it was native.

My 2 cents.

Daniel