> I also can't help making a comparison 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 unfortunate that Qt Quick doesn't take this approach, and that the > "code-behind" experience is so limited. One reason that I've heard why it > might have been done this way is that a rich and fully public C++ interface > may have hamstrung the developers too much, as there would be constant > breaking changes from one release to the next. If that's true then I guess > I understand that, but I would still rather put up with a rich C++ > interface that had breaking changes at new releases, than the relative > limited C++ interface we have now.
I'm not sure I follow. Declarituce UI is in. QML, React (+JSX) give you decaritive layouts. It convergent evolution of stucture±properties+code XAML, WPF, Qt Widgets all have structure and properties but no code. You've got to create the objects then in another context, assign code to them. If you are taking about how QQuickItems wrap C++ my understanding is that's because of the scene graph. My perspective is that the C++ side is better before I'm always having to drop from QML to C++ to expose stuff for QML. So I really don't understand your issue? _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
