----- Original Message ----- > From: Bjørn Erik Nilsen <[email protected]> > On 9/8/11 3:33 PM, ext Jason H wrote: >> I wholly disagree. It is the core of *your* Qt5 apps, but probably > won't >> be mine. >> It is also a poor decision to say "let them eat cake" and by cake > I mean >> Qt4. > > The root of the problem is that we are not aligned on the vision for Qt5. > > If the vision for Qt5 is to create a paradigm shift and move QtQuick to > the core of all future Qt applications, then the only sane option is to > move JS into QtCore. > > If we disagree on the vision, we better start figuring out what our > vision should be so that we can all work towards the same goal.
I would say that in general the community disagrees with you, especially the embedded community, and most likely the commercial Qt community too. I think the general consensus is that there is no problem with your stated "vision" supposing that applies to GUI applications only. However, the Qt community is a lot larger than GUI applications. Even in the GUI community, I would be quite surprised if the majority where even close to using QML/JS right now; something that with Qt4 is problematic per licensing for commercial users (LGPL only code for the JS - yeah, that's been quoted as being fixed for Qt5). And yes, there are still a lot of applications that require integrating the standard QWidget model. For example, I have an application that draws points to a QWidget-derived object. I have a very hard time seeing how I would be able to do the same thing under QML, especially at the performance levels I need. Yes, I'm planning on eventually drawing to a QPixMap (I have a lot of work and research to do before I can do that), which may make it easier but still requires the QPainter methodology. I'm sure I'm not alone in that requirement. Ben _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
