On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote: >> From my experience with the QSkinny project I'm tempted to say that it >> would even be possible to implement the Qt/Widgets API on top of >> Qt/Quick core. > > So long as you ditch the paint event for most of the classes, leaving > the QQuickPaintedItem (or whatever it's called) only for the cases where > it's truly needed.
When implementing widgets ( inside of Qt or 3rd party widgets like in Qwt ) it is mostly a matter of handling resize and paint events. The corresponding calls for Qt/Quick are QQuickItem::geometryChanged and QQuickItem::updatePaintNode(). So when trying to migrate widgets into being QQuickItems you would have to send QResizeEvents inside of geometryChanged and QPaintEvents inside of updatePaintNode. All of these "widgets" could have an FBO ( or QPixmap ) inside and creating a QPainter on a them would result in drawing to this one. Then it would be possible to create a scene graph node from it. Of course I'm heavily oversimplifying, but this way you would at least get something running in a reasonable amount of time - even if this would downgrade the scene graph into being a texture cache. But it would be a starting point for migrating the implementation of updatePaintNode widget by widget. -- But does it make any sense to spend time on this: In the context of Qt 5.0, where the strategy was to replace Widgets by Quick Controls 1 - probably not. But QC1 has become a failed technology and QC2 is not targeting the desktop anymore. So all what Qt has to offer today for the desktop is good old Widgets - running on a graphic stack, that is not competitive anymore. So in the retrospective IMHO the wrong decision had been made. And for the future - no idea, is there already a strategy how to satisfy desktop users with Qt 6 ? Uwe _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
