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