Qt 經驗談

大概 3~4 年前當我開始用 Qt 的時候, 那時候 Qt 4 才剛剛出來沒幾年. 之前的版本我沒用過, 但是那時 Qt 4 看起來已經算是十分的完備, 甚至我還覺得如果只把它看成是一個 UI Framework 來說已經算是撈過界了. 當然 Qt 的野心不僅於此, 許多常見的功能包括 Thread classes, Networking, Web browser engine, XML, SQL, Storage Classes, OpenGL 等等的東西, 畢竟它可是立志要當 C++ 中的 Java Framework Solution 呢. 不過當時我們只是大部分用他來作 UI 的顯示以及設定儲存上的處理罷了. (那時候 Qt 超貴的一個平台的單一 License 要10幾萬, 也沒有啥 LGPL 版跟 Qt Creator, 跟 Visual Studio 的結合也是要錢的版本才有, 整個買下來的費用真的不少. 總歸一句話, 老闆有錢真好.....)

不過當時 Qt 讓我覺得很驚艷的部分則是他的 UI Framework 可以把 View 跟 Model 的處理切得很開, 這一點在當時已經夠讓我驚訝了 (大概是我對其他的 Framework 不熟). 美工的工作僅限於把元件上的所需的圖畫好並使用 Qt 提供的工具把圖貼好 (這部分不難, 也不需要太多的時間作訓練), 然後再將改好的圖跟設定檔給我們之後跟著程式一起包出去就完成了. 當然最近 Qt 又搞了一個 QML 的 UI Script. 大概是想要把元件的屬性進一步開放給 UI 設計者可以有更多的發揮空間吧. 其實當時在早期的 Qt 版本之中就已經有提供類似的功能可以作調整, 不過是得寫在程式裡改的, 要開放出來還得費一番功夫去設計, 可以調整的東西也很有限. 但是現在很多 UI 的 Framework 其實都有遵循類似的設計, 包括最夯的 Android 也是如此. 也許 Qt 不是第一家, 但是習慣了這個模式以後很多類似這樣設計的 Framework 會讓你工作起來更得心應手.

Qt 大部分的 UI 常用原件都是用 Signal 跟 Slot 機制去實作的, 這方面 Qt  的官方文件十分清楚. 這個觀念很方便, 也可以很輕易的把 UI 的呼叫跟程式主體切開跟置換, 也沒有被介面綁標的困擾(當然還是得適可而止別亂用, 飛來飛去的 Signal 跟 Slot 有時候 Debug 起來是要人命的). 當然你也可以去覆寫 Qt 原有的事件去達到類似的目的 (有時候不得不這樣作), 但是通常非必要我不建議這麼作, 除非你可以確定你的程式沒有使用Thread. 因為在某些作業系統下如果是非主要的 Thread 去更動 UI 元件內的資料會造成程式當機 (也許這問題已經不復存在, 但是這在早期不算是新鮮事), 而貼心的 Qt 的 Signal 跟 Slot 機制已經幫你處理掉這一塊的問題了.

還有 Qt 真正的完整 View / Model UI 原件組 (List/Table View Model 之類的) 昰一定得具備的, 畢竟這是 Java 2 幾百年前就有的東西. 概念上大同小異, 只是實現的方法跟細節不同. 這方面我玩得不是很透徹, 但是我覺得似乎 Java Swing 在 Table Cell 客製化內容的顯示的實現上, 像是類似貼圖貼星星等等的東西, 似乎比 Qt 要來的簡單多了. Qt 要去做這些事情, 要搞懂的概念實在是不少.

對於多國語言的支援以及轉換, 其實 Qt 在當時做得很不錯了, 不過這需要設計師一點點小小的幫忙. 在 Qt 程式中常常會見到 tr() 的巨集指令包著字串, 很多初學者會覺得很奇怪, 為什麼要這麼做? 其實這個巨集的作用是為了做多國語言轉換的時候用的. 事先用這個巨集布局好需要翻譯的字串, 之後可以透過工具產生一份份的翻譯檔, 再把對照的字串填入到翻譯檔即可. Qt 會依照作業系統的語系自動轉換到對應的語系, 它也提供了 API 可以切換.

當然 Qt 還有很多很好用的功能, 但是並不是每個東西都這麼好用. 例如如果有效能考量, 用 Qt 的 container class 不如用 std 得還來的快. 因為各家的 編譯器大概已經把這些東西的最佳化都做得很好了. 還有善用演算法跟小技巧去加速一些繁重的工作而不完全依賴它本身提供的模組也是比較健康的思維.