On Tue, Sep 13, 2011 at 3:51 AM, aaron.kenn...@nokia.com wrote:
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.
Keeping 100% compatibility is a requirement even with the break to Qt5?
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, gunnar.sle...@nokia.com 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, gunnar.sle...@nokia.com wrote:
The merge will happen tomorrow morning, Oslo time.
On Sep 5, 2011, at 11:41 AM, ext gunnar.sle...@nokia.com 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, 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
