[Development] Design review: Adapter layer, C++ to QML

Charley Bay charleyb123 at gmail.com
Wed Jan 30 21:35:54 CET 2013


Hi, Alan--

charley:
> > I've implemented a C++ "adapter-layer" (mostly template-based) to expose
> C++
> > objects to QML. <snip>,
>


> Sounds like this is for developers using Qt, not working on Qt.

qt-interest is the correct ML for that (although given the youthful
> state of QML, this could also suggest improvements to QML later. But
> we can worry about that later).
>

Agreed -- although I'm tentatively suggesting the Qt-proper libraries offer
this API layer natively (in the Qt distribution), as I'd assume most users
with heavy C++ libs would need it.  Still, your point is valid, so I can
move lists with this discussion (if there's insufficient interest here).

> ----------
> > Design goals:
> >
> >  (a)- Expose individual C++ objects with minimal code
>
> There are other related goals that could be involved in the C++/QML
> adaption layer. The last generator script I wrote for this (
> http://alan.imagin-itis.net/?p=166 ) was about non-Qt C++ code (with a
> GUI focus), but I assume you're talking about exposing QObject
> subclasses in a Qt project from the start.


Your generator script didn't focus on the "instance-hierarchy" exposed to
QML, and that's what I'm focused on.  (I like your generator idea, but much
of our code likely requires manual consideration of what properties and
instances are exposed.)

Further, no, I'm talking specifically about exposing a massive amount of
C++ classes to QML, within instance-hierarchies, when none of those C++
classes derive from QObject.


> >  (b)- Individual "QML-instances" can "contain" a "C++ back-end-instance"
> > that is not shared with other QML instances.
>
> Is this just creating a subclass with Q_PROPERTY macros?
>

The C++ instance has the "reference-state", and the QML instance merely
"wraps" it.  The QML/GUI cannot instantiate the "reference" instance (the
C++ back-end model manages all that).

Further, with this design, no QML instances are "temporarily-created" to
access a property.  Rather, they always exist as a wrapper to the C++
instance, or they don't (it's the same QML instance each time properties
are extracted from that C++ object).


> >  (c)- Multiple "QML-instances" can "share" access to the same C++
> back-end
> > instance, with coordinated updates (e.g., as one QML-instance triggers a
> C++
> > object "property-value-change", all QML instances are "notified" of that
> > change)
>
> Perhaps you should just be using the new QML Singleton type, used like so:
>
> MyType.myProp = foo; //Engine creates an instance of the C++ type
> first time MyType is used, all references use that instance.
>

The QML model cannot instantiate the back-end C++ instances (they correlate
to hardware managed by a back-end-model).  Rather, we only want QML to
"reflect" whatever the model is doing.

>  (d)- Enable nested QML-wrapped-object-access to nested C++ instances that
> > are natively stored (e.g., no refactoring of C++ code to incrementally
> > expose nested C++ objects to QML)
>
> I don't understand what you're saying here. Do you mean that adding a
> QML adaption layer requires no changes to the backing C++ class?
>

Yes:  The QML adaptation layer requires no changes to the backing C++
classes.  Further, we require a deep-object-instance-hierarchy of wrappers
for the deep-hierarchy-of-C++-instances.


> > <snip>,
> I'm not sure why you needed the multiple QML instances <-> single C++
> instance thing in the first place. Even in Qt 4, you can have a single
> C++ instance that's exposed but as an uncreatable type. Just put that
> in your root context as myInstrument and you're good to go.
>

We will have a (C++) "Detector" object with many properties, and there will
be many GUI/QML "views" into that detector (it appears in the
list-of-all-detectors, on a graphical drawing of the instrument
configuration, in the list of saved/collected parameters, in the list of
all-filters used, etc.)  In all these cases, there is a
"GUI-representation" of something, and the "Detector-properties" are what
we want exposed:  Voltage, filter, QC-status, fluorochrome, laser, etc.

So, logically, a single "Detector" instance is implicitly displayed in many
different ways in many parts of our GUI.  Each "display" can be different.
 All of them must reflect the state of the *specific*
back-end-C++-instance.  With this current implementation, the properties
exist in a single place -- the back-end C++ object.


> The idea of conveniently exposing sets of objects with
> QAbstractListModel like behaviour is interesting, but I don't think it
> should be mixed up with the exposing single instances question. We
> already had a thread on improving QAbstractListModel's utility in QML,
> which I think is a more promising approach.
>

I'm very interested progress on, "improving QAbstractListModel's utility in
QML".  I don't have specific needs.  However, my specific implementation is
a utility (template) base class derived from QAbstractListModel that
*demands* the derived type implement an "enum" for the "roles" for
extracting properties.

So, my "list-model" implementation is merely a utility convenience thing so
that creating a "model" of things requires:

  (1) Derive from utility model-base class
  (2) Implement enum-for-roles
  (3) Implement function to get a QVariant from the enum-role.

The utility base class handles notifications, add/insert/remove, etc.  (I
don't want to do that for each model implemented).

>  (3) Have I missed similar approaches that already exist, which we could
> > otherwise use directly?
>
> Yeah, you might just want to use qmlRegisterSingletonType (new in Qt 5).
>

Because we have much C++ code, and it's tied to hardware and other system
configurations:

  (a) QML cannot instantiate most "important" classes, and these are not
singletons (there might be zero, one, or possibly more than one)

  (b) QML should "reflect" state from the back-end model that does not
derive from QObject nor use signals/slots

  (c) QML/GUI must "reflect" many "views" of specific back-end state

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130130/75885ce7/attachment.html>


More information about the Development mailing list