Any chance to use non QObject classes with QML

半腔热情 提交于 2019-12-03 14:43:16

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)
标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!