[Development] The place of QML

[d3fault]

Ivan Cukic ( http://qt-project.org/forums/viewthread/16465/P15 ):

> (just pulled the last quote regarding C++ and UIs, not replying to that
> post)
>
>> C++ is very capable of creating UIs in a declarative way, it is just that
>> QWidgets are not implemented with that kind of API. One could create an
>> API that would allow this to be a valid C++ code:
>>
>>    1. window (
>>    2.     name = "winMain",
>>    3.     button (
>>    4.          name = "buttonBig",
>>    5.          size = parent.size,
>>    6.          title = "Click me!",
>>    7.          onClicked = something
>>    8.     )
>>    9. )
>>
>>
I agree that it's not a wise idea to expose directly the QtQuick back-end.
What we want instead is a C++ front-end to interface with it (like above).
If you look at the above code that Ivan posted, it looks incredibly similar
to QML.

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.
>

.ui files don't require a JS Interpreter/VM to load

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.
>

A minimalist purist would be more like it. Minimal not meaning I want to
write everything in binary/assembly (or write my owner parsers -_-)... but
minimal in that I want to write the least amount of code for the most
amount of functionality. Additionally, I want to ship my software with the
minimum amount of support packages. I don't deem a JS Interpreter/VM to be
necessary. Think of all the Windows developers that now have to include v8
in every application they distribute. Sure, on a real OS there are system
libraries... but Windows developers (a huge part of Qt users) typically
have to ship the Qt libs (and now v8) with every app they release.

I love MOC because it is done at the pre-compiling stage. I would
absolutely hate MOC if it had to be run every time a user wanted to run my
app.

You're also not complaining that we have PCRE as a backend to implement
> regular expressions.
>

The difference being you aren't forced into using the PCRE just for basic
(modern) GUI functionality (regardless of whether you even use Regular
Expressions). If I don't write my logic in javascript (which I won't), I
still have to ship a javascript interpreter. PCRE is opt-in.


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.

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).

tl;dr:
QML-like C++ Front-End to QtQuick (like Ivan described)
OR
Pre-Compile QML and only ship bytecode in binary for QtQuick use
plox

d3fault


On Mon, Apr 23, 2012 at 1:59 AM, Alan Alpert <alan.alpert at nokia.com> wrote:

> On Mon, 23 Apr 2012 17:35:02 ext lars.knoll at nokia.com wrote:
> > On 4/22/12 9:14 AM, "ext d3fault" <d3faultdotxbe at gmail.com> wrote:
> >
> > >...
> > ...
> > >To quote Lars,
> > >
> > >We want to make the usage of Javascript supported as well as C++ is
> > >supported. We are not making it the superior way or even the only way.
> > >
> > >
> > >...except that the javascript way currently is the superior way. If you
> > >want a hardware accelerated UI (without hacking together your own...
> > >defeating the purpose of using a UI toolkit), you are forced to use
> > >javascript (QML).
> >
> > No, you should be using QML. That doesn't imply that you have to write
> any
> > application logic in Javascript. As I said, use it as a better .ui
> > language. You can still do all your app logic in C++ if you so want.
>
> 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 :) .
>
> > 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.
>
> I can see the non-zero value in exposing the Rectangle element. It's
> pretty much equivalent to QGraphicsRectItem then. I don't
> know about you, but I didn't find QGraphicsRectItem very useful at all. In
> a C++ graphics scene, it wasn't worth the bother to
> compose images out of multiple QGraphicsRectItems. That approach was
> cumbersome and inflexible compared to implementing your own
> QGraphicsItem and just painting a rectangle in paint(). Note that with
> QQuickPaintedItem, you can do the exact same thing with
> scenegraph today (well, on the day Qt5 is released ;) ) just take your
> QPainter* and go to town. Or use QQuickItem and paint it
> using scenegraph or GL directly, to truly get the sort of hardware
> acceleration and speed that requires custom C++ code. (NB:
> after writing your super-fast C++ native object you can then use QML to
> instantiate it and set initial properties, if that appeals
> to you.)
>
> This is one of the main reasons we aren't exposing the elements to C++.
> The value for providing these elements in C++, compared to
> you doing your own painting in C++, is very ill defined. It's not zero,
> but there is a large cost in the limitations we have when
> we make an API public. Remember that if we change it to expose the C++
> API, at even the tiniest expense of the QML API, the C++
> haters will come crawling out of the woodwork with unbridled rage. So
> exposing it to C++ directly provides a very large cost for
> very little gain (that I can see). We shouldn't expose it to C++ until we
> have a good and highly useful C++ API at minimal cost to
> the QML API, otherwise we'll not be able to release such an API until Qt
> 6. I don't know if I'll live that long.
>
> Consider also the current "C++ API" for QtQuick. You can create any
> QtQuick component in C++ and position it with code like the
> following (exercise for the reader, write the equivalent code for
> QGraphicsView and compare):
>
> QQuickCanvas canvas;
> QQmlEngine engine;
> QQmlComponent component(&engine);
> component.setData("import QtQuick 2.0; Rectangle{}");
> QQuickItem* item = qobject_cast<QQuickItem*>(component.createObject());
> item->setX(10);
> item->setY(10);
> item->setWidth(10);
> item->setHeight(10);
> item->setParent(canvas);
> canvas.show();
>
> I think that code is pretty bad. The only material difference to the above
> ugly code that we'd get by exposing the C++ API as it
> stands would be to replace the three component lines with QQuickRectangle*
> item = new QQuickRectangle; I really don't think that's
> good enough to compete even with a stagnating QGraphicsView - which is
> still available (and can be maintained if anyone really
> wants that, as defined by providing patches). Since we have QGV still, it
> also doesn't make sense to just copy it.
>
> Honestly, I think that
> component.setData("import QtQuick 2.0; Rectangle{ border.color: 'green';
> color: 'fuchsia'; width: 120; height: 120;}");
> is already a little nicer than the QGV equivalent of
> rectangle->setPen(QPen(Qt::green));
> rectangle->setBrush(QBrush(QColor("fuchsia")));
> rectangle->setGeometry(0,0,120,120);
> Especially if you're going to have it all on one line like I do ;). I'm
> not a paragon of coding style though, and that's a highly
> subjective point.
>
> The real point is: Is it such a C++ API really that valuable? Do you want
> a C++ API just like QGraphicsView? If so, why aren't you
> happy with QGraphicsView? If not, perhaps you can help us find the perfect
> C++ API for QtQuick so that we can finally expose it?
>
> --
> Alan Alpert
> Senior Engineer
> Nokia, Qt Development Frameworks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120423/edc3e53d/attachment.html>