[Development] Question about Qt's future

charleyb123 . charleyb123 at gmail.com
Mon Apr 21 19:28:24 CEST 2014


I'm not Roland (talking about "value-types"), but I completely agree with
his comments on why they are important (we have that issue also).

But, "jumping-in", ...

<snip, from Roland>,

> >> - Our application has a huge framework of value classes. They cannot
> (or
> > >> at least it does not make sense to) derive from QObject for several
> > >> reasons. But subclassing QObject is the requirement to access data
> from
> > >> C++ in QML. So we had our framework of well designed value classes and
> > >> cannot use them in QML. <snip>



> > The term value classes is due to history reasons in our project. We
> > started creating classes to handle physical values. Hence the name.
>
<snip>,

We call them, "deep/rich" types, sometimes "domain-specific-abstractions",
sometimes "value-types", sometimes "popcorn-types" (domain-specific values
that come-and-go, and typically comprise our API interfaces).

Kevin asketh:

> If you already have them as property values, what kind of operation do you
> need to do in QML that requires JS bindings for those objects?
>

The issue is that Real World Code almost always defines many "value-types"
that propagate through the interface.  They NEST.  That's the Big Deal
Thing(tm).  These typically define your APIs.  Those (existing C++) APIs
are EXACTLY what we want to (or "must") expose to QML.  The values
*themselves* are typically "properties", like those that you would want
exposed through QML.

For example, on our system:

  my_cytometer.laser.wavelength   // Yields "Wavelength" property

...In this case, none of "class Cytometer" nor "class Laser" nor "class
Wavelength" derive from QObject, but we want them exposed to QML.
 Including their nested properties.  Wrapping-or-deriving-from-QObject is
now required.  The "Wavelength" is literally an attribute of "Laser", which
is an attribute of "Cytometer" in existing code.  We need to expose to QML
all of them:  "QmlCytometer", "QmlLaser", "QmlWavelength"

When you have hundreds of classes like this, and their relationships define
your APIs (this is C++ and strong-compile-time-typing and that's what you
are SUPPOSED to do), and NONE of these are derived from QObject, it is now
"work" to figure out how to expose these to QML.

No, exposing a "long" or "double" is not sufficient (you MUST expose a real
"Wavelength-object" to QML.  It has "rules" in the class, such as for
forming/parsing strings, conversion to/from RGB, and QML needs to
*reference* specific "Wavelength" instances in the back-end-system (and
sometimes have a "value" of a "Wavelength" instance).

And actually, the "biggest-issue" is the NESTING:  The "Laser" is an
attribute of "Cytometer".  That granularity must be respected all the way
through to QML, because they comprise one-to-many and many-to-many in your
design (e.g., many "Laser" instances are on a single "Cytometer", but a
single "Laser" typically has a single "Wavelength", but sometimes more.)

> If I want to access this methods from QML I would have to derive them
> > from QObject and register it in the QML context.
>
> Not necessarily, depends on what you want to do.
> However, it is true that it would be nice to have something similar to
> QtScript's binding facilities.
>

Agree with Roland.  Must.  I MUST have "Cytometer" and "Laser" and
"Wavelength" exposed to QML.

In only the "simplest-of-toy-applications" could we pretend that a
"QmlCytometer" exposed to QML has a vector-of-double values to represent
the "several-wavelengths" that might be associated with that "cytometer".

In our system:  We code-gen to wrap everything.  "Wavelength" is now a QML
exposed property of "Laser", which is a QML exposed property of "Cytometer".

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


More information about the Development mailing list