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

Shawn Rutledge shawn.t.rutledge at gmail.com
Wed Jul 4 10:26:03 CEST 2012


On 4 July 2012 09:17, d3fault <d3faultdotxbe at gmail.com> wrote:
> 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++.

Personally I do agree with you that Javascript should not be so
mandatory.  Ideally it should be possible to do a couple of these:
- use a different scripting language
- instantiate Desktop Components from C++
- convert JS to bytecode and ship an app with bytecode rather than
source (but V8 reputedly cannot support this)
- save the output of the JIT so that at least the source doesn't have
to be recompiled every time
- compile qml and JS to native code

At least there is a decent chance the last one might happen.  Then we
could truly say QML is a ui file replacement.  Because AFAIK it has
been more common to run uic at build time rather than to actually ship
the UI files.  The existence of this form of declarative language is
an improvement over XML UI files (which basically couldn't be written
by hand)

QML is itself quite a simple language, if we leave out the possibility
of using JS handlers; maybe it wouldn't even be too hard to write a
qmlc which generates C++ code as long as one doesn't rely on any JS
language features (or by bundling the JS snippets somehow).  I haven't
tried though; has anyone else?



More information about the Development mailing list