[Interest] Creating Qt Quick controls from C++

[Xavier Bigand]

I think that our approche can be wrong, maybe you don't need to be able to
access to the QtQuick components from the C++. The best is to follow the
philosophy of QtQuick with the property bindings. You can expose variables
(properties) from your c++ to the QML and let the QML interact with them.
In QML you have everything to build the GUI dynamically, property bindings,
loaders,...
The c++ code have just to emit a signal when the property value changed,
and your GUI will be updated depending of your conditions in the property
bindings on the QML side.

We use that to create a custom GUI, that can be adapted to every screen
size (from mobile to desktop) be able to change GUI skins, language,...
without restarting the application. It's a major time development win,
because we can emulate the GUI we have on phone on desktop without
restarting the application (we simply change the c++ property that give us
the device type),...

And because we can't use the design due to the c++ dependencies, we add the
QML hot reloading when files are changing.


If you are looking to change our GUI library, removing our actual c++
dedicated to the interface creation shouldn't much harder than refactoring
it to fit the new API.


QtQuick is made to works with property binding, that it is not supported on
the c++ side by Qt. The only thing you can create on c++ side is new item
types by derived some existing.


2016-07-07 23:52 GMT+02:00 Rob Allan <rob_allan at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>


-- 
Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160708/b77384fb/attachment.html>