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_al...@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.xav...@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_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 >>> >>> >> >> >> -- >> Xavier >> > > -- Xavier
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
