用于GUI的Qtdevise器C ++或QML
我知道在QT中使用QML是相当新的，我想知道是否应该使用QTDesigner或QML来devise我的应用程序。 我将使用一个MVC模式，如果我使用QML作为GUI，我主要担心的是可能不容易在我的C ++应用程序的内部进行集成。
随意给你的个人build议，我将不胜感激。 谢谢！
QML主要用于移动平台。 由于其年轻化以及对各种平台界面惯例的关注，因此缺lessbutton和combobox等标准控件（但请参阅“ 组件”项目）。 如果您使用手机，或者您的用户界面需要高度定制的视觉风格，QML 可能值得考虑。 准备在devise自定义控件上做很多额外的工作。 在我看来，集成QML和C ++仍然相当粗糙。 我个人build议只在更简单的应用上使用QML，只能在移动平台上使用，而且只能使用JavaScript。 在适当的情况下，我可能会考虑用C ++编写自定义的QML元素。
Qt的C ++ API不会很快消失。 它的devise也考虑到了桌面，并且在桌面平台上可以更好地满足用户的期望。 如果你在桌面上，我会build议坚持C ++和Designer。 即使QML成熟了一点，对于大多数桌面应用程序来说也可能不是合适的解决scheme。
更新！
看起来事情正在开始改变 。 我还没有尝试过新的组件，文档看起来有点稀疏（或者至less在某种程度上），但这最终可能会消除在桌面上使用QML的最大障碍。 从长远来看，这是否会得到支持仍有待观察，但如果您愿意接受早期采用者的风险，我认为QML现在可能是桌面应用的可行select。
值得尝试一下QML来testing它是否适合你的需求。
如果您使用dynamic接口和animation构build高度自定义的用户界面，则QML适合这项工作; 如果你正在构build一个传统的桌面应用程序，那么你可能会想要坚持使用Qt C ++ API。
关于QML和C ++之间的集成，QML被devise为可以很容易地与C ++代码集成，许多QML应用程序使用某种C ++后端。 将C ++对象注入到QML界面是很简单的，或者在C ++中编写自定义的QML元素。 看看http://doc.qt.io/archives/qt-4.7/qtbinding.html和http://doc.qt.io/archives/qt-4.7/qml-extending-tutorial-index.html 。
上面的答案错过了一件事是，QML对业务逻辑（如果需要的话）具有额外的优势/劣势。 我目前正在为桌面构build一个（小到中等）大小的应用程序，现在我的（2）alpha用户可以享受它。 我对框架的performance力印象深刻，我能多快地完成并testing。 总而言之，我发现与RAD编辑器（devise器）相比，它的工作速度更快，当我正在执行像盘旋/validation等恼人的事情时，我喜欢将JavaScript作为UI的后备工具。
我认为这是一个与你的语言有多舒适的问题。 如果C ++是你的“去”语言，你可能会喜欢devise师。 如果你来自networking（坦白地说，我是一个Java EE工程师/ MVC .NET开发人员，他们做了很多前端工作），你会发现它更加快速。
它也允许用户期望这些日子的一些响应。 总的来说，我会给它一个很大的优势。 试一试 – 你可能会在同一个时间框架内相当烦恼而烦恼。 我仍然对一些事情感到愤怒（特别是FileIO），但我一直以我在桌面上很less做的方式享受GUI的一面。
