任何使用 QML 的非 QObject 类的机会 [英] Any chance to use non QObject classes with QML

问题描述

截至 向 QML 公开 C++ 类型的属性 与 QML 一起使用的类必须是 QObjects.我有没有机会使用非 QObjects (又名 POCO，不是从 QObject 派生，而是在 Qt 元系统中注册)?

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)?

如果没有，是否有一个简单的通用包装系统来使我的对象符合 QML.我能想到的一种方法是将动态属性添加到一个简单的QObject.

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.

或者有没有办法隐式转换为符合 QML 的类型，所以我根本不需要包装?

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

推荐答案

这其实是一个热门话题.

This is one hot topic actually.

我相信您可以注册自己的 POD 并将它们传递给 ito 和 QML 端(就像黑盒子——没有任何成员访问权限，从未尝试过).要访问成员，可以使用一些 get/set 包装器代码，或者以 QML 单例上的方法形式，或者在 QtObject 后代上有效地充当每个实例的包装器.

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.

目前不支持动态属性——你可以用一些非常奇怪的技巧让它们工作，但这可能不值得(但如果你不想绑定到属性，事情会变得简单得多，它仍然是 QObjects).

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).

隐式转换意味着有某种预处理器(这可能是可行的，但会花费大量时间，并且需要将结果提交回 Qt(并终生支持它)).

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)).

我会走这条路:

• 如果有问题的对象可以是 QObjects，测量性能(如果没问题，坚持下去)
• 如果不是，请尝试按值传递不透明的 POD，如果可行，则创建包装脚手架，并查看它是否比以前的选项更快/提供更好的内存使用率
• 如果不需要对属性的绑定，并且需要动态，请研究 a) 嵌套 QVariants b) 动态 QObject 属性
• 如果应满足极高的速度/内存要求，请考虑编写一个自动生成包装器并将其连接到 Qt 项目构建管道的工具

问题是，自定义 POD 无法享受与内置 do 相同级别的支持，并且标准语言实践是围绕操作垃圾收集的 QObject 实例(当然，通过指针到处传递)而构建的，-for-changes 类型的属性:

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
• 列表
• QObject
• 变体(不关注成员更改，iirc)

这篇关于任何使用 QML 的非 QObject 类的机会的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！