Hi, here comes the mail that I promised on the weekend. Let the flamewars begin!
More seriously, I have been playing with the idea of moving both our basic script integration (QJS* in the declarative module) as well as the QML engine into QtCore. As I outlined before, I consider it vital for Qt's success going forward that we move QML into the center of what we do with Qt. The classical widget model we have been successfully using for so many years has reached it's limits and will not carry us forward any longer. I have so far not heard a single person who seriously tried using QML and would want to go back to Qt's classical way of building user interfaces. But QML itself is not bound to graphical user interfaces. It's a generic declarative language that could just as well be used for many other, non graphical tasks. Having this powerful engine available everywhere will open up many possibilities. At the same time JavaScript is also getting more and more used, and there are nowadays many developers that do want to do as little as possible in C++. With the speed that modern JS engines such as V8 have reached, this is also possible even on lower end systems. The current split between Qt's object model living in one place and the QML/JS engine in another has in Qt 4.x lead to suboptimal implementations of the C++/JS bridge. Moving them into the same library gives us many more possibilities to align the object models and really get the best performance out of the binding engine and the bridging code between native and C++. Getting as much as possible performance out of this will be crucial to QMLs (and thus Qt's) success. It would longer term also allow things such as using property bindings from C++. This would allow app developers to save a lot of glue code. Connecting signals to a piece of JS code also becomes possible (yes, lambdas solve that problem to some extent as well). As a side effect, this could also open up a few possibilities to use implementations inside V8 in Qt. So far options are the RegExp engine, dtoa, strtod code. This would reduce the size of the total Qt stack, something that is important on many platforms where Qt is not preinstalled. We could also solve certain pieces like proxy autoconfiguration without requiring plugins that then pull in the JS engine anyways. There's two main downsides I can see: * People doing daemons/servers with Qt might see the JS engine as problematic. But if not used it doesn't really add any runtime overhead, so I wonder how big of an issue this would be in practice. * V8 is not yet working on some CPU architectures that Qt 4.x supports. This sounds more severe, but if we get MIPS support for V8 (it's actively being developed and it looks like it'll be there before we release 5.0), the remaining CPU architectures account most likely for less than 1% of the current Qt use cases. This is IMO not a good enough reason to hold the other 99% back. Comments? Cheers, Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
