Any chance to use non QObject classes with QML

6
votes

As of Exposing Attributes of C++ Types to QML classes used with QML have to be QObjects. Any chance I can use non QObjects s (aka POCO, not derived from QObject, but registered with Qt metasystem)?

If not, is there a simple generic wrapping system to make my objects QML compliant. One I can think of is to add dynamic properties to a simple QObject.

Or is there a way to implicitly convert to a QML compliant type so I do not need to wrap at all?

1
c++qmlqobject
Thanks for upvoting! Have you been to Qt DevDays'13 may be on the last week (in Berlin)? Then we could have met! – mlvljr
Thanks for the comprehensive answer. I'll leave the question open for some more days, but then likely accept your answer. I was not in Berlin, btw. – Horst Walter
Thanks, my mail is in the profile, and I actually feel like trying to experiment on this a bit myself (if I get enough time) soon; so, if you wish, we can try some things out. The Berlin event was nice :) – mlvljr

1 Answers

2
votes

This is one hot topic actually.

I believe you may register your own PODs and pass them around ito and within the QML side (just as black boxes -- w/o any member access, have never tried that). To access the members, some get/set wrapper code could be used, either in form of methods on a QML singleton, or on a QtObject descendant effectively serving as a per-instance wrapper.

Dynamic properties are not currently supported -- you can make them work probably with some quite weird trickery, but it will not probably be worth it (but if you don't want to bind to properties, things will get much-much simpler, and it still will be QObjects).

Implicitly converting would mean having some sort of preprocessor (which is doable probably but would cost lots of time, and a sudecution to submit the result back into Qt (and support it for life)).

I'd go this way:

  • if objects in question can be QObjects, measure the performance (and if it's ok, stick with it)
  • if not, attempt passing opaque PODs by value, if it works, create wrapper scaffolding, and see if it's faster / gives better memory usage than the previous option
  • if no bindings to proerties are needed, and dynamism is required, investigate a) nested QVariants b) dynamic QObject properties
  • if extreme speed / mem requirements should be met, consider writing a tool that auto-generates wrappers and hooking it into the Qt project build pipeline

Thing is, custom PODs don't enjoy the same level of support the built-in do, and the standard language practices are built around manipulating garbage-collected QObject instances (passed everywhere by pointer, of course), which have watched-for-changes properties of types:

  • POD
  • list
  • QObject
  • variant (not watched for member changes, iirc)