On Sep 20, 2016, at 22:52, Rob Allan <rob_al...@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.  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.)

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?  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.)  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?

Some people think that making more scene graph stuff public is also not worth 
the trouble, and would tie down existing internal APIs too much.  Especially 
when it comes to text rendering.  But in the meantime you can use private APIs 
when public ones are missing.

If you just want to write custom items which populate scene graph nodes, and 
still use QML in general, it’s already not so bad (as long as your custom items 
don’t include text).  If you want to mix OpenGL and QtQuick in layers, no 
problem.  (Qt3D made sure of that.)  

> 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.

If you are really OK with that, then use private APIs.  Probably better to 
start with 5.8 since there were big changes from 5.7 to 5.8.

Interest mailing list

Reply via email to