[Development] The place of QML
lars.knoll at nokia.com
lars.knoll at nokia.com
Mon Apr 23 09:35:02 CEST 2012
On 4/22/12 9:14 AM, "ext d3fault" <d3faultdotxbe at gmail.com> wrote:
>Yes, it is strongly biased due to the wording. Fix the wording and post
>it anyways. The numbers will not change.
>I got bored and drew a pretty picture to summarize my feelings for QML:
>Hope you laugh.
>But back to being serious. How can anybody in the QML camp argue against
>this: Modern, Hardware Accelerated GUI Defining/Declaring/Creation does
>not require QML/JS Interpreter/Virtual Machine.
>It's like these genius' (QML/QtQuick is still brilliant) got so caught up
>with what they were working on that they forgot the big picture: Hardware
>Accelerated C++ GUI. Forcing the use of a declarative language, a JS
>Interpreter, and a virtual machine just makes most of us want to stab
>ourselves in the eye out of principle (our principles differ from yours).
And who says that 100% of the code has to be C++? I bet you are also
happily using Perl/python where it makes sense. .ui files in Qt 4.x are
XML, yet nobody complains about these.
Qt is about finding pragmatic solutions to problems. Yes it comes from a
C++ heritage, but I don't see why we should limit ourselves to purely C++
if we can create better solutions to the problem.
This complaining sounds a bit like all the C++ purists that think Qt is
bad because it includes a code generator (moc) for signals/slots and
properties. Yet they all happily use tools like flex and bison and don't
write their parsers by hand.
>To quote Lars,
>supported. We are not making it the superior way or even the only way.
>want a hardware accelerated UI (without hacking together your own...
>defeating the purpose of using a UI toolkit), you are forced to use
No, you should be using QML. That doesn't imply that you have to write any
language. You can still do all your app logic in C++ if you so want.
When you ask for simply exposing all a C++ API to all QML items, you're
missing a point. QML is a language that include states&transitions and a
binding engine. The binding engine works on arbitrary expressions and
needs some backend to evaluate these. That backend happens to be V8.
I don't see a problem with that. You're also not complaining that we have
PCRE as a backend to implement regular expressions.
We are already exposing most of the the C++ APIs that make sense for
application developers to use. Simply exposing the C++ interface of all
QML elements won't buy you anything, as the most important feature of Qt
Quick (bindings) still can't be handled that way.
There's zero value in exposing the C++ class that implements the QML
Rectangle element. There's nothing you can really do with it anyway. If
you need to create your own QML elements in C++ we have QQuickItem and
QQuickPaintedItem, which form a very good and solid basis.
And as others already pointed out, we need to be careful as to what we
expose in C++. Any API we add comes at a large cost (that you probably do
not see) in terms of maintenance and limitations to what we can change
because of binary compatibility.
>On Fri, Apr 20, 2012 at 3:59 PM, <marius.storm-olsen at nokia.com> wrote:
>That's a strongly biased poll due to the wording. And it's missing the
>points the Lars has been trying convey, but some seem to ignore.
>Sent from my Nokia N9On 4/20/12 17:31 ext d3fault wrote:
>Does Qt need a modern C++ GUI API?
>machines, glue code, glue abstract and proxy object
>-Yes, I¹d like the option of 100% native development without being left
>behind with a last century GUI API
>Can someone put that poll, or at least a link to it, on the front page of
>Development mailing list
>Development at qt-project.org
More information about the Development