Re: [Qt5-feedback] Heads up: Merging refactor branches into master
Looked again, still can't see a problem. Cheers, Lars On 9/14/11 10:50 PM, ext Stephen Kelly steve...@gmail.com wrote: lars.kn...@nokia.com wrote: On 9/14/11 10:13 PM, ext Stephen Kelly steve...@gmail.com wrote: gunnar.sle...@nokia.com wrote: The merge will happen tomorrow morning, Oslo time. The refactor branch should be merged again. There is one commit in the refactor branch which is not merged into master, though it has been cherry picked. Tools like gitk then show that refactor has not been merged into master. I don't see this. Yes we have two merges close to each other, but gitk shows the history just fine. Cheers, Lars stephen@hal:~/dev/src/qtbase{master}$ git branch --contains origin/refactor stephen@hal:~/dev/src/qtbase{master}$ git branch --contains origin/refactor^ * master Also run gitk origin/refactor and compare the branches metadata for the branch and the commit before it. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
Frederik Gladhorn wrote: Hi Stepen, Hi, You are right, one patch was committed to refactor after the merge by accident. But then also cherry-picked into master. (5842e7e97efa80a9a8442e07f9898c32a4447102) Yes, I wrote that in my initial email. My point was that when I checked if refactor had been merged into master the 'standard/normal' way, the tool told me it hadn't been, which is correct because the extra commit was cherry-picked. If you don't want to fix that, that's your call I guess, but it's a simple fix. Thanks, Steve. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
gunnar.sle...@nokia.com wrote: The merge will happen tomorrow morning, Oslo time. The refactor branch should be merged again. There is one commit in the refactor branch which is not merged into master, though it has been cherry picked. Tools like gitk then show that refactor has not been merged into master. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
On 9/14/11 10:13 PM, ext Stephen Kelly steve...@gmail.com wrote: gunnar.sle...@nokia.com wrote: The merge will happen tomorrow morning, Oslo time. The refactor branch should be merged again. There is one commit in the refactor branch which is not merged into master, though it has been cherry picked. Tools like gitk then show that refactor has not been merged into master. I don't see this. Yes we have two merges close to each other, but gitk shows the history just fine. Cheers, Lars ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
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. Hi Aaron, ok thank you for the clarification. I think the message would have been better to use the new V8 Qt bridge instead of linking directly with V8 (which is a massive work). Please could you point me on some documentation for the new JS bridge? I have googled but nothing. Best regards, Sylvain ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
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
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
ok thank you for the clarification. I think the message would have been better to use the new V8 Qt bridge instead of linking directly with V8 (which is a massive work). Reading again the email from Gunnar, he told exactly that but I misunderstood. My apologies. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
On Tuesday 13 September 2011 10:42:53 Gábor Lehel wrote: 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? Yes, keeping as much source compatibility as possible, in order to make possible to upgrade projects with millions of lines of code. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
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 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 Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback