[Interest] Creating Qt Quick controls from C++
Rob Allan
rob_allan at trimble.com
Thu Jul 7 23:52:41 CEST 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160708/4702f6c4/attachment.html>
More information about the Interest
mailing list