[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