[Qt5-feedback] C++ api to use for UI in addition to QML

[Alan Alpert]

On Wed, 18 May 2011 06:05:38 ext Richard Moore wrote:
> On Tue, May 17, 2011 at 2:00 AM, Alan Alpert <alan.alpert at nokia.com> wrote:
> > You can't find an item by id from C++, it's a detail internal to the QML
> > engine. ObjectName will continue to work in Qt 5 though.
> 
> For some reason, you seem to be under the impression that using
> findChild in order to interact is a good API. Please could you explain
> this? It's very clear that many users would like to make use of parts
> of QML (for example basic widgets) but don't want to move to QML
> completely - this makes complete sense, since QML seems to be targeted
> at small, flashy UIs. Surely it is obvious that a better way of
> interacting with QML from C++ is a basic requirement for adoption in
> non-trivial applications?
> 
> > In fact, QML 2.0 should have a very similar C++ API to QML1.x (because we
> > expose so little of it). You will be able to instantiate QML scenes with
> > components, and use the meta object system for introspection. It would
> > help if you provide more detail than 'interact with'. What's missing
> > from the QML 1.x C++ support that you want (keeping Thiago's points in
> > mind, as he is entirely correct) ?
> 
> I'd like to be able to write code using the QML based widgets in a
> similar way to the way I can currently do so with QWidgets. ie. Use a
> pre-built component set from C++ by instantiating and interacting
> directly with the widgets.
> 
> I'm not anti-javascript - I wrote the KDE javascript binding, but this
> is seeming like you plan to port the flaws of the current design to
> the new code base.
> 

We plan to port the design of the current design to the new code base. This 
design neither expects you to use findChild all the time, nor write code the 
same way as you did with QWidgets. The reasoning is that all the things you 
want to do the QWidget way, i.e. myWidget->setTextLabel(itemLabelKappa), can 
be done as easily or better in QML. Setting properties, geometry and 
animations for example are all things that QML is intended to be better at 
than the C++ widgets approach.

This is why the QML design has you expose the variables to QML, through an 
application object for example, and then setup all the bindings in QML. This 
requires no pointers to the individual QML items, as they receive all of their 
setup instructions in the QML files. This does not use findChild, and I don't 
see why it won't scale to any application size (although you may need to 
organize the exposed properties better than all on a single QObject).

The weak spot that I can see is for the specific use-case of replacing a single 
widget with a QML component. You can't use the same style of commands and it's 
cumbersome to expose a QObject for every widget. I have my doubts as to how 
realistic this usecase is though. In the switch to Qt5, you are not likely to 
port a single widget over at a time to QML. More probable is that you stick 
with widgets until you have time to redo it with a QML-from-the-start UI, or 
you replace whole sections (of multiple related widgets) at a time. In both 
cases, exposing a QObject should work fine. If I'm wrong an that usecase is 
common in reality, we should look into some convenience that eases the 
cumbersome burden of creating and exposing large numbers of QObjects for their 
properties.

> > Another thing to keep in mind is that you won't have to write Javascript
> > to use QML. Qt Creator has a QML design view that you can use, and then
> > everything gets hooked up like it used to be with .ui files. Except with
> > greater customization and more animations. With Qt 5, you will be able
> > to create UIs without 'writing' QML, just by using the tools.
> 
> I can do that with flash. I'm hoping for something more.
> 

The 'more' is that you can invoke C++ methods from it. Whereas with flash you 
can hit the limits of its capabilities and be stuck without a fall-back.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks