Hi, Assuming V8 goes into QtCore (and even if it does not), would it be fully wrapped into a QtV8 API, or would symbols be exported?
If the latter, what happens if in two years IonMonkey, JSC or a new player is 10 times better than V8? Either stick to V8 or move to Qt6 to break ABI? Given the current development frenzy around Javascript engines, how tightly tied to a particular player can Qt afford to be? V8 is 3 years old, Qt4 is 6 years old and it will be 1 year before Qt 5.0 is out. Assuming Qt5 has the same lifespan as Qt4, is betting on V8 for the next 7 years a wise decision? On Mon, Sep 5, 2011 at 10:30 PM, <[email protected]> wrote: > 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 > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
