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

Attila Csipa qt at csipa.in.rs
Wed Jul 4 10:17:49 CEST 2012


On 07/04/2012 10:17 AM, d3fault wrote:
> Lorn, so you think it should be allowed that Qt Modules are not 
> interoperable?
>
> Also, did QML in the Trolltech days have javascript hacked on and 
> forced-JIT in the design? There's a 3rd option that I intentionally 
> didn't mention that is actually a sensible home for QML: .ui file 
> replacement. Currently QML depends too much on itself to be a .ui file 
> replacement. There is no C++ equivalent of much of the functionality 
> in QML, whereas everything you can do in a .ui file, you can do in C++.
>

This is a bit of a red herring. You can do everything in the .ui you can 
do in C++ exactly because there is not that much you can do with it. You 
can have a fully static QML (without any JS) for the same purpose, but 
that would make no sense - that would be just syntax switching from XML 
to JSON without any functional benefit. Interoperability is of course 
very important, but it's really not about "we will intentionally make it 
suck", but rather that some things are easier to expose to the C++ side 
than others. Long before declarative we had QtScript and QtWebkit which 
were - in those days - even less interoperable, but perhaps they were 
not as cool, so the sour grapes syndrome didn't kick in :) Yes, one 
might have personal preferences regarding the language choice and how it 
interfaces with the rest of Qt, but that doesn't invalidate the concept. 
You're not forced to use QML, it's just that for some tasks it's the 
easiest (and thus recommended) way to go.

Attila



More information about the Development mailing list