[Development] The place of QML

alan.alpert at nokia.com alan.alpert at nokia.com
Wed Apr 25 06:31:40 CEST 2012



>From: development-bounces+alan.alpert=nokia.com at qt-project.org [development->bounces+alan.alpert=nokia.com at qt-project.org] on behalf of ext d3fault [d3faultdotxbe at gmail.com]
> Sent: Monday, April 23, 2012 9:33 PM
> To: development at qt-project.org
> Subject: Re: [Development] The place of QML
>
>
>I don't think Lars emphasized this enough, but QML is *not* JS. In fact, the JS engine is only used when you have >non-trivial bindings. The  rule of thumb is that you have to really write code that looks like JS in order to have it >interpreted by V8. So if
>you use it the same way as a .ui file, the performance characteristics are almost the same too. For example:
>
>
>
>Rectangle {
>    x: 10
>    y: 10
>    width: 10
>    height: 10
>}
>
>This is the level of functionality that UI files provided, and it didn't need JS. Well, it still doesn't. That QML code >isn't going to run anything through V8. The QML engine is smart enough to just assign the values and not >bother using a JS interpreter. You end up with a C++ object instantiated, and with some properties set, which is >exactly what .ui files did. So if you compare this to a .ui file, the only difference is that it is being compiled when >you load the component instead of during the compile phase. Oh, and it's easy enough to write by hand as well >as with the visual designer.
>
>I understand that run-time compilation is a concrete performance cost for a static UI, and we're looking into >ways of storing the compiled output so that you can just load bytecode to initialize objects (for the same >performance characteristics as a .ui file). But so far our performance metrics show that the compile time is >minuscule for QML applications and so it's not high enough on our priority list for what to optimize. Patches are >welcome though :) .
>
>It doesn't go through v8? Cool, so why are we forced to use/ship v8 (Rhetorical. I know why: it's for the few who >write their app logic in JS -_-)? Your last paragraph peaked my interest. It would be a good compromise and >would get me to shut up. I would be
> happy with QML if it was only used during the pre-compile/compile stage (move the js interpreter into the >toolchain lol idgaf). For all those who want to write their logic in js (grossssss), maybe have a QT += >jsinterpreter option. Your performance metrics
> don't indicate a significant value, but they probably don't take into consideration costs such as added library >size (mostly affects windows developers) or memory consumption. The 'concrete performance cost' of run-time >compilation is unnecessary in principle
> (regardless of how insignificant it is)... which is why we don't want it.


Your 'rhetorical' question is actually a valid one that has a better answer than you provided. In fact, you probably shouldn't be forced to use V8 if you don't use it. Your gripe isn't with the QML language, it's with our current implementation - which is in continuous development despite already being highly useful.

I can see it as a viable future direction that you can run QML with v8 disabled. You wouldn't even need to link against V8, and any binding which would require V8 to evaluate it produces a compile time error instead. Add that feature to the separate compiler so you can compile QML in the compile phase, and just pass bytecode to your QmlComponent, and then you've pretty much got everything you wanted, plus QML. Which I know you'll all learn to love ;) .

The thing with limited resources is that we don't have time to implement those features right now (they're a lot of work). And for us they are not a priority, so at the very least I don't see my time being allocated to implementing this any time soon. A key point in meritocratic governance structures is that resource allocation can define timetabling, so if you submitted the patches soon then I could see this feature getting into Qt 5.1 (assuming the patches get through the peer-review process of course). Summary: "I look forward to your patch :) ".

>Yes yes, tons of work... tons of maintenance... I get that. But it's better I bitch now than later (after more code >has been written).

I'm not sure that bitching is ever the 'better' option... and if you don't think it's worth your time, why is it worth mine?

>tl;dr:
>
>QML-like C++ Front-End to QtQuick (like Ivan described)

I should probably look at that actual thread, but I have no idea how a C++ API could produce the binding for parent.size - unless we make moc insert a JS VM for runtime processing ;) .

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks














More information about the Development mailing list