Re: [Development] Adding new third party component three.js to Qt?
Hi Mark,
thank you for bringing this to my attention!
I hadn't noticed that the Qt 5.4 install doesn't have the documentation for
QtCanvas3D under Docs, while it does have documentation for QtWebView tech
preview. We're planning to do a Tech Preview 2 with Qt 5.4.1 as I've fixed
quite a few bugs that will be visible to most users of Canvas3D since Tech
Preview 1. I'll investigate why the docs are not building and try to sort it
out for 5.4.1 release.
Meanwhile you should be able to build the documentation yourself from the
QtCanvas3D sources with make docs. As I said, best option at this point is to
get the latest from https://codereview.qt-project.org/qt/qtcanvas3d as there
are quite a few bug fixes done since TP1.
Regards,
Pasi
From: development-bounces+pasi.keranen=theqtcompany@qt-project.org
development-bounces+pasi.keranen=theqtcompany@qt-project.org on behalf of
Mark Gaiser mark...@gmail.com
Sent: Friday, January 9, 2015 5:01 PM
To: development@qt-project.org
Subject: Re: [Development] Adding new third party component three.js to Qt?
On Fri, Jan 9, 2015 at 3:39 PM, Keränen Pasi
pasi.kera...@theqtcompany.commailto:pasi.kera...@theqtcompany.com wrote:
Hi Louai,
The changes required to the library were originally quite large. But
thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
wrapper classes to make e.g. Image loading look and smell like in HTML
land, the delta has been getting smaller and smaller. Here is a pretty
complete list based on quick compare between the R69 original three.js and
the Canvas3D port of the R69 release of three.js. There might be something
I’m forgetting to mention here. But as I said the delta has been getting
smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
some delta always as QtQuick is not HTML.
* We don’t have performance timers in Qt Quick JS, so the Clock class must
be modified to not use those.
* In some files the class is declared with syntax of ( function (THREE) {
blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
executing functions don’t seem to work, V4VM just refuses to load the
file. I haven’t been able to replicate this behaviour with a small
example, so probably it’s relates to some complex situation arising when
loading a large JavaScript file OR then there is some minute detail in
that self executing function that I can’t spot.
* Resizing of images has to be modified as that is usually done with HTML
trickery that doesn’t work at the moment with Canvas3D.
* Accessor functions defined in prototypes with:
get x() { return this._x },
set x(value) { this._x = value; this.onChangeCallback(); }
* Must be rewritten with the (older?) syntax of:
this.__defineGetter__(x, function(){return this._x;});
this.__defineSetter__(x, function(value){this._x =
value;this.onChangeCallback();});
* Canvas3DRenderer is new code, ported from WebGL. Main differences are to
do with initialization differences between Canvas3D and WebGL. Handling of
some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
(should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
place and function overloading should work). And I’ve wanted to support
the logging features of Canvas3D objects, by setting the .name attribute
of some objects so that when you turn on logging you can see what
UniformAttribute, what Shader3D object you are looking at in the logs..
Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
name in the renderer causes V4VM not to load the file, but again a minimal
example of this doesn’t have this problem so can’t replicate it). Again,
the delta should get smaller with WebGLRenderer, but I’d expect there to
always be some delta.
That is all the delta I can list quickly, if you are interested in details
just get the R69 release from three.js git and the stable branch of
QtCanvas3D port and do a detailed compare of those.
Reagrding this delta I’ve thought a bit how to reorganise the delta so
that it could live in a separate folder inside three.js. If I can make
that happen, then maybe it would be possible to get these few changes in
to three.js upstream and make it possible to always use the latest from
there as well if one so wishes. But that will require a bit more work on
V4VM I think before we’re there. E.g. Add support for binary file loading
with XMLHttpRequest and track down why those few anomalies occur when
loading self executing functions declared in the manner they are in
three.js so that the upstream code should run as much as possible
unmodified on top of Canvas3D with just the few changes we need in place.
Regards,
Pasi
On 08/01/15 12:54, Al-Khanji Louai
louai.al-kha...@theqtcompany.commailto:louai.al-kha...@theqtcompany.com
wrote:
On Wednesday 7. January 2015 06.03.14tel:2015%2006.03.14 Keränen Pasi
wrote:
Hi,
I¹d like to open the discussion on including
Re: [Development] GIMP QML exporter script (project not on Gerrit)
Hi Tuukka, No, it wasn't that at all, the documentation is what saved me. My problem stemmed from having committed a whole bunch of changes and then having to retro-fit Change-Id's etc (which meant a git learning curve for me) since I didn't initially consider making any changes (i.e. my git environment wasn't set up as per the Setting up Gerrit instructions). Had I not ended up in a situation where I had to work back to front, it would have gone a lot more smoothly. The only recommendation I have at the moment is perhaps to improve on the qtrepotools documentation (if it exists, I haven't been able to find it) and perhaps a pre-commit hook (I do not know if such a thing is possible) that could do some sanitizing up front? Thanks again for a spectacular framework! Kind regards, William. On 9 January 2015 at 09:35, Turunen Tuukka tuukka.turu...@theqtcompany.com wrote: Thanks, William. If some of the instructions were misleading, hard to find or inadequate, please let us know. Intention is to make it straightforward to contribute. In addition to your contribution we value your feedback for improving the instructions. Yours, Tuukka From: William Hallatt goblincod...@gmail.com Date: Friday 9 January 2015 07:02 To: William Hallatt goblincod...@gmail.com Cc: development@qt-project.org development@qt-project.org Subject: Re: [Development] GIMP QML exporter script (project not on Gerrit) Thanks for all the assistance folks. Finally managed to submit to Gerrit and sort out all the sanity bot's reviews :) Have a good weekend, William. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
-Original Message- From: development-bounces+sami.makkonen=theqtcompany.com@qt- project.org [mailto:development- bounces+sami.makkonen=theqtcompany@qt-project.org] On Behalf Of Keränen Pasi Sent: 7. tammikuuta 2015 8:03 To: development@qt-project.org Subject: [Development] Adding new third party component three.js to Qt? Hi, I¹d like to open the discussion on including the three library as part of Qt 5.6 and onwards. Mainly because this would give our users a better experience if we¹d bundle the right, tested version of Three.js together with the Qt version it was tested on. I¹ve been pushing the Qt Canvas3D component onwards and timewise it should be landing to Qt 5.5 release. The WebGL-like API (non-conformance tested) it offers is very low level and most users will not like to work on that level. To that end I¹ve ported the WebGL based Three.js scenegraph library available at http://threejs.org on top of Canvas3D. You can find the latest version from master branch at https://github.com/tronlec/three.js The reason for picking this particular library over others are: * It¹s one of the most active WebGL scene graph projects out there. * It¹s well done, with examples, API documentation etc. * It has excellent support form community in the form of tutorials, websites, discussion forums etc. * It is available under permissive MIT license: https://github.com/mrdoob/three.js/blob/master/LICENSE In Qt 5.5 we¹ll include a few examples that will have this library as part of the examples. The library will for now at least need some porting effort to make it run on top of Canvas3D as there are some HTML depencencies that need to be handled, plus V4VM has a few quirks that need to be accounted for. Hopefully some of the V4VM quirks are bugs and will be fixed in due time, but the HTML dependencies do remain. And my current experience with graphics APIs is that you want to test the whole stack together. If we e.g. add support for new extensions in Canvas3D, that can activate new codepaths in Three.js that again need testing and possibly new Qt specific delta must be added to the three.js for those parts. Comments? Thoughts? Please remember to update the licensing documentation (http://doc.qt.io/qt-5/licensing.html) to include the three.js. Also as a side note links to Canvas 3D should be also added to appropriate places e.g. Graphics topic (http://doc.qt.io/qt-5/topics-graphics.html#opengl-and-3d). -- Sami Regards, Pasi Keränen Software Specialist The Qt Company http://www.qt.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 09 January 2015 20:19:36 André Pönitz wrote:
In some case these macros even expand to something else than the obviously
related C++ keyword, so potential benefits gained from using the actual
feature have to be weighed with the costs of obfuscation.
They expand to the correct keyword when the keyword is permitted, so there's
no mistake. They expand to something else that will not affect the code unduly
if the keyword is not permitted.
Do you have anything in mind for when they'd expand unexpectedly?
I'd like to propose the following.
Policy per keyword:
* Q_NULLPTR - strongly encouraged
Use it whenever your literal zero is a null pointer. You can leave it out
when it cannot be mistaken for a zero and it would otherwise make the
source code harder to read.
Note that Qt still compiles with C++98, so you can't use Q_NULLPTR for
disambiguation.
No, please, not.
C++ 'nullptr' only gives a benefit over '0' in the rare cases where it
helps for disambiguation. I would not really like a policy encouraging
'nullptr' when '0' is just fine, but at least that would be tolerable.
On the other hand, 'Q_NULLPTR' does not even serve the 'disambiguation'
purpose, so it's really useless annoying line noise.
I propose to continue to use '0' until Qt can switch over to C++11
and then re-open the discussion with 'nullptr - mildly encouraged'.
Fair enough.
Marc, what's your opinion?
Note that the disambiguation need not be only by the compiler. If the code is
simpler to understand because you marked something as a pointer, then I think
you should use the macro.
* Q_DECL_FINAL - optional, use with care
There's a small benefit in optimisation by devirtualising calls. Use it
with care.
Use in public classes is discouraged, since people can compile with a
C++98
and derive / override what they shouldn't.
Another reason is that even if we think it should be final, the user of
the class (or rather sub-classes) might disagree.
We make the call because we designed the code. If the class isn't intended to
be derived from, then let the user know.
* Q_DECL_OVERRIDE - required in new code, don't add to old code
Always add Q_DECL_OVERRIDE for any override in new classes you write. This
supersedes the need for the virtual keyword -- add it or not, it's up to
you.
DO NOT add to existing classes, including for new overrides to existing
classes. Clang 3.6 has a new warning about inconsistent use of this
keyword, so adding to one place requires adding to all overrides in that
class. Therefore, this needs to be done fully in each class and that's
not a whitespace correction error.
In my opinion Q_DECL_OVERRIDE brings sufficient benefit to generally
encourage its use despite of the line noise it brings. However, since
'virtual' is not needed in case Q_DECL_OVERRIDE is used the rule should be
to leave 'virtual' out/remove it in that case.
Indeed.
[1] - All 'ok' under the assumption that this does not affect code that
does not need to stay compatible with C++98. Such code should rather use
C++11 keywords directly.
That's still per compiler, since compilers added support for the keywords at
different times. Therefore, the use of the Q macro is required, unless you've
already surrounded the code with the matching #ifdef.
For example:
#if defined(Q_COMPILER_CONSTEXPR) defined(Q_COMPILER_UNIFORM_INIT)
constexpr Foo() : array{1, 2, 3} ()
#endif
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 9 January 2015 at 20:19, André Pönitz apoen...@t-online.de wrote: C++ 'nullptr' only gives a benefit over '0' in the rare cases where it helps for disambiguation. I would not really like a policy encouraging 'nullptr' when '0' is just fine, but at least that would be tolerable. Not only that, compilers are starting to complain about 0 used in place of NULL / nullptr, for instance GCC under -Wzero-as-null-pointer-constant. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtIFW] Offline from online?
-Original Message- From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro] Sent: Thursday, January 08, 2015 10:07 AM To: Koehne Kai; development@qt-project.org Subject: Re: [Development] [QtIFW] Offline from online? 17.12.2014, 12:53, Koehne Kai kai.koe...@theqtcompany.com: - Original Message- From: development-bounces+kai.koehne=theqtcompany.com@qt- Subject: [Development] [QtIFW] Offline from online? What about the creation of the offline installers based on shared in the online repository components? So far the IFW doesn't offer such functionality out of the box. Could you elaborate a bit on the use case you have in mind? When developing a large project consisting of several modules (for example, Qt Framework) that accompanies each module can build and upload a compressed binary repository on the server to use this module, developers of other modules. Now the developers of the modules do not need to build third-party modules to develop your module. So. For each module there is an online repository. All happy. But, we still need to create the offline installer to install the project on a separate machine without access to the online repository. To create such an installer, we need not compressed packages of each module. We take all of these packages and will be compressed in to record installerbase. Why? Each module has already been built and compressed. It seems to me online repository contains enough information to create the offline installer. I see, thanks for the details. You only need to teach binarycreator as the option to take some components are not from the folder with the packages (option-p), and from an online repository. I believe that this functionality will be in demand. Kai, what do you think? It is difficult to do it? I agree that it should be doable. I'm not that much into the details though to say how much effort it would be... There are others that know that part of the IFW better than me :) Could you file a feature request on bugreports.qt.io , project Qt Installer Framework, so that we can discuss this there further? Thanks Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] 5.4.1 branch has now been added to the CI
Hi! The subject says it all... -Tony Tony Sarajärvi CI Tech Lead ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Hi Louai,
The changes required to the library were originally quite large. But
thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
wrapper classes to make e.g. Image loading look and smell like in HTML
land, the delta has been getting smaller and smaller. Here is a pretty
complete list based on quick compare between the R69 original three.js and
the Canvas3D port of the R69 release of three.js. There might be something
I’m forgetting to mention here. But as I said the delta has been getting
smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
some delta always as QtQuick is not HTML.
* We don’t have performance timers in Qt Quick JS, so the Clock class must
be modified to not use those.
* In some files the class is declared with syntax of ( function (THREE) {
blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
executing functions don’t seem to work, V4VM just refuses to load the
file. I haven’t been able to replicate this behaviour with a small
example, so probably it’s relates to some complex situation arising when
loading a large JavaScript file OR then there is some minute detail in
that self executing function that I can’t spot.
* Resizing of images has to be modified as that is usually done with HTML
trickery that doesn’t work at the moment with Canvas3D.
* Accessor functions defined in prototypes with:
get x() { return this._x },
set x(value) { this._x = value; this.onChangeCallback(); }
* Must be rewritten with the (older?) syntax of:
this.__defineGetter__(x, function(){return this._x;});
this.__defineSetter__(x, function(value){this._x =
value;this.onChangeCallback();});
* Canvas3DRenderer is new code, ported from WebGL. Main differences are to
do with initialization differences between Canvas3D and WebGL. Handling of
some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
(should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
place and function overloading should work). And I’ve wanted to support
the logging features of Canvas3D objects, by setting the .name attribute
of some objects so that when you turn on logging you can see what
UniformAttribute, what Shader3D object you are looking at in the logs..
Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
name in the renderer causes V4VM not to load the file, but again a minimal
example of this doesn’t have this problem so can’t replicate it). Again,
the delta should get smaller with WebGLRenderer, but I’d expect there to
always be some delta.
That is all the delta I can list quickly, if you are interested in details
just get the R69 release from three.js git and the stable branch of
QtCanvas3D port and do a detailed compare of those.
Reagrding this delta I’ve thought a bit how to reorganise the delta so
that it could live in a separate folder inside three.js. If I can make
that happen, then maybe it would be possible to get these few changes in
to three.js upstream and make it possible to always use the latest from
there as well if one so wishes. But that will require a bit more work on
V4VM I think before we’re there. E.g. Add support for binary file loading
with XMLHttpRequest and track down why those few anomalies occur when
loading self executing functions declared in the manner they are in
three.js so that the upstream code should run as much as possible
unmodified on top of Canvas3D with just the few changes we need in place.
Regards,
Pasi
On 08/01/15 12:54, Al-Khanji Louai louai.al-kha...@theqtcompany.com
wrote:
On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote:
Hi,
I¹d like to open the discussion on including the three library as
part of
Qt 5.6 and onwards. Mainly because this would give our users a better
experience if we¹d bundle the right, tested version of Three.js
together
with the Qt version it was tested on.
I¹ve been pushing the Qt Canvas3D component onwards and timewise it
should
be landing to Qt 5.5 release. The WebGL-like API (non-conformance
tested)
it offers is very low level and most users will not like to work on
that
level. To that end I¹ve ported the WebGL based Three.js scenegraph
library
available at http://threejs.org on top of Canvas3D. You can find the
latest version from master branch at
https://github.com/tronlec/three.js
The reason for picking this particular library over others are:
* It¹s one of the most active WebGL scene graph projects out there.
* It¹s well done, with examples, API documentation etc.
* It has excellent support form community in the form of tutorials,
websites, discussion forums etc.
* It is available under permissive MIT license:
https://github.com/mrdoob/three.js/blob/master/LICENSE
In Qt 5.5 we¹ll include a few examples that will have this library as
part
of the examples.
The library will for now at least need some porting effort to make it
run
on top of Canvas3D as there are some HTML
Re: [Development] Adding new third party component three.js to Qt?
On Fri, Jan 9, 2015 at 3:39 PM, Keränen Pasi pasi.kera...@theqtcompany.com
wrote:
Hi Louai,
The changes required to the library were originally quite large. But
thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
wrapper classes to make e.g. Image loading look and smell like in HTML
land, the delta has been getting smaller and smaller. Here is a pretty
complete list based on quick compare between the R69 original three.js and
the Canvas3D port of the R69 release of three.js. There might be something
I’m forgetting to mention here. But as I said the delta has been getting
smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
some delta always as QtQuick is not HTML.
* We don’t have performance timers in Qt Quick JS, so the Clock class must
be modified to not use those.
* In some files the class is declared with syntax of ( function (THREE) {
blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
executing functions don’t seem to work, V4VM just refuses to load the
file. I haven’t been able to replicate this behaviour with a small
example, so probably it’s relates to some complex situation arising when
loading a large JavaScript file OR then there is some minute detail in
that self executing function that I can’t spot.
* Resizing of images has to be modified as that is usually done with HTML
trickery that doesn’t work at the moment with Canvas3D.
* Accessor functions defined in prototypes with:
get x() { return this._x },
set x(value) { this._x = value; this.onChangeCallback(); }
* Must be rewritten with the (older?) syntax of:
this.__defineGetter__(x, function(){return this._x;});
this.__defineSetter__(x, function(value){this._x =
value;this.onChangeCallback();});
* Canvas3DRenderer is new code, ported from WebGL. Main differences are to
do with initialization differences between Canvas3D and WebGL. Handling of
some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
(should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
place and function overloading should work). And I’ve wanted to support
the logging features of Canvas3D objects, by setting the .name attribute
of some objects so that when you turn on logging you can see what
UniformAttribute, what Shader3D object you are looking at in the logs..
Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
name in the renderer causes V4VM not to load the file, but again a minimal
example of this doesn’t have this problem so can’t replicate it). Again,
the delta should get smaller with WebGLRenderer, but I’d expect there to
always be some delta.
That is all the delta I can list quickly, if you are interested in details
just get the R69 release from three.js git and the stable branch of
QtCanvas3D port and do a detailed compare of those.
Reagrding this delta I’ve thought a bit how to reorganise the delta so
that it could live in a separate folder inside three.js. If I can make
that happen, then maybe it would be possible to get these few changes in
to three.js upstream and make it possible to always use the latest from
there as well if one so wishes. But that will require a bit more work on
V4VM I think before we’re there. E.g. Add support for binary file loading
with XMLHttpRequest and track down why those few anomalies occur when
loading self executing functions declared in the manner they are in
three.js so that the upstream code should run as much as possible
unmodified on top of Canvas3D with just the few changes we need in place.
Regards,
Pasi
On 08/01/15 12:54, Al-Khanji Louai louai.al-kha...@theqtcompany.com
wrote:
On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote:
Hi,
I¹d like to open the discussion on including the three library as
part of
Qt 5.6 and onwards. Mainly because this would give our users a better
experience if we¹d bundle the right, tested version of Three.js
together
with the Qt version it was tested on.
I¹ve been pushing the Qt Canvas3D component onwards and timewise it
should
be landing to Qt 5.5 release. The WebGL-like API (non-conformance
tested)
it offers is very low level and most users will not like to work on
that
level. To that end I¹ve ported the WebGL based Three.js scenegraph
library
available at http://threejs.org on top of Canvas3D. You can find the
latest version from master branch at
https://github.com/tronlec/three.js
The reason for picking this particular library over others are:
* It¹s one of the most active WebGL scene graph projects out there.
* It¹s well done, with examples, API documentation etc.
* It has excellent support form community in the form of tutorials,
websites, discussion forums etc.
* It is available under permissive MIT license:
https://github.com/mrdoob/three.js/blob/master/LICENSE
In Qt 5.5 we¹ll include a few examples that will
