All geek questions in one place

Any opportunity to use classes without QObject with QML

By Providing C ++ Type Attributes for QML, the classes used with QML must be QObject s. QObjects any chance that I can use non QObjects (aka POCO, not derived from QObject , but registered in the Qt metasystem)?

If not, is there a simple general packaging system to make my QML objects compatible. I can think of adding dynamic properties to a simple QObject .

Or is there a way to implicitly convert to a QML-compatible type so that I don’t have to wrap at all?

+6
source share
1 answer

This is actually one hot topic.

I believe that you can register your own PODs and pass them around ito and inside the QML side (just like black boxes - without access to any member, you never tried this). To access the elements, you can use some get / set shell code, either in the form of methods on the same QML or on a descendant of QtObject, which effectively acts as a wrapper for each instance.

Dynamic properties are not currently supported - you can make them work, perhaps with a rather strange trick, but this is probably not worth it (but if you do not want to bind to properties, everything will be much simpler, and there will still be QObjects).

Implicit conversion would mean to have some kind of preprocessor (which is doable, probably will cost a lot of time, and the court to return the result to Qt (and maintain it for life)).

I would go as follows:

  • If the objects in question can be QObjects, measure performance (and if everything is ok, stick with it)
  • If not, try passing the opaque PODs by value, if it works, create guard forests and see if this / improves memory usage faster than the previous option
  • If property bindings are not required and dynamism is required, examine a) the nested QVariants b) the properties of the dynamic QObject
  • If maximum speed / memory requirements are required, consider writing a tool that automatically creates wrappers and connects it to the Qt project build pipeline.

The thing is, custom PODs do not enjoy the same level of support as the built-in, and standard language methods are built around manipulating garbage collected QObject instances (of course, passed everywhere with a pointer) that looked -for-changes the type properties:

  • Pod
  • list
  • QObject
  • (member changes are not visible, iirc)
+2
source

Source: https://habr.com/ru/post/955802/

More articles:


All Articles