[Development] Question about Qt's future

Kevin Krammer kevin.krammer at kdab.com
Tue Apr 22 11:31:21 CEST 2014


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.krammer at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5918 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140422/3bbc8ee1/attachment.bin>


More information about the Development mailing list