[Interest] Creating Qt Quick controls from C++

[Rob Allan]

Hi Xavier,

Thanks for your thoughts on this. Yes, I think I understand the way that Qt
Quick and QML can be used to make layouts that are dynamic and updatable
depending on property bindings. However, I think I'm talking about another
level of customization - namely, forms that are constructed entirely at
runtime from application logic. This is way more than just showing or
hiding fields, changing colors, or some of the things that I suspect are
typically done with bindings, slots and signals. In our case we have dozens
- in fact hundreds - of forms, some user-definable, that are built at
runtime, and it is just not feasible for us to build these ahead of time as
static QML files.

I still contend that Qt Quick does not make this as easy as it could, if
the entire QML object tree could be created and/or manipulated from C++ -
as is the case in the other UI frameworks I mentioned.

Regards,
Rob

On Fri, Jul 8, 2016 at 11:56 AM, Xavier Bigand <flamaros.xavier at gmail.com>
wrote:

> 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/20160713/63c02eb5/attachment.html>