寻找与 C++ 一起使用的 GUI 框架，以“现代化”现有的触摸屏界面。
我是一名具有 C++/Java 背景的新手程序员，刚刚分配了一个项目，该项目涉及使用 MFC（3 个数据视图、多个文本/无线电控制对话框等）获取现有 C++ 程序并将界面重新设计为“触摸屏友好”，例如更大的按钮控件、滑块等。
与我得到的典型的准系统 MFC 相比，我得到了相当自由的指令来制作“更现代的界面” 。我知道我有很多东西要学，所以任何建议都是有帮助的。
到目前为止，我提出的选项是：
真的，我只需要找到一种方法让这个程序看起来不是 10 多年前编写的，到目前为止，在自学 MFC 时，它在合并任何类型的图形设计方面似乎并不灵活/主题。
我应该研究其他替代方案吗？MFC 是否有更多的东西，我只需要了解更多吗？正如我所说，任何关于要调查的事情的建议都是有帮助的。
您列为#1 的内容实际上可能是两种方法中的任何一种。一种（称为 1a）是继续使用与原始版本相同的 VC++ 和 MFC，并且只进行最少量的编辑以在需要时增加控件的大小。如果在现有代码的编写方式上遇到一些相当糟糕的运气，这可能根本不涉及任何真正的编程，并且会相对快速和容易。
第二个（称为 1b）将使用当前版本的 VC++、MFC 等进行更新。这可能会涉及一些代码更新，但可能不是什么可怕的事情（尽管如果它已经超过10 年，重要的代码也可能需要更新）。稍加注意，您也许可以对 UI 进行相当多的更新（例如，从菜单更改为功能区，包括颜色主题支持），但投资仍然很少。
您的 #2 很容易以几乎完全重写的方式结束。尽管表面上相似，但 C++/CLI 是与 C++完全不同的语言。唯一真正有意义的方法是，如果您有相当多的非 UI 代码，您可以完全不理会，并专门使用 C++/CLI 作为现有 C++ 和 .NET UI 之间的“桥梁”（并且 UI 相当最小，因此对 C++/CLI 的相当平庸的工具支持不会造成大问题）。如果您的 UI 非常简单，C# 有足够好的工具支持，它可能很容易成为比 C++/CLI 更好的选择。
您的#3 可能只需要比 2 稍微少一点的重写，至少与 UI 相关的代码是这样。虽然代码仍然是 C++，但 Qt 与 MFC 有很大不同。如果您（可能很快）想要支持 Windows 以外的东西（例如，iOS 或 Android），那么最大的优势将是。对于可移植性，Qt 比您指定的任何替代方案都具有巨大优势。
很多问题都回到了可以完整保留多少 C++ 代码的问题。如果您在与 UI 完全分离的“引擎”中有大量代码，并且 UI 相当简单，那么保留现有代码很有意义，从头开始重写 UI 并不是那么糟糕的一个问题。另一方面，如果 UI 和业务逻辑代码紧密地交织在一起（相当普遍），那么对我来说，除了对 UI 进行非常小的调整外，其他代码的其余部分也可能会进行重大改写。
结论：如果 UI 与其他代码严重交织在一起，那么您唯一真正的选择是在 1a 和 1b 之间。如果 UI 很容易与其他代码分离，那么 2 和 3 之间的选择（至少对我而言）主要是可移植性是否很重要（现在或任何时候）。