任何使用 QML 的非 QObject 类的机会

Posted 2023-02-17

【中文标题】任何使用 QML 的非 QObject 类的机会

【英文标题】：Any chance to use non QObject classes with QML

【发布时间】：2013-10-11 19:13:40

【问题描述】：

从 Exposing Attributes of C++ Types to QML 开始，与 QML 一起使用的类必须是 QObjects。有没有机会我可以使用非 QObjects s（又名 POCO，不是源自 QObject，而是在 Qt 元系统中注册）？

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

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

【问题讨论】：

感谢您的支持！你有没有去过 Qt DevDays'13 可能是在上周（在柏林）？那我们就可以见面了！

感谢您的全面回答。我会把这个问题留几天，但可能会接受你的回答。顺便说一句，我不在柏林。

谢谢，我的邮件在个人资料中，我真的很想自己尝试一下（如果我有足够的时间的话）；所以，如果你愿意，我们可以尝试一些事情。柏林的活动很好:)

【参考方案1】：

这实际上是一个热门话题。

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

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

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

我会走这条路：

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

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

吊舱 列表 QObject 变体（不关注成员更改，iirc）