Hey, there is a lot of interesting points in all these answers; some
similars, some not.
Maybe a good way forward would be to try to pinpoint the problems more
precisely with an online platform such
as http://en.arguman.org/ ? Or even just some kind of google doc...
Starting from there would maybe make it easier for the Qt devs to weigh the
"for" and "against" for the stuff that is often mentioned ?
Instead of having to find specific arguments in 45 mails...
And then open some paths for contributions to try to alleviate the
My 0.0005 cents
On Wed, Sep 21, 2016 at 1:53 PM, Jason H <jh...@gmx.com> wrote:
> > 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
> > language and the "code-behind" class hierarchy of UI elements are
> > absolutely equivalent 1st class citizens. Anything you can do in XAML,
> > can also do in the C# code-behind, whether it be creating controls,
> > changing their properties, altering layouts, etc. Likewise in
> > I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc
> > 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
> > "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++
> > 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
> > 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
> 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 mailing list