If your app is for desktop only, I suggest you go with Widget instead of Qt Quick.
Sure Qt Quick has many advantages but for desktop only software it still lacks major features, for instance Qt Quick Controls 2 does not handle mouse hovering (e.g Buttons will not highlight when the cursor is over) and Qt Quick Controls 1 does not handle keyboard focus properly (e.g you cannot press 'space' to toggle a check box, https://bugreports.qt.io/browse/QTBUG-47658 ). Also as you already spotted the public C++ API fro Qt Quick and the Scene Graph is very limited*. So you will need to generate QML from your C++ code and then run it through the QML engine to create your GUI, if you choos to go this way. * you can't even create a C++ "QuickButton" class derived from QQuickItem with Qt public API as you have nothing to easily draw text on the SceneGraph Br, Benjamin 2016-07-07 23:52 GMT+02:00 Rob Allan <rob_al...@trimble.com>: > I'm part of a team that is looking at migrating an existing Windows C++ app > to Qt. The first decision is whether to use Widgets or Qt Quick. Since Qt > Quick is newer, shinier, faster, etc, that seems like the obvious choice. > However, for reasons that I won't go into here, the vast majority of forms > in our app are built dynamically in code. This kind of approach seems easy > enough with Widgets, but looks like it could be difficult, or even > infeasible, with Qt Quick. That's because the preferred way of creating Qt > Quick layouts is using QML, and while there is an object model backing that, > my impression is that this object model is not designed to support > heavy-duty creation and manipulation of layout elements. For example, while > QQuickItem is documented, none of its derived classes are, and I believe > their interfaces may be private - so the only way to manipulate items is > using a generic "setProperty" syntax. And while there are a few articles > around that talk about accessing the Qt Quick model from C++, such as this > one > [http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c], > they tend to use snippets of QML to get the job done in a rather hacky way, > and make various comments about the perils and pitfalls of trying to > manipulate the model from code. > > I can't help comparing this with two other popular layout frameworks: > WPF/XAML, and Android/AXML. In both of these worlds, the markup language and > the "code-behind" class hierarchy of UI elements are absolutely equivalent > 1st class citizens. Anything you can do in XAML, you can also do in the C# > code-behind, whether it be creating controls, changing their properties, > altering layouts, etc. Likewise in Android/AXML, I can (if I choose) create > FrameLayouts, RelativeLayouts, TextViews, etc in code, and arrange them and > manipulate them any way I like, as an alternative to creating an AXML > designer layout. > > It seems very unfortunate that Qt Quick doesn't take this approach, and that > the "code-behind" experience is so limited. > > Am I missing something here? Assuming I'm not, are there any plans to make > the Qt Quick class model more "open", with full documentation and public > interfaces for all relevant properties and methods? > > Thanks, > Rob > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
