RCViewer最終選擇QT作為應(yīng)用框架志衣，到今天為止窿吩，我認(rèn)為這一次技術(shù)選型并沒有錯(cuò)或链，一半來自于我對現(xiàn)有開發(fā)進(jìn)度與實(shí)驗(yàn)結(jié)果的掌控和滿意度，另一半來自于我驚喜的發(fā)現(xiàn)鲸沮，最偉大的先驅(qū)竟然也是QT開發(fā)的琳骡，這一下子背書了QT可以開發(fā)大型應(yīng)用的能力，所以QT就這樣成為了正選讼溺。
然而是不是沒有遺憾楣号？早期在QT上做UI，實(shí)在是只知道在.ui文件中拖拖拖怒坯，然后一頓猛調(diào)炫狱，可是跑起來后返現(xiàn)，這里有一點(diǎn)點(diǎn)歪剔猿，那里也有一點(diǎn)點(diǎn)不準(zhǔn)確视译。所見即所得的編程方式再一次極大降低了應(yīng)用開發(fā)的門檻，碼獸們已經(jīng)不需要知道組件是怎么畫出來的归敬，組件可以響應(yīng)的按鍵事件是怎么被系統(tǒng)拋出來酷含，然后一路不迷失直奔目標(biāo)到達(dá)組件這里的，只需要拖動(dòng)組件汪茧，添加信號(hào)椅亚，或者像MFC一樣雙擊，填寫callback陆爽。但所見即所得的編程方式什往，也使得在需要對應(yīng)用展示做精細(xì)化調(diào)整時(shí)，從內(nèi)心出發(fā)的無能為力慌闭。
所以QT引入了qss别威，這實(shí)在是福音，在.ui文件中擺放控件的大概位置驴剔，不需要理會(huì)控件的具體樣式與內(nèi)容省古，也不需要理會(huì)控件的響應(yīng)式交互，然后到你的qss丧失，定義控件的樣式豺妓，與響應(yīng)式交互，簡直完美布讹×帐茫可是.ui與qss的組合也有大缺點(diǎn)。qss是一個(gè)css的語法模仿描验，然而這個(gè)語法模仿的意思白嘁，指的是qss僅僅語法模仿css，在使用方式上膘流，qss與css有相當(dāng)大的區(qū)別(也可能是我沒有解鎖qss的正確玩法)絮缅。css中的繼承體系鲁沥，引用體系，在qss中完全沒有體現(xiàn)耕魄，qss只是提供了一種用配置文件定義.ui文件中控件樣式的方式画恰。控件樣式中頻繁會(huì)使用的常量如顏色吸奴、字體等允扇，qss中并不能做常量定義，何其悲傷奄抽，當(dāng)我想修改一種字體或者某幾個(gè)屬性共用的屬性蔼两，不得不修改多個(gè)地方，以保證展現(xiàn)上的協(xié)調(diào)逞度。我想QT大概是想以QWidget的繼承體系额划，覆蓋qss中的繼承體系，然而對于習(xí)慣與css的碼獸來說档泽，這太隱晦了俊戳。
.ui和qss的結(jié)合還有致命缺陷：無法只做層疊UI。.ui中可以添加DockWidget馆匿，然而此Dock并不表示我可以浮在任何人上方不占用parent的空間抑胎，此Dock是要占用空間的，此Dock會(huì)將parent中的其他控件擠壓渐北，然后把自己固定在邊上阿逃。這對于只做像Word的菜單欄一類的應(yīng)用，確實(shí)是利好赃蛛，然后我們還有很多浮動(dòng)的彈出菜單恃锉，既需要Dock在邊上，又不能占用parent的空間哇呕臂！所以在這種情況下破托，C++出場了。
所以用QT開發(fā)應(yīng)用的正確姿勢應(yīng)該是：.ui做大概布局歧蒋，qss定義控件樣式土砂，C++實(shí)現(xiàn)復(fù)雜效果。
