[Interest] What don't you like about Qt?

[André Pönitz]

On Wed, Sep 21, 2016 at 05:42:44AM +0000, Shawn Rutledge wrote:
> 
> On Sep 20, 2016, at 22:52, Rob Allan <rob_allan at trimble.com> wrote:
> > 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).
> 
> It’s intentional though: we don’t have to worry about binary
> compatibility that way, or even source compatibility to an extent -
> it’s only the QML API that we have to keep compatible.

I believe quite a few of the people asking for C++ access to Qt Quick
are perfectly aware of the state of the current implementation, at
least to a degree to understand the desire to not set access to it in
stone. But, after weighing pros and cons, they came to the conclusion
that having *any* "official" access, even one that does not come with
any binary or even source compatibility guarantees is more valuable
than being restricted to QML.

It is beyond me how one can hide behind the "we can't/do not want to
guarantee compatibility" argument when people explicitly declared *for
years* that they don't care about such for that particular scenario.

> We don’t strictly even need PIMPLs (and I wonder if we could get any
> speedup or memory savings if we didn’t have them), but most of the
> classes have them anyway.  I guess maybe the original authors were
> anticipating that the C++ API might become public some day, so they
> have private objects just in case.  But making more of them public is
> the same as locking the API and reducing flexibility.
>
> If there are any API warts, they become difficult to fix after that.
> (E.g. the restriction that we can neither add nor remove virtual
> functions is downright crippling sometimes.)

There is no API lock if there is no compatibility promise. People ask
for the API, not the promise. Making it accessible with the usual _p.h
No guarantees/"We mean it." would not restrict any development,
and make a few people happier.

> I think that there should be a more extensive C++ interface to the
> scene graph itself.  People complain that QtQuick is bloated: you
> have to create too many QObjects and too many bindings; so what’s the
> difference if you do it in C++ instead of QML?

Come on. Yes, it is bloated, and this particular problem won't go away
by making it accessible from C++. But that's absolutely not the only
point, not even the most important one. On my personal "more important"
list is at least access to a plethora of standard tools (code checkers,
profilers, debuggers, refactory tools) when using C++, the ease of
maintenance of a uniform code base where simple refactoring like
renaming "just works", compile time reality checks, and easier
integration in large projects where Qt is just one out of many building
blocks.

> But the scene graph nodes are fundamental and inescapable - hopefully
> not as bloated either.  (Why must they exist?  Because batching is
> fundamental to get good performance in OpenGL: you use a scene graph
> because you don’t want to make thousands of draw calls to draw the UI
> each time it changes.)

[I thought by now the prediction that OpenGL will be all that matters
in 2018 has been abandoned.  Not to mention that the sunny side of
OpenGL never extended to such mundane tasks like displaying text, and
that it probably would make sense to re-evaluate architectural decision
that were solely bases on that buried assumption.  But that's a
different topic to whine about]

> If you don’t like Javascript, there isn’t yet
> a good way to omit the whole engine from your build; but I think
> there should be, and then it might be practical to use the scene
> graph directly.  But that would be a static scene; to make it dynamic
> and interactive you'd have to re-invent some difficult things: event
> delivery, (most types of) animations, layouts, etc.  If you want to
> bind another language to the scene graph though, and use
> different/functional/more-elegant paradigms for the interactive
> stuff, it’s not a bad place for the boundary, right?

Probably not. A least this sounds like a reasonable starting point.
Also, without compatibility promises, not getting the boundary
right in the first attempt is not fatal.
 
Andre'