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 Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
