On Mon, Oct 10, 2011 at 1:23 PM, Alexis Menard <alexis.men...@openbossa.org> wrote: > 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->QGraphicsView is (or at least feels like) an entirely different porting story than QWidget+QGraphicsView->QtQuick for two reasons: 1. QGraphicsView and QtWidgets have blatantly different usecases (user interface vs. visualization), while QtQuick is a "UI Construction Toolkit" (the "uick" in "Quick") just like QWidgets. 2. Porting QWidget to QGraphicsView can happen from inside to outside (usually single widgets with custom paintEvent() have been converted into a QGraphicsView) while, from what I can currently project, porting to Qt Quick while happen from the outside, starting at the mainwindow level, while leaving the contained QWidgets (or QGraphicsView) intact during the porting. > QWidget->QML is not a trivial port though so at some point people will > have to move the code from C++ to QML. That's why I want to do it step to step, and again, starting at the standardized chrome layer (mainwindow with menu, tool, and status bars) looks like the obvious direction, not only because this is the point where most needs to be changed in touch-friendly ports for mobile. > 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). We have a handful spare-time developers on a codebase of 260 KLOC, and you're asking to switch languages? No, thanks. As I said numerours times, I really like the idea behind Qt Quick and QML. And I agree that many things can be done in JavaScript very well. But we're talking about existing code here. So there must be a huge improvement if you want us to just consider using JS for the game logic. But there is no improvement: It's not faster, it's not simpler (just because of a direct port to JS), but on the other hand the bug will definitely introduce regressions. That hasn't to do with the quality of the involved technologies and/or people, it's simple math for N = 260 KLOC. My point is, you should stop wondering about people who have never used Qt Quick complaining about Qt Quick if you tell people to rewrite their business logic in JS. Of course these are not your exact words, but many people seem to take it like this, and in some way I understand them. Greetings Stefan _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
