我知道有很多Qt vs MFC的问题，但我会尽量非常具体。
我们有一个大的(10年的发展)c++ MFC应用程序的利基行业。它应该永远只支持windows和英语。但是我们需要添加一些新的设计师绘制的GUI和GUI控件(对话框、按钮、自定义列表等)。
我们可以雇佣1到2个新的GUI开发人员来构建这些新的界面，所以我们可以选择不同于MFC的技术。
Qt似乎最有前途，适合与MFC并行运行(哦，不，我们不是从头开始重新构建应用程序)。
似乎大多数被引用的Qt优势都是无关紧要的:跨平台开发，易于国际化，开源，非gui库(我们不需要网络，并且已经实现了大多数其他功能)。
但Qt也因其良好的面向对象设计而闻名，他们最近推出了QtQuick。我想给它一个机会，所以问题是
- 在一个商业的仅windows项目中，从纯MFC迁移到MFC+Qt有什么实质性的优势，这是值得学习Qt的麻烦，将其集成到我们的构建/部署过程中，也许还需要支付商业许可证?
- 特别是，如果我们在Qt中构建新的gui并通过QWinWidget将它们合并到应用程序中，它会加速开发吗?
可能不会。
如果gui和业务逻辑很好地分离，那么将gui逐渐转移到Qt或在Qt中实现新部分可能是有意义的-但我们都知道gui/逻辑将是一个可怕的混合在一起的混乱
如果你正在做一个重写(这是Qt将最终作为)，然后如果它是一个常规的商业类型的应用程序，那么使用c#/.net可能更容易。
如果性能是至关重要的，你有很多领域的知识捆绑在定义良好、分离良好的c++库中，那么Qt前端将是值得的
基本上不是回答问题，但也可能有所帮助。我认为用新工具做GUI的另一种方法是使用ActiveX和COM。我相信您可以轻松地在MFC应用程序中使用ActiveX组件。还有很多方法可以创建这样的控件。我使用Delphi来做控件，这些控件成功地用于。net WinForms应用程序，但据我所知，这些控件可以在。net环境中轻松创建。