[Interest] Creating Qt Quick controls from C++

[Xavier Bigand]

If some of your forms are user defined, maybe you can take a look to the
QML editor code integrated in QtCreator. I don't know if it's rendered with
QML or something else, if it's in QML then the way it is done should be
correspond to what your a looking for.

I don't know why Qt doesn't support property bindings in c++, for our
project we have implemented it to solve a lot of issues we had because of
dependencies in our algorithms.
Maybe it will come in a futur with public APIs to manipulate QML objects
from c++.

Have a good day.

2016-07-13 6:37 GMT+02:00 Rob Allan <rob_allan at trimble.com>:

> 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
>>
>
>


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