使用Qt开发跨平台桌面应用时，应该选择widgets还是qml？

如果是桌面平台，劝题主还是使用Widgets。也别搞QML为主，widget为辅这一套了。不够麻烦钱的。不知道 这么推荐是从哪方面考虑的。而我的理由如下：

1，QML只适合写界面。绝大部分的逻辑还是要靠C++的，而QML和C++通信部分是蛋疼的（不难，但是确实蛋疼，各种Invoke）。假如你一部分逻辑用js，一部分用C++，到后期维护起来，估计就想买后悔药了。

2，QML成品控件太少，稍微复杂的控件都要你自己写。没有第三方控件。而widgets有非常多的选择。

3，QML没法调试(删除)，开发效率没有吹的那么高。大多情况下，你面对的其实是一个TXT文档，而运行效率则有点呵呵（内存/CPU你可以写个例子看看）。

更正：QML是可以调试的。

4，如果你想用QML做移动平台的开发，那你要考虑到跟系统的原生样式匹配问题。

真心不明白QML的定位。

－－－－－－－－
问：

请问，您是怎么得出“QML没法调试”，“开发效率没有吹的那么高”，“运行效率有点呵呵”，“QML成品控件太少”，“不明白QML的定位”这些论点呢？况且您在2015-11-04年编辑的时候，Qt已经很好了，Qt都已经更新到Qt5.5.1的版本了，您是怎么知道QML不可以调试的呢？

答：
0，QML是可以调试的。我的错。

1，开发效率问题高不高的问题：
QML是只适用于做界面，写复杂逻辑还是不够的。最终产品必须C＋＋（业务逻辑）和QML（界面）一起写。而其成品控件，第三方控件肯定没有widgets多，那么开发效率从何谈起高呢？

2，运行效率问题。
这个自己写个例子即可看到。最初我们是实用的Qt4.8，Quick1，内存占用10倍于widgets。Qt5 也至少5倍于widgets。当然，现在大家都不怎么介意内存占用了。所以看具体场景吧。

3，不明白QML的定位。
看起来Qt是想使用Quick统一天下（桌面＋移动端）。这个梦想有点远大，最终能否实现么，从目前来看，没戏。移动端是肯定没戏，因为除了能“跨平台”，没有任何优势，反而到现在都支持不完善，不少bug。而跨平台特性，它是连React Native都干不过的。到现在为止移动端使用quick进行开发的寥寥无几（请试举哪些移动端重量级的产品是Qt做的？）。桌面端优势又不比widgets明显。那他的定位是什么呢？

4，QML的优势和适用场景。
QML／Quick支持GPU加速，这是非常棒的特性。做动画界面很高效，比较适合做花哨的界面，在普通的桌面程序开发中，这个优点并不突出。

总结：真希望Qt的团队，能够放弃移动端（目前的路线肯定干不过Hybrid／Native路线了），全力以赴支持Quick桌面端，这样还有可能和Electron一战，否则，Qt沦落到只被用来做工控嵌入开发都不一定啊！