從我所瞭解的來看，Qt在OS X上看起來根本不是原生的。本地GUI的解決方案是什麼？
那麼你如何解決這個問題？您是否使用其他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 OS &？
這是我的經驗，你有兩個相互競爭的目標時，開發圖形用戶界面：
就目前而言，您基本上必須選擇一個對您來說最重要的問題。
我不知道這樣做的GUI工具包能夠實現理想的完美，既可移植又看起來像每個平臺上「屬於」的結果 - 這包括C++和Java選項。肯定有東西可以達到近乎原生的外觀，但總是有些事情對他們來說並不完全正確。就我個人而言，我更喜歡我稱之爲「引擎可移植性」的東西，並且我確信它有更加奇特的名字。基本上，如果需要的話，儘可能使邏輯的核心儘可能便攜，而不是必須的。
這基本上意味着不依賴於像Qt這樣的庫的所有非GUI功能，除非您確定它們將在您需要運行的每個目標平臺上都可用。例如，我必須將一些C++代碼移植到Android一次，而Android上的Qt在當時不存在。如果我的核心邏輯依賴於它，我會遇到麻煩。如果我的引擎沒有從我的GUI中分離得很好，我會遇到麻煩。事實上，我必須用Java重新編碼UI，然後通過JNI調用引擎。我還必須移植一些較低級別的功能，例如線程，因爲C++ 11當時還沒有完成，我無法使用boost線程，而原始代碼是針對Windows的。但核心邏輯並沒有直接調用操作系統線程庫，所以絕大多數代碼都不需要被觸及。 （另外：這並不是說你不能使用像Qt這樣的非GUI功能，但是如果你的代碼與它整合在一起，那麼如果你不得不爲它編寫代碼，你將會被卡住如果你的代碼和Qt之間有一個抽象層，那麼你只需要移植抽象層。）
可移植性並不容易。事情已經有了很長的路要走，但是我們還沒有實現開發者願意擁有的東西，我不相信我們真的會這麼做。
這只是恕我直言，但它是基於經驗。
請參閱http://stackoverflow.com/questions/12717138/what-is-linuxs-native-gui-api和http://stackoverflow.com/questions/8303896/gui-programming-c-for-mac- OS-X獅子。 – user1929959
你是什麼意思「Qt在OS X上看起來不是本機的」？是否有一些小部件失蹤？有些小部件不是作爲原生小部件繪製的嗎？或者是什麼？ – 2013-08-01 15:27:33