在 Python 中使用自定义 Qt 子类
首先：我对 Qt 和 SWIG 都是新手。目前正在阅读这两个文件的文档，但这是一项耗时的任务，因此我正在寻找一些剧透。预先知道某件事是否行不通是件好事。
我正在尝试为一些内部软件制定模块化架构。核心组件采用 C++ 语言，并通过 SWIG 暴露给 Python，以便进行新组件的实验和快速原型设计。 Qt 似乎有一些类我可以用来避免在这里过多地重新发明轮子，但我担心其中一些部分如何组合在一起。
具体来说，如果我创建一些 C++ 类，我需要通过 SWIG 公开它们。其中一些类可能是 Qt 类的子类，或者在其公共接口中公开了 Qt 内容。这似乎可能会引起一些并发症。
Python 中已经有两个 Qt 接口：PyQt 和 PySide。出于许可原因可能会使用 PySide。我希望让 Qt 类的 SWIG 包装的自定义子类与其中任何一个很好地配合，会有多痛苦？我应该预先了解哪些并发症？
First off: I'm new to both Qt and SWIG. Currently reading documentation for both of these, but this is a time consuming task, so I'm looking for some spoilers. It's good to know up-front whether something just won't work.
I'm attempting to formulate a modular architecture for some in-house software. The core components are in C++ and exposed via SWIG to Python for experimentation and rapid prototyping of new components. Qt seems like it has some classes I could use to avoid re-inventing the wheel too much here, but I'm concerned about how some of the bits will fit together.
Specifically, if I create some C++ classes, I'll need to expose them via SWIG. Some of these classes likely subclass Qt classes or otherwise have Qt stuff exposed in their public interfaces. This seems like it could raise some complications.
There are already two interfaces for Qt in Python, PyQt and PySide. Will probably use PySide for licensing reasons. About how painful should I expect it to be to get a SWIG-wrapped custom subclass of a Qt class to play nice with either of these? What complications should I know about upfront?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
PyQt 通过 SIP 将 C++ 代码公开给 Python； PySide 通过 Shiboken 实现此目的。两者都具有与 SWIG 大致相同的功能（除了它们仅支持“将 C++ 扩展为 Python”，而 SWIG 还具有 Ruby、Perl、Java 等的后端）。 SWIG、SIP 和 Shiboken 均未设计为可相互互操作。您无法方便地使用 SWIG 来使用 Qt 所需的 C++ 扩展来包装任何代码（以支持信号和插槽），并且我不知道在尝试互操作 SIP 包装（或 Shiboken 包装）和 SWIG 时可能会遇到什么危险- 包装的代码。
请问，为什么您选择使用两种独立且等效的方式来包装 C++ 代码库的不同部分（Qt 通过 SIP 或 Shiboken，其他所有内容通过 SWIG）？如果您仍然可以重新考虑这个奇怪的设计决策，我会真诚地建议您这样做。
如果您对 SWIG 的选择是一成不变的，那么我预测每当您使用 Qt 扩展（即槽或信号）包装 C++ 代码时都会遇到很大的麻烦，并且对于所有相关人员来说通常都是非常痛苦的时间。如果您选择一种包装方式并坚持下去，问题应该会大大减少。我没有使用 Shiboken 的实际经验（它有点太新了，而且我现在几乎不再做 GUI 应用程序了……我的世界都是 Web 应用程序！-），但过去曾在这个角色中使用过 SIP（早在它被很好地记录之前——这些天在我看来，它的记录精彩，对 Shiboken 的粗略细读也给了我同样的印象），我可以强烈推荐它（事实上，如果我可以选择）即使项目中不涉及 Qt 代码，这也可能是比 SWIG 更好的选择）。
PyQt exposes C++ code to Python via SIP; PySide does so via Shiboken. Both have roughly the same capabilities as SWIG (except that they only support "extended C++ to Python", while SWIG has back-ends for Ruby, Perl, Java, and so forth as well). Neither SWIG nor SIP and Shiboken are designed to interoperate with each other. You couldn't conveniently use SWIG to wrap any code using the C++ extensions that Qt requires (to support signals and slots) and I have no idea what perils may await you in trying to interoperate SIP-wrapped (or Shiboken-wrapped) and SWIG-wrapped code.
Why, may I ask, have you chosen to use two separate and equivalent ways to wrap different parts of your C++ codebase (Qt via SIP or Shiboken, everything else via SWIG)? If you can still reconsider this weird design decision I would earnestly recommend that you do so.
If your choice of SWIG is carved in stone, I predict big trouble any time you're wrapping C++ code using Qt extensions (i.e., slots or signals) and a generally thoroughly miserable time for all involved. If you pick one way to wrap, and stick with it, the problems should be enormously reduced. I have no real-world experience with Shiboken (it's a bit too new, and I hardly ever do GUI apps these days any more... my world's all web app!-), but have used SIP in this role in the past (way back before it was decently documented -- these days it seems to me that it's splendidly documented, and superficial perusal of Shiboken gives me the same impression) and I can recommend it highly (indeed if I could choose it would be an option probably preferable to SWIG even if no Qt code was involved in a project).