>From: development-bounces+alan.alpert=nokia....@qt-project.org
>[development->bounces+alan.alpert=nokia....@qt-project.org] on behalf of ext
>d3fault [d3faultdot...@gmail.com]
> Sent: Monday, April 23, 2012 9:33 PM
> To: development@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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
