据我所知，在OS X上，Qt看起来并不是原生的。
那你怎么解决这个问题呢？您是否使用其他GUI库，如GTK？但是除了Linux之外，它不会是原生的，对吗？
您是否必须为每个操作系统编写GUI？那么你为Windows编写一个Qt GUI，为Linux编写一个Qt GUI，为OS X编写一个Qt GUI？或者它仍然看起来不是原生的？
您是否必须根据操作系统使用不同的GUI库？所以你使用Qt for Windows，GTK for Linux和Cocoa for OS X？但是Qt不仅仅是一个GUI库;它有很多功能。那么这是否意味着你需要为Linux和Linux重新发明轮子？ OS X？
答案 0 :(得分：4)
根据我的经验，您在开发GUI时有两个相互竞争的目标：
目前，你基本上必须选择最重要的那个。
我所知道的GUI工具包没有实现可移植的理想完美，看起来像每个平台上的“属于”结果 - 这包括C ++和Java选项。肯定有一些东西可以实现近乎原生的外观，但总有一些东西对它们来说不太对劲。就个人而言，我更喜欢我称之为“引擎可移植性”的东西，而且我确信它有更多的名字。基本上，如果有必要，可以使逻辑的核心尽可能地便携，同时能够 - 但不是必须 - 移植GUI。
这基本上意味着不依赖于像Qt这样的库的所有非GUI功能，除非您确定它们将在您需要运行的每个目标平台上可用。例如，我不得不将一些C ++代码移植到Android一次，而Android上的Qt当时不存在。如果我的核心逻辑依赖它，我会遇到麻烦。如果我的引擎没有与我的GUI分离得很好，我就会遇到麻烦。事实上，我不得不用Java重新编码UI，然后通过JNI调用引擎。我还必须移植一些较低级别的功能，如线程，因为C ++ 11当时尚未最终确定，我无法使用boost线程，原始代码适用于Windows。但核心逻辑没有直接调用操作系统线程库，因此绝大多数代码都不需要触及。
（顺便说一下：这并不是说你不能使用像Qt这样的东西的非GUI功能，但是如果你的代码与它紧密相关，那么如果你需要为平台编写代码就会陷入困境库不支持。如果你的代码和Qt之间有一个抽象层，那么你只需要移植抽象层。）
便携性并不容易。事情已经走了很长的路，但我们还没有达到开发人员所希望拥有的东西，而且我不相信我们真的愿意。
这只是恕我直言，但它是基于经验。