On Monday, 2014-04-21, 11:28:24, charleyb123 . wrote: > ...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.
Right. As I wrote elsewhere a mechanism like the one available in QtScript would be benefitial. > > 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". What I meant was: what kind of operations in QML do need access to these compond types? For example in a widget based UI you wouldn't have a standard widget [1] that knows how to display or enter a Wavelength, right? You would have some adapter code that will take a Wavelength object and then process it into something a standard widget can handle. Why does the adapter code no longer suffice? Since I don't know about your data types let me try a different example. If I had the need to display width/height/depth of an image I would likely have a widget that has three labels or read-only spinboxes, neither of which can read the image properties themselves. So I would have adapter code that takes a QImage and accesses its width(), height() and depth() methods and put those into the widgets. As far as I can tell I could use the exact same adapter code if the UI was in QML. For additional declarative niceness I might be inclined to expose the wrapper in the form of a type with an image property for input and three appropriately named integer properties for output. But the actual adapter code would be the same. Cheers, Kevin [1] Custom widget would be in the same boat as custom item, so that obviously can always deal with domain specific types. -- Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates! Kevin Krammer | kevin.kram...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development