06.09.2011, 00:30, [email protected]: > 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. >
Hi Lars, Qt was known as a C++ framework. What the heck JavaScript is doing here in QtCore? -- Regards, Konstantin _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
