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