I'm fairly new to Qt (a few months), but am already very impressed by its
power and overall quality. I'm also super impressed that the user-base is
being asked about what they don't like - so many providers of tools or
services just don't want to hear this stuff! So much kudos to the
developers for even asking this question.

My biggest gripe is that the Qt Quick object model seems to be much more
poorly supported in C++ than it is in QML. For example, in C++ you really
only have access to QQuickItem - none of its derived classes are
documented, and their interfaces are private - so the only way to
manipulate items is using a generic "setProperty" syntax. This is in stark
contrast to QML where all the QML types, methods and properties are
available to you. When you have an app that builds most of its UI
dynamically from C++ code (as ours does), this makes life pretty difficult.
I guess this is one area where widgets would score better than Qt Quick
(but we still prefer Qt Quick for a number of reasons).

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.

Interest mailing list

Reply via email to