2011/10/10 Adriano Rezende <adriano.reze...@openbossa.org>: > On Mon, Oct 10, 2011 at 6:39 AM, Stefan Majewsky > <stefan.majew...@googlemail.com> wrote: >> On Fri, Oct 7, 2011 at 9:13 PM, <lars.kn...@nokia.com> wrote: >>> Putting QWidgets on top of/inside the scene graph is doable without >>> performance regressions. We haven't done it though. >> >> Personally, I consider such an effort top priority if you want people >> to migrate from QtWidgets to Qt Quick 2. >> >> At kdegames, we have 40 applications which are nearly all based on >> QGraphicsView. Reality is that GUI and logic are not separated >> properly; the views, scenes and items contain most of the logic. >> >> It's simply not feasible to start porting these towards a >> scene-graph-based interface unless there is a way to embed the >> QGraphicsView into the chrome provided by Qt Quick 2. > > Supporting QWidget or QGV on top of QtQuick2 would be a huge mistake > IMO. It would be a political movement that will not end up well in the > long term. If one wants to use QML, they must use it in the right way, > avoiding creating a Frankestein application. We already suffered with > QGraphicsProxyWidget for no real gain. QtQuick2 needs to provide all > features to support all the real use cases without creating a > bridge/portal that could summon old demons.
But that's the only sane and feasible way of porting big QWidget-based applications to QML. One would do it iteratively, for example, top-down, first putting the whole QMainWindow into QML context, then start rewriting different parts of it in QML. I guess it's quite obvious that this way is much better, much more manageable, doable by small opensource teams, feasible for more-or-less mature projects, and such. -- Georg Rudoy LeechCraft — http://leechcraft.org _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
