我有一个大型的跨平台（Linux和Windows）C ++项目，我想为其创建一个GUI。
我对这个项目的GUI的基本原理几乎没有一般性的问题：
答案 0 :(得分：26)
GUI应该与应用程序的逻辑分开吗？
是的，当然......
如果它是分开的，逻辑和GUI应该如何通信？ TCP / IP套接字是一个不错的选择吗？还有什么其他可能性？
...但不是那。套接字会过度（例外：见问题5）。通常，您在GUI和后端部分中拆分类。然后GUI类调用后端的方法。
使用不同于C ++的语言设置GUI是个好主意吗？如果是 - 哪种语言？
如果是这样，你必须整合这两种语言，所以我建议用同一种语言编写所有内容。但要回答你的问题，你可以为你的后端创建Python绑定，并用Python编写GUI（使用PyGTK，PyQT或wxWidgets）。
拥有基于浏览器的GUI是个好主意吗？
这取决于您希望如何部署应用程序。如果它应该安装在每台客户端计算机上，那么Web界面就没有意义。如果您想集中托管，那么您可以选择Web界面。
即使项目的核心逻辑是跨平台的，我可以决定GUI只是基于Windows（.NET？）并且它将通过Socket与相关Win / Linux机器上的逻辑进行通信或类似的方法。这样做是个好主意吗？
我认为只有当后端必须是某种安全（即不得安装在用户的计算机上）或者如果您有类似客户端的瘦方法时，这才有意义编写跨平台GUI比编写跨平台后端（在我看来）要容易得多，所以你宁愿跨平台做两个部分。顺便说一下，基于.NET的GUI不仅仅是Windows - 例如Mono已经支持很多Windows窗体（但不是WPF，不幸的是）。
修改
关于你的单声道问题：单声道大多是稳定的，但并非一切都已实现。可以肯定的是，您可以运行The Mono Migration Analyzer (MoMA)来确定某些内容是否无法在Mono中运行。但我认为so many companies在生产环境中成功使用Mono这一事实意味着您至少应该考虑将Mono作为一种选择！
答案 1 :(得分：2)
GUI应该与应用程序的逻辑分开吗？
它应该，因为UI小部件只是对象的类型，OO的规则之一就是每个 对象应该受到它可以履行的责任的信任。一个对话框不太了解 序列化例如。
如果它是分开的，逻辑和GUI应该如何通信？是 TCP / IP套接字是一个不错的选择吗？是什么 其他可能性？
这取决于您需要多少分离。我使用异步消息进行通信，然后我可以使用 不同的传输层没有很多变化。 TCP / IP允许您在与核心不同的机器上使用GUI，但它的开销高于 例如，传递窗口消息。
将GUI设置为一个是一个好主意 语言不同于C ++？如是 - 哪种语言？
理想情况下，您应该尽可能少地使用语言，除非您确实需要a的技术功能 某种语言。 GUI更像是一个库问题，而不是一个语言问题，所以如果你能找到一个非常好的 C ++ UI库（提示：Qt），您应该用C ++编写所有程序代码。
拥有一个好主意 基于浏览器的GUI？
可能是，但你应该考虑需求而不是想法。您的客户是否希望与之互动 你的程序来自浏览器？他们可以承担额外的费用和开发时间吗？你有专业知识吗？
即使项目的核心逻辑 是跨平台的，我可以决定 GUI将仅基于Windows （.NET？）它将与之通信 相关Win / Linux上的逻辑 机器通过Socket或类似的 方法。这样做是个好主意吗？
这可能是一个好主意，但请看＃3的答案。还要考虑您将要开发一个客户端 - 服务器程序，这比独立程序要复杂得多。 最后，您需要检查.NET依赖关系的优缺点，而不是使用C ++ UI库：.NET为您带来了wxWdigets，Qt，gtkmm等无法获得的功能。
答案 2 :(得分：2)
（1）通常是，这使得可以单独维护业务逻辑和用户界面。它还使您以后可以使用基于浏览器的SaaS用户界面以及桌面式本地无网络操作模式，仍然可以共享整个应用程序逻辑代码。
（2）不使用TCP / IP套接字。通常，应用程序和GUI将使用事件和/或消息传递进行通信。例如，当应用程序想要通知GUI发生某些事情时，它会创建一个合成事件，然后将其推送到GUI的事件队列。如果应用程序也是基于事件的，则GUI可以通过发布事件与其通信。对于非阻塞，快速操作，GUI可以直接调用应用程序逻辑代码，但必须保证调用快速返回。对于较慢的操作，无论如何都需要一个单独的线程来处理它们。该线程可以是处理应用程序端事件的线程，也可以在需要时将其作为工作线程生成。
我们公司的产品在Eclipse IDE之上有一个用户界面，但部分应用程序逻辑是用C ++编写的。这两部分通过CORBA进行通信，即基本上是异步事件机制。我们对此解决方案感到满意。
在较小规模上，GUI应用程序通常使用模型 - 视图 - 控制器（MVC）等抽象来分离UI和应用程序逻辑。
（3）集成用两个不同组件编写的组件总是很麻烦。我认为只有当你有明显的平台优势时才应该这样做。例如。我们从Eclipse IDE组件中受益，而应用程序则受益于C ++的原始速度。
（4）基于浏览器的GUI非常棒，但与业务逻辑的集成受到延迟的影响，如果您实际拥有桌面式应用程序，Web服务器的无状态模式会使架构变得繁琐。基于浏览器的GUI适用于软件即服务应用程序，因为它们不需要用户安装，并且可以由产品开发人员随意升级，但如果您不打算将产品作为软件即服务产品（例如Salesforce）。
（5）如果您的应用程序逻辑是跨平台的，我会努力使UI跨平台。否则，对于那些只支持应用程序逻辑的平台，您可能需要安装两个操作系统，一个用于运行UI，另一个用于运行应用程序逻辑。有很好的跨平台用户界面框架，至少
答案 3 :(得分：1)
最好使用python作为基础gui语言，使用QT作为gui平台。 如果你在单独的进程中拆分gui和base程序，那么你可以使用这种机制进行通信：
但最好创建一个进程并直接从python调用基本语言并与本机语言的数据结构进行通信。你为了这个目的使用swig。但是因为你不能在C ++中调用python函数，你可以在python中使用池来进行共享数据的一些更改，并根据这些更改做一些事情。我经历过两种方式。当我使用python进行GUI和管理时，它可以节省时间。
答案 4 :(得分：1)
1。 GUI应该与应用程序的逻辑分开吗？
是。但是，请参阅答案＃2
2。如果它是分开的，逻辑和GUI应该如何通信？ TCP / IP套接字是一个不错的选择吗？还有什么其他可能性？
我相信通过选择GUI框架，MFC，.NET，wxWidgets，Qt，...可以获得最佳答案。 您选择的框架将尽可能轻松地为您分离和沟通。
不要试图重新发明轮子。框架设计人员已经在他们可以负担得起的实现中加入了更多的思考和测试。
请注意，问题＃1表明您要求在单个应用程序中分离逻辑。但是，后来的问题表明你可能会想到两个独立的应用程序，甚至可能在不同的机器上运行。
我认为在完全独立的应用程序中使用GUI总会导致一些缓慢且不灵活的事情。但是，如果您不关心速度和灵活性，特别是如果您已经使用简单的控制台类型接口运行核心应用程序，那么这可能是最好的方法。
3。使用不同于C ++的语言使用GUI是一个好主意吗？如果是 - 哪种语言？
没有
如果你是一个单人编程团队，那么你将会因为掌握两种语言而过于分散。如果你是一个多人团队，为什么通过建立两种不同的文化来复合沟通？
4。拥有基于浏览器的GUI是一个好主意吗？
如果你可以避免它，那就不行了。如果您需要基于浏览器的GUI，那么您就会知道它。如果你不需要，那就保持简单并跳过它。
5。即使项目的核心逻辑是跨平台的，我可以决定GUI只是基于Windows（.NET？），它将通过Socket或类似方法与相关Win / Linux机器上的逻辑进行通信。这样做是个好主意吗？
与＃4相同的答案
答案 5 :(得分：1)
有些用户已经对您的问题给出了一些好的答案，这就是为什么我想给您一些如何处理我的项目的提示。
问：我的应用程序应运行在哪个操作系统上？
Windows和Linux！ - ＆GT;我会使用C ++或Java
问：运行时速度是否重要？
是的！ （计算，绘图，访问系统资源......） - ＆GT;鉴于速度C ++通常更快（并非总是）
问：是否需要配置文件？
答：是的！我必须设置一些用户和系统特定的值。 - ＆GT;可以将配置保存到注册表中但是因为我们也想在linux上使用我们的应用程序，所以我们使用xml（rapidxml将是一个很好的C ++解决方案）
问：是否需要数据库？
答：是的，我需要保存一些信息/计算（本地/全球）。 - ＆GT;本地：我使用sqlite - ＆GT;如果你只需要保存相对较少的信息，请考虑更快的方式来存储这些信息（xml？！）
问：我应该如何构建我的应用程序？
答：始终将GUI与“逻辑”部分分开 - ＆gt;以后更容易更改代码，您也可以将代码用于其他项目。 +已经提到的原因。
问：我应该如何构建我的GUI？
答：考虑一下您的应用程序应该用于什么以及用户应该做什么。啊，请不要创建太深的层次结构，这意味着用户不必打开10个窗口就可以打开他们想要的窗口。对于您的代码也是如此，拥有太多创建新对象的对象并不是明智的决定。
object->object->object->object->object->object->object->object
答：是的？你必须使用套接字！但请记住，通过套接字进行的通信不是非常快速和安全，因此如果您不需要，请不要使用它们。问：我的应用程序是否必须与服务器应用程序通信？
问：我不确定如何开始（我们是一群开发人员）
答：在开始一个新项目时我正在考虑所有这些要点（可能还有一些）+为了看看我需要哪些类和方法，我首先要创建一个UML-Diagram来帮助我理解我应该开始，图表也将帮助我跟踪我的类和方法以及它们如何相互参与。 UML-Diagram还将帮助您的配偶或客户了解您的应用程序的结构。
对于更大的项目，我会使用C ++＆amp; wxWidgits或者Qt。 （只是我的观点）
RGDS 莱恩
答案 6 :(得分：1)
如果你想要一个免费且写得很好的跨平台GUI解决方案的好例子，我建议你看一下wxWidgets（1）。我希望这有帮助
答案 7 :(得分：1)
我的回答很通用，因为你没有说明你的申请。
GUI应该与应用程序的逻辑分开吗？
在代码中，绝对是。在一个单独的进程中运行，可能在一台单独的机器上运行，也可能是一个好主意，但这实际上取决于您的要求。
将其完全分开的原因：
不分开的原因：
如果它是分开的，逻辑和GUI应该如何通信？ TCP / IP套接字是一个不错的选择吗？还有什么其他可能性？
HTTP是一种流行的选择，它避免了防火墙等大多数问题。在C / C ++中，您可以将libcurl用于http / https请求和Boost.CGI（尚未接受Boost）或服务器端的其他CGI库之一。
IPC的其他选项包括共享内存（Boost.Interprocess），UNIX套接字和其他网络协议。但是，除非传输大量数据，否则我不会推荐这些。
使用不同于C ++的语言使用GUI是个好主意吗？如果是 - 哪种语言？
我没有从中看到太多的好处。尽管如此，分离GUI还是允许用不同的语言编写它 - 甚至可能是它的多个实现。
拥有基于浏览器的GUI是个好主意吗？
当然。 如果您可以使用HTML5和JavaScript完成所需的工作，甚至不要考虑使用传统的GUI，只需将其设为webapp即可。
好处是：
curl程序）另一方面，您的性能会略有下降，但它再一次不会影响典型的GUI应用程序。
即使项目的核心逻辑是跨平台的，我可以决定GUI只是基于Windows（.NET？）并且它将通过Socket或类似方法与相关Win / Linux机器上的逻辑通信。这样做是个好主意吗？
跨平台GUI库的API有点可怕。 Qt现在看起来非常出色，它的API相当不错，即使它对你的应用程序有重大影响。尝试严格限制对Qt的任何使用。真正的原生跨平台GUI的另一个选择是wxWidgets，它可以更好地与其他C ++代码集成，但是它有一个非常讨厌且容易出错的API。
对于Web UI，你绝对应该考虑Wt，它是一个高级C ++ AJAX框架，具有类似于Qt的接口，但是使用现代C ++实践而不是像Qt那样接管你的应用程序。
答案 8 :(得分：1)
我同意评论员说“信息不足”，但根据您的需要，您应该对网络浏览器界面给予很多考虑。
如果实时流数据和即时满足交互不重要，那么Web界面可以相当简单，没有AJAX，只需要基于形式的简单CGI和动态生成的HTML。请记住浏览器为您更新时存在的部分以及其他人的资金以及Windows，Linux，Mac或其他系统中的任何更改。
您的用户已经发现这个很熟悉。你可以找到程序员来完成这项工作。 如果需要，几乎所有主要语言中的库都已存在于将Web服务器本地嵌入到应用程序中。或者您可以运行某种中央服务器。
浏览器已经有了很好的方法来分离内容，输入（表单），样式和增强功能，以便在未来找到可以开发或更改相关组件的人员。
有些人可能会说这对应用程序的独立版本不好，但我说只要你添加一些安全性就可以独立运行（运行一个嵌入式网络服务器，只有来自本地计算机才会回答请求）。通过从应用程序启动浏览器或告诉用户在哪里进入启动消息（URL http://localhost:7654或其他什么，而不是他们的永恒目的地:-)），可以使用户的生活更轻松。
答案 9 :(得分：0)
- GUI应该与应用程序的逻辑分开吗？
是
- 如果它是分开的，逻辑和GUI应该如何通信？是 TCP / IP套接字是一个不错的选择吗？是什么 其他可能性？
TCP / IP太过分了。使用OOP或任何其他结构化编程方法分离应用程序逻辑和GUI。
- 将GUI设置为与a不同的语言是一个好主意 C ++？如果是 - 哪种语言？
就跨平台应用程序而言，C ++已经足够好了。其他选项是Java和.NET，在这种情况下，大多数跨平台的东西都会被处理......虽然没有C ++提供的控制程度。
- 拥有基于浏览器的GUI是个好主意吗？
最好的想法，只要您的应用在用户互动过程中不需要太精细的控制程度。
- 即使项目的核心逻辑是跨平台的，我也可以决定 GUI将是唯一的 基于Windows（.NET？），它会 与上面的逻辑沟通 相关的Win / Linux机器通过 套接字或类似方法。这是好事 这样做的想法？
恕我直言，增加使用套接字的复杂性并不值得。
SciTE是一个简单的跨平台应用程序的一个很好的例子。对于Windows程序员来说，源代码应该很容易理解。我建议你下载源代码，看看两个平台（Windows和GTK）是如何处理相同的代码库的。
答案 10 :(得分：0)
你上帝有很多好的答案，但我仍然会写自己的
GUI应该与应用程序的逻辑分开吗？
我认为这是最好的。因此，当它进行修改时，您可以更轻松地处理它。此外，使用多平台的GUI框架并具有其他语言的绑定，例如GTK +或Qt。
如果它是分开的，逻辑和GUI应该如何通信？ TCP / IP套接字是一个不错的选择吗？还有什么其他可能性？
套接字是一个不错的选择，如果它是本地通信，则通过线程。
使用不同于C ++的语言使用GUI是个好主意吗？如果是 - 哪种语言？
我认为这不是最好的选择。如果可以，请使用相同的语言。
拥有基于浏览器的GUI是个好主意吗？
只要它不太复杂。我认为基于浏览器的GUI仅适用于协作工具或绝对平台独立（每个操作系统都有浏览器），只要您将主程序保存在服务器中即可。有人说avobe，如果你考虑做一个web GUI，首先考虑做一个webapp。
即使项目的核心逻辑是跨平台的，我可以决定GUI只是基于Windows（.NET？）并且它将通过Socket与相关Win / Linux机器上的逻辑进行通信或类似的方法。这样做是个好主意吗？
在我看来，它增加了复杂性，通常是不必要的，但如果你真的必须这样做，是的，套接字是最好的选择。