RCViewer最终选择QT作为应用框架，到今天为止，我认为这一次技术选型并没有错，一半来自于我对现有开发进度与实验结果的掌控和满意度，另一半来自于我惊喜的发现，最伟大的先驱竟然也是QT开发的，这一下子背书了QT可以开发大型应用的能力，所以QT就这样成为了正选。
然而是不是没有遗憾？早期在QT上做UI，实在是只知道在.ui文件中拖拖拖，然后一顿猛调，可是跑起来后返现，这里有一点点歪，那里也有一点点不准确。所见即所得的编程方式再一次极大降低了应用开发的门槛，码兽们已经不需要知道组件是怎么画出来的，组件可以响应的按键事件是怎么被系统抛出来，然后一路不迷失直奔目标到达组件这里的，只需要拖动组件，添加信号，或者像MFC一样双击，填写callback。但所见即所得的编程方式，也使得在需要对应用展示做精细化调整时，从内心出发的无能为力。
所以QT引入了qss，这实在是福音，在.ui文件中摆放控件的大概位置，不需要理会控件的具体样式与内容，也不需要理会控件的响应式交互，然后到你的qss，定义控件的样式，与响应式交互，简直完美。可是.ui与qss的组合也有大缺点。qss是一个css的语法模仿，然而这个语法模仿的意思，指的是qss仅仅语法模仿css，在使用方式上，qss与css有相当大的区别(也可能是我没有解锁qss的正确玩法)。css中的继承体系，引用体系，在qss中完全没有体现，qss只是提供了一种用配置文件定义.ui文件中控件样式的方式。控件样式中频繁会使用的常量如颜色、字体等，qss中并不能做常量定义，何其悲伤，当我想修改一种字体或者某几个属性共用的属性，不得不修改多个地方，以保证展现上的协调。我想QT大概是想以QWidget的继承体系，覆盖qss中的继承体系，然而对于习惯与css的码兽来说，这太隐晦了。
.ui和qss的结合还有致命缺陷：无法只做层叠UI。.ui中可以添加DockWidget，然而此Dock并不表示我可以浮在任何人上方不占用parent的空间，此Dock是要占用空间的，此Dock会将parent中的其他控件挤压，然后把自己固定在边上。这对于只做像Word的菜单栏一类的应用，确实是利好，然后我们还有很多浮动的弹出菜单，既需要Dock在边上，又不能占用parent的空间哇！所以在这种情况下，C++出场了。
所以用QT开发应用的正确姿势应该是：.ui做大概布局，qss定义控件样式，C++实现复杂效果。
