Hi, On 12/09/2011, at 11:04 PM, ext Sylvain Pointeau wrote:
QtScript should be using V8 and provide all the facilities of binding QtObjects... (it is using JavascriptCore if I remember well correct?) While this would be true in an ideal world, after much prototyping it was decided that porting the entire QtScript API to V8 and preserving its exact semantics was simply not possible. As a compromise, we have left the QtScript module untouched to preserve 100% compatibility for existing applications, and introduced a parallel API against V8 (the QJS* classes) that is similar enough that we expect most applications - and almost all new applications - to be able to move to it instead. While the V8 library itself is in QtBase, the QJS* convenience API is in QtDeclarative, although it may be moved prior to the release of Qt 5 (see the lengthy "QML/JS engine in QtCore?" thread). Cheers, Aaron V8 is another story, it requires a lot more stuff from the development.... What is the other Javascript interpreter you mentioned? Best regards, Sylvain On Mon, Sep 12, 2011 at 2:56 PM, <[email protected]<mailto:[email protected]>> wrote: On Sep 12, 2011, at 2:14 PM, ext Sylvain Pointeau wrote: > Hi, > > I am wondering why you suggested to use V8 instead of QtScript? > is it a module that will be dropped in a near future? There is already a JavaScript interpreter inside the QtBase repository, so why pull in another one if you don't have too? The QtScript module will not be going away, but as it looks today, we will not be investing heavily into it either. - Gunnar > > Best regards, > Sylvain > > On Mon, Sep 12, 2011 at 10:40 AM, > <[email protected]<mailto:[email protected]>> wrote: > The merge will happen tomorrow morning, Oslo time. > > On Sep 5, 2011, at 11:41 AM, ext > [email protected]<mailto:[email protected]> wrote: > > > Hi, > > > > We are getting closer to the point where we integrate the Qt refactor > > branch. What this branch does is that it separates most of Qt's desktop > > widgets along with a number of currently less actively developed modules > > into their own libraries, in accordance with the module maturity list we > > published earlier this year and in line with Lars' blog about the intent of > > Qt 5. The over all goal is to simplify our graphics stack, minimize our > > platform/device dependent layer (lighthouse integration) and make sure QML > > and OpenGL are prime citizens in Qt 5. > > > > These branches are not at feature parity with Qt 4.7 yet, and nor will they > > be for a quite some time. But we want to push the changes into the master > > codeline so that the structure we have mentioned in blogs and other forums > > gets visible in terms of code. > > > > Currently we have "official" support for single-window, QML 2 based on > > OpenGL on Linux/X11, Linux/XCB, Linux/Wayland and Mac OS X. There is some > > rudimentary support for the same setup on Windows, but it is still work in > > progress. Our stack works on top of Software Mesa (very slow), LLVMpipe > > (very fast) in addition to real OpenGL hardware (usually fastest). > > > > Standard widget based applications still works, but they are not our > > current priority. We will pick this up once the QML 2 stack is more > > complete. > > > > We're expecting to merge into master in 1-2 weeks time. > > > > What are the changes in practice? > > - code that use widgets need to add "QT += widgets" in their .pro file > > - code that includes <QtGui/QLabel> or similar needs to be updated to > > <QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does > > this for you. Run it in the root directory and you are done. > > - There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx > > which integrates tightly with lighthouse. To keep changes to existing code > > minimal, we decided to keep the existing libQtOpenGL classes pretty much as > > is without any changes, and rather introduce new classes in QtGui for the > > classes we wanted. > > - Printing support has been moved into its own library, libQtPrintSupport. > > We have a long term plan of creating a better printing API, covered > > inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951<http://bugreports.qt.nokia.com//browse/QTBUG-19951>, > > so we have spent some effort in removing the dependency on the current > > API's from the "Qt essentials". The API is unchanged. > > > > > > Can I expect any performance changes? > > - No. This is about removing a large chunk of code to make our stack > > simpler to maintain and to have smaller footprint. > > > > > > What can I plan for? > > - In new projects, see if you can use QML 2 instead of QWidgets. > > - In new projects, see if you can use QML 2 instead of QML 1. > > - In new projects, see if you can use V8 instead of QtScript. (QJSValue and > > QJSEngine classes in libQtDeclarative) > > - In new projects, see if you can use OpenGL functionality in QtGui instead > > of libQtOpenGL.so > > > > > > What does this means for you right away? > > - If you upgrade to Qt5 with refactor, you need to update the includes and > > add widgets/script/qtquick1 to your .pro files > > > > > > What does this means long term? > > - None of the existing libraries > > > > I hope this transition will be as painless as possible for everyone. If you > > have further questions, don't hesitate to ask > > > > - > > Gunnar > > _______________________________________________ > > Qt5-feedback mailing list > > [email protected]<mailto:[email protected]> > > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback > > _______________________________________________ > Qt5-feedback mailing list > [email protected]<mailto:[email protected]> > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback > _______________________________________________ Qt5-feedback mailing list [email protected]<mailto:[email protected]> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
