原生 GUI 的解决方案是什么？

What's the solution to native GUIs?

本文关键字：是什么 解决方案 GUI 原生      更新时间：2023-10-16

根据我从SO那里了解到的，Qt在OS X上看起来根本不是原生的。

那么你该如何解决这个问题呢？您是否使用其他GUI库，如GTK？但它不会是Linux以外的任何东西的原生版本，对吧？

你必须为每个操作系统编写一个GUI吗？所以你为Windows写了一个Qt GUI，为Linux写了一份Qt GUI和为OS X写了一封Qt GUI？或者它看起来仍然是非本地的？

您是否必须根据操作系统使用不同的GUI库？所以你用Qt来运行Windows，用GTK来运行Linux，用Cocoa来运行OS X？但Qt不仅仅是一个GUI库；它有很多特点。那么，这是否意味着你需要重新发明Linux的轮子；OS X？

根据我的经验，在开发GUI时有两个相互竞争的目标：

  • 避免在为每个平台重新编码时重复工作
  • 看起来它100%"属于"它运行的平台

就目前情况来看，你基本上必须选择对你最重要的一个。

据我所知，没有一个GUI工具包能够实现可移植性和结果"属于"每个平台的理想完美性，这包括C++和Java选项。肯定有一些东西能达到近乎本土的外观，但总有一些东西不太对劲。就我个人而言，我更喜欢我所说的"引擎可移植性"，我相信它也有更花哨的名字。基本上，它是让你的逻辑核心尽可能地可移植，同时能够（但不需要）在必要时移植GUI。

这基本上意味着不依赖像Qt这样的库的所有非GUI功能，除非你确信它们将在你需要运行的每个目标平台上都可用。例如，我不得不将一些C++代码移植到Android，而当时Android上的Qt并不存在。如果我的核心逻辑依赖于它，我会有麻烦的。如果我的引擎没有很好地与GUI分离，我可能会遇到麻烦。事实上，我不得不用Java重新编码UI，然后通过JNI调用引擎。我还必须移植一些较低级别的功能，如线程，因为C++11当时还没有最终确定，我不能使用boost线程，而且原始代码是针对Windows的。但是核心逻辑并没有直接调用操作系统线程库，所以绝大多数代码都不需要被处理。

（顺便说一句：这并不是说你不能使用像Qt这样的非GUI功能，但如果你的代码与它集成在一起，那么如果你必须为库不支持的平台编码，你就会陷入困境。如果你在代码和Qt之间有一个抽象层，那么你只需要移植抽象层。）

便携性并不容易。事情肯定已经走过了很长的路，但我们还没有达到我们开发者想要的，我不相信我们真的会做到。

这只是IMHO，但它是基于经验的。

相关文章：