[Development] QtQml value types

[Dominik Holland]

Am 24.04.14 12:46, schrieb 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);

I like that idea, but couldn't we do something like this ?

qRegisterWrapper<MyWrapper>(qMetaTypeId<YourType>())

MyWrapper is a QObject based class which can whatever you want and gets 
YourType as reference or per value.

It would mean you create your wrapper once for all your Types of your 
Interface and afterwards the QmlEngine will create the Wrapper 
automatically for every object which is exposed to QML.

I could also think of having some automatically created wrappers for 
QList<YourType>.


The wrapper itself gives you the flexiblity to decide whether you can 
support changedSignals of what functions you want to expose to QML.

In the end it would also be great to register the Wrapper as a own QML 
Type to be able to create the object in QML.

Dominik

> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development