python Qt 现在在 LGPL 下发布，你会推荐它而不是 wxWidgets 吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/464463/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Qt being now released under LGPL, would you recommend it over wxWidgets?
提问by Mapad
I am quite a heavy user of wxWidgets, partly because of licensing reasons.
我是 wxWidgets 的忠实用户，部分原因是许可原因。
- How do you see the future of wxWidgets in prospect of the recent announcementof Qt now being released under LGPL?
- Do you think wxwidget is still a good technical choice for new projects ? Or would you recommand adopting Qt, because it is going to be a de-facto standard.
- I am also interested about the possible implications this will have on their bindings with the most common scripting languages (e.g. PyQt, wxPython, wxRuby). Why PyQt is so under-used when it has a professional grade designer and wxPython not?
- 您如何看待 wxWidgets 的未来，因为最近宣布Qt 将在 LGPL 下发布？
- 您认为 wxwidget 仍然是新项目的一个不错的技术选择吗？或者您会建议采用 Qt，因为它将成为事实上的标准。
- 我还对它们与最常见的脚本语言（例如 PyQt、wxPython、wxRuby）的绑定可能产生的影响感兴趣。为什么 PyQt 有专业级设计师而 wxPython 却没有得到充分利用？
Related:
有关的：
采纳答案by mghie
For those of us who are drawn to wxWidgets because it is the cross-platform library that uses native controls for proper look and feel the licensing change of Qt has little to no consequences.
对于我们这些被 wxWidgets 所吸引的人来说，因为它是一个跨平台库，它使用本机控件来获得正确的外观和感觉，Qt 的许可更改几乎没有影响。
Edit:
编辑：
Regarding
关于
Qt not having native controls but native drawing functions
Qt 没有原生控件，但有原生绘图功能
let me quote the wxWidgets wiki page comparing toolkits:
Qt doesn't have true native ports like wxWidgets does. What we mean by this is that even though Qt draws them quite realistically, Qt draws its own widgets on each platform. It's worth mentioning though that Qt comes with special styles for Mac OS X and Windows XP and Vista that use native APIs (Appearance Manager on Mac OS X, UxTheme on Windows XP) for drawing standard widget primitives (e.g. scrollbars or buttons) exactly like any native application. Event handling, the resulting visual feedback and widget layout are always implemented by Qt.
Qt 没有像 wxWidgets 那样真正的本地端口。我们的意思是，尽管 Qt 非常逼真地绘制了它们，但 Qt 在每个平台上绘制了自己的小部件。值得一提的是，Qt 为 Mac OS X、Windows XP 和 Vista 提供了特殊样式，它们使用原生 API（Mac OS X 上的外观管理器，Windows XP 上的 UxTheme）来绘制标准小部件基元（例如滚动条或按钮），就像任何本机应用程序。事件处理、由此产生的视觉反馈和小部件布局始终由 Qt 实现。
回答by Emiliano
I'm currently using pyqt at work and I find myself totally satisfied. You have better documentation (IMHO), better event managing (signal-slot pattern is somehow more powerful than the old simple-callback style), and importing your custom widget in a graphical designer like qt-designer is far easier. As far as I can tell qt-designer is more powerful than any wxpython counterpart, like Boa Constructor and pyGlade). You also have great support for translating program's strings in different languages (better support than wxLocale at least, and you can use a tool like Qt-Linguist which is fully integrated in the qt system).
我目前在工作中使用 pyqt，我发现自己完全满意。你有更好的文档（恕我直言），更好的事件管理（信号槽模式在某种程度上比旧的简单回调风格更强大），并且在像 qt-designer 这样的图形设计器中导入你的自定义小部件要容易得多。据我所知，qt-designer 比任何 wxpython 对应物都更强大，例如 Boa Constructor 和 pyGlade）。你也非常支持翻译不同语言的程序字符串（至少比 wxLocale 支持更好，你可以使用 Qt-Linguist 之类的工具，它完全集成在 qt 系统中）。
I'm using wxpython in some hobbistic works, but I'm still a noob there. I think its greater advantage over pyqt is to have a native look&feel on different platforms. This is a huge point if you are developing windows/linux applications, for example. Actually you could use "skins" to obtain a native look&feel with windows-qt applications but I have no idea on how to achieve that (sorry, I've never used qt on windows :D).
我在一些业余作品中使用 wxpython，但我仍然是一个菜鸟。我认为它比 pyqt 更大的优势是在不同平台上拥有原生的外观和感觉。例如，如果您正在开发 windows/linux 应用程序，这是一个重要的点。实际上，您可以使用“皮肤”来获得 windows-qt 应用程序的本机外观和感觉，但我不知道如何实现这一点（抱歉，我从未在 windows 上使用过 qt :D）。
回答by akaihola
Please note that, as of Jan 2009, while Qt 4.5 was to be available under LGPL, Riverbank Computing hadn't made any announcement about licensing for future versions of PyQt. PyQt is still only commercial/GPLv2/GPLv3.
请注意，截至 2009 年 1 月，虽然 Qt 4.5 将在 LGPL 下可用，但 Riverbank Computing 尚未就PyQt未来版本的许可发布任何公告。PyQt 仍然只是商业/GPLv2/GPLv3。
As noted in comments for this answer, Nokia announced the LGPL-licensed PySideproject in August 2009.
正如对此回答的评论中所述，诺基亚于 2009 年 8 月宣布了 LGPL 许可的PySide项目。
回答by Philippe F
Honestly, I don't think that people will massively switch away from WxWidgets.
老实说，我不认为人们会大量远离 WxWidgets。
For python, there are PyQt bindings and WxPython bindings. Despite Qt being much more practical than WxWidgets, the majority of GUI python open source programs are written with WxWidgets. Since those programs are open source, the GPL vs LGPL did not matter that much in their choice of toolkit.
对于 Python，有 PyQt 绑定和 WxPython 绑定。尽管 Qt 比 WxWidgets 实用得多，但大多数 GUI python 开源程序都是用 WxWidgets 编写的。由于这些程序是开源的，因此 GPL 与 LGPL 在他们选择的工具包中并没有那么重要。
The same goes for Gtk. Many open source applications are written in Gtk, on windows, despite Gtk being very difficult to work with on windows. With Qt, those applications would be a lot easier to maintain on a cross platform basis, but it has not happened.
Gtk 也是如此。许多开源应用程序是在 Windows 上用 Gtk 编写的，尽管 Gtk 在 Windows 上很难使用。使用 Qt，这些应用程序在跨平台的基础上维护起来会容易得多，但事实并非如此。
So, choice of toolkit is influenced by many parameters, licensing being only one of them.
因此，工具包的选择受许多参数的影响，许可只是其中之一。
I still don't understand why Qt is not more mainstream, because it's in my opinion the easiest and more practical GUI toolkit ever written.
我仍然不明白为什么 Qt 不是更主流，因为在我看来它是有史以来最简单、更实用的 GUI 工具包。
回答by Andy Brice
Qt is very comprehensive and high quality framework. I am sure that many new projects that would have used wxWidgets will now use LGPL Qt instead. But projects that are already using wxWidgets will no doubt continue to use wxWidgets rather than doing a massive re-write.
Qt 是一个非常全面和高质量的框架。我确信许多本来会使用 wxWidgets 的新项目现在将使用 LGPL Qt。但是已经在使用 wxWidgets 的项目无疑会继续使用 wxWidgets 而不是进行大规模的重写。
回答by Berry Tsakala
I chose wxPython for 2 main reasons:
我选择 wxPython 有两个主要原因：
- Boa Constructor, which is still a beta product, gives me unified control over 100% of the process, whereas PyQt indeed has better designer, but there's no connection between editing "event handlers".
- Boa Constructor 仍然是一个测试版产品，它让我可以统一控制 100% 的过程，而 PyQt 确实有更好的设计器，但编辑“事件处理程序”之间没有联系。
My ideal IDE designs, creates events, let me edit just the functional code needed, and run; without "compiling UICs", without switching editors, without going into the command line. While for Large scale applications it matters very little, my current domain is fast and small scale programs.
我理想的 IDE 设计、创建事件，让我只编辑所需的功能代码，然后运行；无需“编译 UIC”，无需切换编辑器，无需进入命令行。虽然对于大型应用程序来说它无关紧要，但我目前的领域是快速和小型程序。
Licensing... it doesn't matter right now, but it will once I start vending my stuff on small scale.
autocompletion inside event functional code doesn't seem to work in QTDesigner, for event code. I might be missing something, yet the "broken" process described above prevent it from being a RAD.
许可……现在不重要，但是一旦我开始小规模销售我的东西就会重要。
对于事件代码，事件功能代码中的自动完成似乎在 QTDesigner 中不起作用。我可能遗漏了一些东西，但上面描述的“损坏的”过程阻止它成为 RAD。
回答by Matthew
I was never able to setup Qt to cross compile. I remember seeing something from Trolltech saying that they don't officially support cross compilation, although I can't find it now.
我永远无法设置 Qt 进行交叉编译。我记得从 Trolltech 那里看到一些东西说他们不正式支持交叉编译，尽管我现在找不到了。
There are many guides and such detailing how to get Qt to cross compile, so its possible (likely) that I was doing something wrong.
有很多指南和详细说明如何让 Qt 进行交叉编译，所以有可能（很可能）我做错了什么。
When choosing a framework, I recommend considering and testing out their cross compilation abilities.
在选择框架时，我建议考虑并测试它们的交叉编译能力。
