On Mon, Oct 10, 2011 at 6:39 AM, Stefan Majewsky <[email protected]> wrote: > On Fri, Oct 7, 2011 at 9:13 PM, <[email protected]> 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.
I think this opens a pandora box just like QGraphicsProxyWidget. People will expect to put anything inside and hope that it will work and get angry when it doesn't (not knowing why it can't work). But if it's easier and less error prone that QGraphicsProxyWidget then yes perhaps it's a good step. QWidget->QML is not a trivial port though so at some point people will have to move the code from C++ to QML. I think we should focus on having a good Qt Component for desktop. > > 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. > Thing is that most of the logic could be written JS. I was wondering if that's better to have an intermediate solution rather than thinking if it could be worth to re-think the entire thing (for simple kdegames of course). > Greetings > Stefan > _______________________________________________ > Qt5-feedback mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback > -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
