[Qt GUI] QtQuick/QML 與 QtWidgets 的選擇
上一篇文章([Qt for Python] PySide 與 PyQt 的選擇)我簡單敘述了PySide跟PyQt的比較,不論你的最終選擇為何,對於初次選擇Qt作為GUI開發框架的學習者來說,一開始可能又會面臨到另一個困擾,就是QtQuick/QML跟QtWidgets的差異與選擇,所以在進入正式的系列文章之前,先來談談這個問題。
跟上一篇相同,先講結論,我認為選QtQuick/QML就對了。原因很多,不過我一樣列了三個最主要的理由,如下。
第一、完美切割 UI 跟 bussiness logic
對網頁程式開發有一定了解的開發者來說,對於 MVC 這個設計概念應該都不陌生。採用QtQuick/QML開發UI的話,等於是天然的MVC架構,完全把UI的邏輯跟商業邏輯切割清楚,不論你在商業邏輯的實作部份,是用C++或Python,都可以容易地在設計上符合MVC的設計理念。
雖然說,QtWidgets也是有獨立的UI檔案,是基於XML的文件。但在UI的操作邏輯,還是得透過C++或Python的實作來達成。光這一點優勢,就有足夠的理由選擇QtQuick/QML來實作UI。怎麼說呢?想想看,如果UI要改版的情況,商業邏輯沒有太大改變,那需要修改的程式碼,等於只有QtQuick/QML的部分。反之,在這樣的前提下,採用QtWidgets開法的UI,為了UI設計改版,有很大的可能性是整套程式碼都要修改。
第二、語法簡單直覺且開發快速
不論QtWidgets或QtQuick/QML,都可以透過官方IDE的UI設計工具,用拖曳的方式組成符合設計的UI,且自動產生對應的UI檔案。QtWidgets的UI文件是類似於Android UI的XML格式檔案,雖然有所謂的結構性,但閱讀起來不是太容易,且維護上也比較花時間。
相對來說,QtQuick/QML就是一個非常直接的描述式語言,透過描述UI元件的屬性,再搭配JavaScript語言,實現UI邏輯。程式的易讀性跟維護,都比QtWidgets好太多。另外,在UI動畫的開發上,也比QtWidgets容易,而且有比較佳的效能。
第三、渲染效能搭配硬體優化
自從Qt 4.7開始,官方發佈了QtQuick/QML這個新的GUI框架與程式語言,Qt公司就致力於其效能的優化,尤其在每一次大版本發佈(Qt5與Qt6),都有很大程度的技術改進。包括底層渲染引擎的效能,還有與硬體(GPU)的整合。
因為QtQuick/QML也是用C++實作的,且設計上本來就跟OpenGL有高度的整合,所以在繪製的效能上是非常不錯的。尤其是在嵌入式系統中,其特性就能發揮相對的優勢。這也是為什麼,有越來越多的嵌入式平台,採用Qt作為其應用程式的開發框架。像是近幾年來車用的儀表板,漸漸以數位式為主流,而有部分車商的數位儀表板,就是採用QtQuick/QML實作的。
接下來的文章預告
如果你是剛開始接觸Qt GUI框架,搭配Python開發,勢必會遇到UI與Python的互相溝通問題,網路上可以搜尋到的文章或影片教學,大多是以QtWidgets為主的,所以我接下來會針對QtQuick/QML如何與Python的溝通,做一系列的文章。
特別的是,我在之前寫了幾篇關於QtQuick/QML與C++的文章,所以接下來幾篇,也會參考之前的文章,介紹一下改成用Python是如何實作。換句話說,在不修改之前QML範例程式的情況下,改成用Python實作對應的功能,達到同樣的運行結果。
如果你對接下來的文章有興趣,歡迎填寫頁面最下方的表單,訂閱電子報,屆時會發送文章通知給訂閱者。
個人覺得必要時C++跟python拿出來開Component給QML用
比如AudioDevice之類的
然後QML做商業邏輯串接+UI 開發產能最高
謝謝您的回應,想必您也有一定程度的相關經驗。
以我的觀點,我不會放太多商業邏輯在QML
QML有的邏輯還是以UI操作邏輯
功能面為主的部分,還是以C++/Python實作
如果設計得當 可以有純邏輯的component
其實可以切得很乾淨漂亮
唯一的問題應該就是qml都跑在UI thread
WorkerScript的支援偏爛
當初設計一個DSP框架的時候我是用QML來串接各個node
比如
AudioDevice {
id: ad
}
FastFourierTransform {
input: ad.output
}
但他會利用threadpool去跑運算
想當然..這免不了用C++