Hi Robin, > Why does it need to be? I have never needed to subclass QQuickControl, > personally, so I have never brought this topic up.
For the same reason all other controls from QC2 do subclass it. If you want to participate in mechanisms ( like font/locale/palette propagation ) that are implemented in this base class, you have to. > There is a cost, yes. But I would say it's more a cost/benefit tradeoff. > Faster prototyping and development cycles at a cost of requiring some of > your resources to munch on. Please allow me not to respond: I would like to avoid ending up in yet another QML vs. C++ discussion. > Anyway, wrt direction, I assume you are hinting at a scenegraph that is > less tied to QtQuick. No, the scene graph is already a standalone module with a well designed public API: many thanks to the authors. Its API could be more comfortable and the existing set of nodes is underfeatured, but in general I have not much to complain. Almost everything is about the C++ classes of the various Qt/Quick modules. The majority of them is designed with having QML as the one and only use case in mind. I'm also not happy about how the scene graph is used inside of those classes, because it substantially contributes to the memory and startup performance problems of Qt/Quick. It took me some tome to get those things under control, but in the end it was possible without having to patch Qt code itself. > If you are volunteering ... I am - and you can already see more than 50K lines of code from my efforts. Uwe _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
