[Development] QtQml value types

[Simon Hausmann]

On Thursday 24. April 2014 11.55.07 Roland Winklmeier wrote:
> Hi list,
> 
> we discussed the topic whether non-QObject types can be used in QML or not
> several times. The last time is only a few days ago as part of the Qt
> future discussions. So I had some thoughts what needs to happen to solve
> this issue.

Thank you for taking this out of the "future of Qt" thread (which seemed 
counterproductive). I wanted to do the same today :). I'm interested in 
contributing to the actual implementation of making it easier to use value 
types in QML. I'm aware of attempts from the past and I'm familiar with the 
current internal implementation. However it's not entirely clear to me yet 
what the presumably best way is for making it part of the public API.
 
> I can remember someone told me there are plans to add such a feature. So my
> first question is, how far are we on this? Is it just a plan or is someone
> really working on it already? Are there any details?
 >
> If there is nothing happening at the moment, I'd like to share some ideas I
> had during the last days.
>
> I'm not an expert in QtQuick/QML internals so I have no idea what might be
> possible or not. At the moment I assume only QObject derived classes can be
> used in QML contexts.
> 
> Charley's presentation (
> http://www.qtdeveloperdays.com/sites/default/files/presentation_pdf/QtDevDay
> sSFO-2013_WrappingCppForQml_final.pdf) was very interesting to me as I see
> this as a possible workaround until something more sophisticated is in
> place.
> During discussions in our team one of the members pointed me to internal
> class QQmlValueType (
> https://qt.gitorious.org/qt/qtdeclarative/source/HEAD:src/qml/qml/qqmlvaluet
> ype_p.h). This is used to make Qt value types like QSize, QPointF available
> through a QObject wrapper and is very similar to what charley presented.
> Now I wonder can't we just make this (or something similar) available as a
> public API? This would allow developers to add their custom types without
> much effort and would solve a lot problems.
> I don't think this is much effort but it will help a lot.

QQmlValueType is quite good in what it does. It could be that this is what we 
should be doing.

On the other hand for QtScript Kent came up with a solution that's strikingly 
beautiful at first:

    scriptEngine->setDefaultPrototype(qMetaTypeId<YourType>(), prototype);

It means that whenever a value type with the given meta-type ID enters the 
JavaScript world, the object that's being created to wrap the value will have 
the given object as prototype set.

That's incredibly powerful if you think about it, it even allows implementing 
functionality for value types in JavaScript itself.

Now the usability of this API depends on the availability of C-style function 
callbacks in QJSEngine in order to effectively allow wrapping in C++. That 
itself is something we've been hesitant about due to the way this exposes 
internals of the engine.

At the same time - even if we had C callbacks - we have to ask ourselves: 
What's the right data representation? For each operation, would we have to 
unpack a QVariant out of a QJSValue and then cast it to whatever the specific 
value type is?

Theoretically this is something that QQmlValueType solves, but in practice if 
you have for example a QPoint and code like this:

    var p = someObject.position;
    p.x = 42;
    p.y = 100;

Then the load and store from say variant is executed twice each.


It gets more complex when you consider that value types are semantically 
different in JavaScript. In the above example modifying p.x actually modifies 
someObject.position.x, i.e. someObject will probably move on the screen.


These are just some initial thoughts - there are many things to consider. It's 
one of the topics we should try to discuss at the Qt contributor summit. But 
perhaps until then we can come up with an intermediate initial solution here 
on the mailing list - flexible enough to allow for extension in the future.

Simon