Re: [Development] Adding new third party component three.js to Qt?
Hi Pasi, We have already forked and currently maintain a separate fork of three.js that is compatible with Qt3dCanvas so including that fork’s code as included 3rd party source code seems like the obvious thing to do. You have my support in doing this. We should not optimise for what makes the life of a package maintainers for a Linux distribution easier. We should optimise for what makes things easier for developers using Qt on all platforms. Give them something that is setup to works out of the box, and is known to work well with our given release. We do this currently with many other 3rd party dependencies. The whole argument is absurd anyway because we’re talking about a Javascript library. One that in the browser case will have a new version downloaded every time you go to a page that uses it. Regards, Andy Nichols From: development-bounces+andy.nichols=theqtcompany@qt-project.org development-bounces+andy.nichols=theqtcompany@qt-project.org on behalf of Keränen Pasi pasi.kera...@theqtcompany.com Sent: Tuesday, January 20, 2015 11:35 AM To: development@qt-project.org Subject: Re: [Development] Adding new third party component three.js to Qt? Hi everyone, So far it seems there has been some positive answers from the community, but the distribution packaging side seems to have most comments against inclusion of the three.js library or at least have comments on HOW it should be included. Sorry, I¹m dropping out of the ³qtchooser² thread, it¹s going way over my understanding of packaging related issues, I¹m a graphics guy and will let the more capable people from our releasing side comment on that. But out of curiosity, can I ask for a show of hands on which distributions currently include the 100% JavaScript three.js based 3D scene graph library in them OR are expecting to do so in the future? Just to see how much impact are we talking about if we decide to include the library to cater for those users that do seem to want a ready ported and verified to work solution within their Qt SDK for their Canvas3D related scene graph needs (perhaps by taking the approach Louai suggested earlier to allow for the eventuality that some distribution wants to include their chosen version of three.js in it). Regards, Pasi On 19/01/15 13:27, Keränen Pasi pasi.kera...@theqtcompany.com wrote: Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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 ___ 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] Adding new third party component three.js to Qt?
Hi everyone, So far it seems there has been some positive answers from the community, but the distribution packaging side seems to have most comments against inclusion of the three.js library or at least have comments on HOW it should be included. Sorry, I¹m dropping out of the ³qtchooser² thread, it¹s going way over my understanding of packaging related issues, I¹m a graphics guy and will let the more capable people from our releasing side comment on that. But out of curiosity, can I ask for a show of hands on which distributions currently include the 100% JavaScript three.js based 3D scene graph library in them OR are expecting to do so in the future? Just to see how much impact are we talking about if we decide to include the library to cater for those users that do seem to want a ready ported and verified to work solution within their Qt SDK for their Canvas3D related scene graph needs (perhaps by taking the approach Louai suggested earlier to allow for the eventuality that some distribution wants to include their chosen version of three.js in it). Regards, Pasi On 19/01/15 13:27, Keränen Pasi pasi.kera...@theqtcompany.com wrote: Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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 ___ 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?
The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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] Adding new third party component three.js to Qt?
On Thu, Jan 15, 2015 at 05:48:16PM -0800, Thiago Macieira wrote: But what if we ship source and the generated minified files? as you are bringing up the example of includes below ... shipping as in in the tar balls is fine by me. but don't commit the minified (== generated) file to the repository. We do that for other sources that seldomly change, like the outputs from qlalr. bad example ... the only reason why we still do that is because qmake is too daft to be able to properly integrate qlalr into the build process (dependency tracking ...). this cannot be said for a lot of other generated files, for which their presence in the repository is pretty much historical only. don't add to that history. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. ___ 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?
On Thursday 15 January 2015 20:31:58 Thiago Macieira wrote: On Friday 16 January 2015 00:54:31 Lisandro Damián Nicanor Pérez Meyer wrote: We do that for other sources that seldomly change, like the outputs from qlalr. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. Before answering this one please note that I understand why you do this and why you would prefer to keep doing it. It happens that distros like Debian (and for what I read, also Fedora) think differently. I think you need to get some leeway and not think in absolute terms. Yes, my bad. I actually spent quite some time to try to correctly phrase this paragraph trying to express that I'm not trying to force anything nor generate a debate nor bad faith nor... but it seems I failed :-/ Allow me to blame the fact that I'm not a native speaker and I live at least 1000km away from the nearest english-speaking country ;) I realize we in Debian might be missing to regenerate some stuff (maybe quite a lot) but when we find stuff that has been pre-generated we do our best to re generate it during the build process. Do you remove and regenerate: - the Unicode tables in qunicodedata.cpp? - the CLDR data in qlocale_data_p.h and qtimezoneprivate_data_p.h? How about the locale list in qlocale.h? - the indexed string tables in qdbuserror.cpp, qbenchmarkperfevents.cpp, qxmlstream.cpp, and qsimd.cpp? - the QML parser from qmljs.g? - the XML parser from qxmlstream.g? (note the cyclic dependency, since qlalr depends on QtCore) - the pre-generated IAccessible2 interfaces (Windows-only, think of cross- mingw) - the class list in tools/uic/ui4.h? And this is just qtbase. I'm sure there are more. We are possibly missing quite a lot of them, but having a list of things to look at really helps. Thanks! Doesn't it suffice to know that you can regenerate the generated code? Even the ones you can regenerate perfectly, down to the same indentation? There's actually one thing we maintainers are allowed to do: recreate the original tarball regenerating all the necessary files and then ship that. It's a compromise solution, but if we can add those steps directly in the build process the better. Doc is an example, we Debian maintainers need to ensure that every piece we ship is in it's preferred form of modification and that we are able to create the resulting stuff ourselves with the tools in the archive. So pregenerated doc is not a solution for us. I'm not saying it was a solution. I'm saying it is a convenience. Well, a convenience we can't use then. Anyone: if you find something that needs regenerating and we (again, Debian) are not doing it, do not hesitate to fill a serious bug in Debian's bug tracker. Or ping me if you somehow find it and you are not using Debian. See above. Most of it requires manual editing to insert the resulting output back into the source code. Ah, let's hold on a little here. Up to this point I was *always* referring to stuff that gets 100% created after some process, like javascript minification. Stuff that needs hand editing *is* special, as one could consider it as the preferred form of modification. It might be a gray area, but if somebody has to fiddle with some data to create the source code then we trust upstream in this in the same way we trust for the 100% hand-coded stuff. If there is a free tool which can be used instead of the non-free one we will do our best to use it, even if the result is sub-par. Else we would prefer to simply remove the offending file and tell our users sorry, but it needs a non-free tool to build. Putting Qt in the contrib repo is a much worst user disservice than not shipping the file (and again, in Debian terms). Thanks for the info. We all agree we don't want that to happen. That's why we're discussing now, so we can find a solution that works for the packagers, like we did in the past for qtchooser (a solution designed for distro's needs). *My pleasure*. And thanks *a lot* for pointing those files above. I'll filter out those that need manual editing and see what I can do with the rest of them. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
On Thursday 15 January 2015 20:31:58 Thiago Macieira wrote: Do you remove and regenerate: - the Unicode tables in qunicodedata.cpp? - the CLDR data in qlocale_data_p.h and qtimezoneprivate_data_p.h? How about the locale list in qlocale.h? - the indexed string tables in qdbuserror.cpp, qbenchmarkperfevents.cpp, qxmlstream.cpp, and qsimd.cpp? - the QML parser from qmljs.g? - the XML parser from qxmlstream.g? (note the cyclic dependency, since qlalr depends on QtCore) - the pre-generated IAccessible2 interfaces (Windows-only, think of cross- mingw) - the class list in tools/uic/ui4.h? And this is just qtbase. I'm sure there are more. More in qtbase: - src/tools/moc/(pp)keywords.cpp generated by the generator in src/tools/moc/util (circular dependency again) - src/corelib/io/qurltlds_p.h generated by util/corelib/qurl-generateTLDs (BTW, this really need to be regenerated, for security reasons) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ 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?
On Friday 16 January 2015 15:35:02 Olivier Goffart wrote: [snip] More in qtbase: Thanks a lot! - src/tools/moc/(pp)keywords.cpp generated by the generator in src/tools/moc/util (circular dependency again) If you mean that those cpp are needed in order to build the tools that will later build the files themselves then it's not a problem to accept pregenerated stuff to bootstrap it because we can end up rebuilding everything. - src/corelib/io/qurltlds_p.h generated by util/corelib/qurl-generateTLDs (BTW, this really need to be regenerated, for security reasons) Then I'll start with this one :) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
On Wednesday 14 January 2015 09:24:43 Thiago Macieira wrote: On Wednesday 14 January 2015 11:38:55 Lisandro Damián Nicanor Pérez Meyer wrote: The same can be said about C/C++ 3rdparty libraries. So no, bundling is not good for distros. Imagine a security bug appears: we need to start hunting down each embedded version and fix it, checking that we don't break anything specially in forked cases. A nightmare. Actually, the problem here is not that of shipping a bundled version. It's embedding the binary inside one of Qt binaries. Let's solve this problem first: how to find the JS file (minified or not) somewhere on disk, without Qt resources. Once that is solved, distros can opt to build three.js from the official sources and apply the necessary Qt patches in the manner that is most helpful to them. This would indeed be a nice way to start fixing this. I might be becoming mad, but I'll see what can be done in that regard (we do have a policy for that, but so far Debian-only as far as I know). -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
On Friday 16 January 2015 00:54:31 Lisandro Damián Nicanor Pérez Meyer wrote: We do that for other sources that seldomly change, like the outputs from qlalr. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. Before answering this one please note that I understand why you do this and why you would prefer to keep doing it. It happens that distros like Debian (and for what I read, also Fedora) think differently. I think you need to get some leeway and not think in absolute terms. I realize we in Debian might be missing to regenerate some stuff (maybe quite a lot) but when we find stuff that has been pre-generated we do our best to re generate it during the build process. Do you remove and regenerate: - the Unicode tables in qunicodedata.cpp? - the CLDR data in qlocale_data_p.h and qtimezoneprivate_data_p.h? How about the locale list in qlocale.h? - the indexed string tables in qdbuserror.cpp, qbenchmarkperfevents.cpp, qxmlstream.cpp, and qsimd.cpp? - the QML parser from qmljs.g? - the XML parser from qxmlstream.g? (note the cyclic dependency, since qlalr depends on QtCore) - the pre-generated IAccessible2 interfaces (Windows-only, think of cross- mingw) - the class list in tools/uic/ui4.h? And this is just qtbase. I'm sure there are more. Doesn't it suffice to know that you can regenerate the generated code? Even the ones you can regenerate perfectly, down to the same indentation? Doc is an example, we Debian maintainers need to ensure that every piece we ship is in it's preferred form of modification and that we are able to create the resulting stuff ourselves with the tools in the archive. So pregenerated doc is not a solution for us. I'm not saying it was a solution. I'm saying it is a convenience. Anyone: if you find something that needs regenerating and we (again, Debian) are not doing it, do not hesitate to fill a serious bug in Debian's bug tracker. Or ping me if you somehow find it and you are not using Debian. See above. Most of it requires manual editing to insert the resulting output back into the source code. If there is a free tool which can be used instead of the non-free one we will do our best to use it, even if the result is sub-par. Else we would prefer to simply remove the offending file and tell our users sorry, but it needs a non-free tool to build. Putting Qt in the contrib repo is a much worst user disservice than not shipping the file (and again, in Debian terms). Thanks for the info. We all agree we don't want that to happen. That's why we're discussing now, so we can find a solution that works for the packagers, like we did in the past for qtchooser (a solution designed for distro's needs). -- 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] Adding new third party component three.js to Qt?
Lisandro Damián Nicanor Pérez Meyer wrote: That might be a question for Kevin, but on Debian a javascript library is treated as any other C/C++ library: source code should be there, the binary/minified version must be created from the unminified code at package build time (ie, when building the source code that ships it). It doesn't matter what uses it. That is also true in Fedora. What we do not have guidelines for so far is reuse of systemwide JavaScript libraries in non-web applications. So Qt will probably get away with bundling three.js for now. But shipping it only in minified form is also banned by global Fedora policies and thus clearly unacceptable. My recommendation is to not ship a minified file in the source tarball at all (we would have to remove it), but to generate it at build time. However, please make sure the minifier you are using is Free Software. The popular JSMin is NOT Free Software: http://wonko.com/post/jsmin-isnt-welcome-on-google-code http://www.gnu.org/licenses/license-list.html#JSON and therefore NOT an acceptable build dependency for Qt (or any other package for that matter) in Fedora and Debian: https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses (JSON License) https://bugzilla.redhat.com/show_bug.cgi?id=455507 https://wiki.debian.org/qa.debian.org/jsonevil So please use UglifyJS or another acceptably-licensed minifier instead. Kevin Kofler ___ 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?
On Thursday 15 January 2015 17:48:16 Thiago Macieira wrote: On Friday 16 January 2015 01:38:50 Kevin Kofler wrote: What we do not have guidelines for so far is reuse of systemwide JavaScript libraries in non-web applications. So Qt will probably get away with bundling three.js for now. But shipping it only in minified form is also banned by global Fedora policies and thus clearly unacceptable. To clarify: minified-only is obviously bad. But what if we ship source and the generated minified files? We (Debian) need to remove the minified sources from the original tarball. We do that for other sources that seldomly change, like the outputs from qlalr. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. Before answering this one please note that I understand why you do this and why you would prefer to keep doing it. It happens that distros like Debian (and for what I read, also Fedora) think differently. I realize we in Debian might be missing to regenerate some stuff (maybe quite a lot) but when we find stuff that has been pre-generated we do our best to re generate it during the build process. Doc is an example, we Debian maintainers need to ensure that every piece we ship is in it's preferred form of modification and that we are able to create the resulting stuff ourselves with the tools in the archive. So pregenerated doc is not a solution for us. There are exceptions with stuff that can be used on all archs (like docs, called arch: all in Debian's jargon) but those are probably going to dissapear once arch:all packages are built on Debian's infra. Anyone: if you find something that needs regenerating and we (again, Debian) are not doing it, do not hesitate to fill a serious bug in Debian's bug tracker. Or ping me if you somehow find it and you are not using Debian. If that's ok, does it matter that a non-free tool was used? I'm guessing it does matter, even if there's a free one can also produce a valid output. Yes it does matters, totally. Requiring a non-free tool to build would make Qt and **everything** that depends on it to the contrib repo: free software stuff that needs non-free stuff to build and/or run. And that supposing we can ship the build tool in non-free, else we would simply not be allowed to build that part. If there is a free tool which can be used instead of the non-free one we will do our best to use it, even if the result is sub-par. Else we would prefer to simply remove the offending file and tell our users sorry, but it needs a non-free tool to build. Putting Qt in the contrib repo is a much worst user disservice than not shipping the file (and again, in Debian terms). As a side note, Debian's rules are also Ubuntu's ones for most of their stuff, including Qt. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
I think it's also good to notice that (once again, we in Debian) if a lib is shipped under 3rdparty but the build process auto detects a system one and uses it instead is definitely a nice solution for us. Yes, we maintainers need to check the code of the 3rdparty stuff and their licenses, but as long as we don't build it there is nothing wrong to have the code there. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
On Friday 16 January 2015 01:38:50 Kevin Kofler wrote: What we do not have guidelines for so far is reuse of systemwide JavaScript libraries in non-web applications. So Qt will probably get away with bundling three.js for now. But shipping it only in minified form is also banned by global Fedora policies and thus clearly unacceptable. To clarify: minified-only is obviously bad. But what if we ship source and the generated minified files? We do that for other sources that seldomly change, like the outputs from qlalr. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. If that's ok, does it matter that a non-free tool was used? I'm guessing it does matter, even if there's a free one can also produce a valid output. -- 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] Adding new third party component three.js to Qt?
On Wednesday 14 January 2015 09:16:22 Olivier Goffart wrote: [snip] However, in the source code, the non-minified version needs to be present with instructions on how to regenerate the minified version. What's optional: minifying during build. It's ok to commit the minified version to Git, so long as the non-minified version is easily available. The non-minified version does not have to be in the git repository to respect the license. It is enough to have it in another git repository for example. Or just in a package available in a 3rdparty directory of the qt-project FTP. While this is, to the best of my knowledge, entirely true the fact of shipping the unminified source code along with the minified one in the same repo helps us distro maintainers *a lot* as we don't require to modify the original tarballs to include it. If the javascript library is in it's unmodified (ie, upstream's original) form we can simply remove the minified version and use the distro-packaged one. But if the library gets modified, like in this very case, we really need the source code in the same tarball. Adding the original code in 3rdparty in the same repo is definitely a plus for us who need to deal with them. Another big big plus for us maintainers is if there is code (like a script) to minify the lib at build time. It doesn't needs to be included in the build process, it can be manually done and maybe even require some external tool. In this way we simply run the script before compilation and we are done. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
On Wednesday 14 January 2015 07:24:52 Keränen Pasi wrote: Hi Kevin and Lisandro, I have zero experience with distribution packaging and the problems therein so sorry if I’m a bit lost here. Thank you Kevin for the links you sent, I found them informative. No problem, it happens quite often :) I followed the Packaging:JavaScript link and it states Please note that this section really only applies to JavaScript libraries intended for use on the web”. Canvas3D and three.js port on top of it are NOT meant to be used on the web, they are both meant to be used within QtQuick/QML environment, so running locally as part of your native code (or pure QtQuick) application. That might be a question for Kevin, but on Debian a javascript library is treated as any other C/C++ library: source code should be there, the binary/minified version must be created from the unminified code at package build time (ie, when building the source code that ships it). It doesn't matter what uses it. I also read through the Packaging:No_Bundled_Libraries link. I can see the points made in there, but there is also a good reason why we want to bundle the three.js together with certain version of Qt and Canvas3D. We want to deliver a library that we know has been tested together with the V4 VM and the Canvas3D and we know it should run smoothly there. And by doing this we add value to our customers. The same can be said about C/C++ 3rdparty libraries. So no, bundling is not good for distros. Imagine a security bug appears: we need to start hunting down each embedded version and fix it, checking that we don't break anything specially in forked cases. A nightmare. Regarding one of the points made in that document on forks. Yes, at the moment this port from HTML to QtQuick is a fork of the official three.js library and lives right next to it in Github. But as I said I’m hoping we can reduce the delta we have by doing some additional work on the V4VM and on the Canvas3D. And perhaps if the remaining HTML vs. QML delta is in only few places and is minimal, we can then persuade the maintainers of three.js to re-design those few parts to make upstreaming possible with a clean design. But it's still a fork, meaning semi-duplicated code that we maintainers need to address. Please allow me to be clear in one thing: I *do* understand that for Qt, as long as the license is respected, there is not much of a problem. What I've expressed here is what us distro maintainers face with this actions. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
On Wednesday 14 January 2015 11:38:55 Lisandro Damián Nicanor Pérez Meyer wrote: The same can be said about C/C++ 3rdparty libraries. So no, bundling is not good for distros. Imagine a security bug appears: we need to start hunting down each embedded version and fix it, checking that we don't break anything specially in forked cases. A nightmare. Actually, the problem here is not that of shipping a bundled version. It's embedding the binary inside one of Qt binaries. Let's solve this problem first: how to find the JS file (minified or not) somewhere on disk, without Qt resources. Once that is solved, distros can opt to build three.js from the official sources and apply the necessary Qt patches in the manner that is most helpful to them. -- 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] Adding new third party component three.js to Qt?
On Tuesday 13 January 2015 23:03:11 Thiago Macieira wrote: On Wednesday 14 January 2015 05:14:10 Keränen Pasi wrote: Hi Thiago (and Lars), Surely we can include a minified version that gets bundled with your app when you e.g. use a new project wizard to create a Canvas3D project with three.js? No need to have any larger than necessary files there? Already the new project wizard freezes up to around 20-40 seconds (beachballing Qt Creator on my Mac while it does it) when you create a new project as it¹s copying the 800k three.js file, I¹d like to cut down that time as much as possible. You can include a minified version in your application's binary package. In fact, the binary versions of Qt will probably include the minified version somewhere, like a resource. However, in the source code, the non-minified version needs to be present with instructions on how to regenerate the minified version. What's optional: minifying during build. It's ok to commit the minified version to Git, so long as the non-minified version is easily available. The non-minified version does not have to be in the git repository to respect the license. It is enough to have it in another git repository for example. Or just in a package available in a 3rdparty directory of the qt-project FTP. But if people really want to hack around with the three.js port I¹d expect them to use the original source files (each class in separate .js file) as it¹s a bit unwieldy to edit that ~800k sourcefile (trust me, been there done that bunch of times when trying to figure out a bug in it). It¹s a lot nicer to edit the separate files for each class and then build the big source file after you¹ve done the modifications.. Again: what's important is that the we ship form in which people prefer to make modifications. If that's the separate files, that's what we need to ship. But that does not have to be in the same git repository. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ 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 Thiago (and Lars), Surely we can include a minified version that gets bundled with your app when you e.g. use a new project wizard to create a Canvas3D project with three.js? No need to have any larger than necessary files there? Already the new project wizard freezes up to around 20-40 seconds (beachballing Qt Creator on my Mac while it does it) when you create a new project as it¹s copying the 800k three.js file, I¹d like to cut down that time as much as possible. But if people really want to hack around with the three.js port I¹d expect them to use the original source files (each class in separate .js file) as it¹s a bit unwieldy to edit that ~800k sourcefile (trust me, been there done that bunch of times when trying to figure out a bug in it). It¹s a lot nicer to edit the separate files for each class and then build the big source file after you¹ve done the modifications.. So I¹m thinking we then should actually include the separate source files and the build script for that as well? And offer the minified version (once it builds and works with V4VM that is) as ³pre built binary² version as well. Regards, Pasi On 08/01/15 19:05, Thiago Macieira thiago.macie...@intel.com wrote: On Thursday 08 January 2015 12:47:04 Keränen Pasi wrote: Size without minification is 824kBytes. Unfortunately minification currently fails due to the placeholder TypedArray wrappers in Qt Canvas3D. Minification is to be done by the buildsystem. We need to ship the source in the format that developers prefer to make modifications to. -- 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 ___ 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?
On Wednesday 14 January 2015 05:14:10 Keränen Pasi wrote: Hi Thiago (and Lars), Surely we can include a minified version that gets bundled with your app when you e.g. use a new project wizard to create a Canvas3D project with three.js? No need to have any larger than necessary files there? Already the new project wizard freezes up to around 20-40 seconds (beachballing Qt Creator on my Mac while it does it) when you create a new project as it¹s copying the 800k three.js file, I¹d like to cut down that time as much as possible. You can include a minified version in your application's binary package. In fact, the binary versions of Qt will probably include the minified version somewhere, like a resource. However, in the source code, the non-minified version needs to be present with instructions on how to regenerate the minified version. What's optional: minifying during build. It's ok to commit the minified version to Git, so long as the non-minified version is easily available. But if people really want to hack around with the three.js port I¹d expect them to use the original source files (each class in separate .js file) as it¹s a bit unwieldy to edit that ~800k sourcefile (trust me, been there done that bunch of times when trying to figure out a bug in it). It¹s a lot nicer to edit the separate files for each class and then build the big source file after you¹ve done the modifications.. Again: what's important is that the we ship form in which people prefer to make modifications. If that's the separate files, that's what we need to ship. So I¹m thinking we then should actually include the separate source files and the build script for that as well? And offer the minified version (once it builds and works with V4VM that is) as ³pre built binary² version as well. -- 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] Adding new third party component three.js to Qt?
Hi Kevin and Lisandro, I have zero experience with distribution packaging and the problems therein so sorry if I’m a bit lost here. Thank you Kevin for the links you sent, I found them informative. I followed the Packaging:JavaScript link and it states Please note that this section really only applies to JavaScript libraries intended for use on the web”. Canvas3D and three.js port on top of it are NOT meant to be used on the web, they are both meant to be used within QtQuick/QML environment, so running locally as part of your native code (or pure QtQuick) application. I also read through the Packaging:No_Bundled_Libraries link. I can see the points made in there, but there is also a good reason why we want to bundle the three.js together with certain version of Qt and Canvas3D. We want to deliver a library that we know has been tested together with the V4 VM and the Canvas3D and we know it should run smoothly there. And by doing this we add value to our customers. Regarding one of the points made in that document on forks. Yes, at the moment this port from HTML to QtQuick is a fork of the official three.js library and lives right next to it in Github. But as I said I’m hoping we can reduce the delta we have by doing some additional work on the V4VM and on the Canvas3D. And perhaps if the remaining HTML vs. QML delta is in only few places and is minimal, we can then persuade the maintainers of three.js to re-design those few parts to make upstreaming possible with a clean design. As I said the discussion about doing the upstreaming to three.js hasn’t been started. The simple reason being I want us to have done the best we can before we start nudging them and asking if they’d be interested in our changes that make their library on top of Qt Quick. That way the discussion is going to be easier and the amount of work needed to do the upstreaming is going to be minimal. I don’t want to start that discussions by saying “I’d like you to remove the use of self executing functions in this class just because for some reason in this particular case our VM just doesn’t handle it very well..”. I realised I didn’t mention timeline for this adding of three.js at all. My own estimate is that we could be able to only ship a few examples with Canvas3D that will use three.js as part of the examples in Qt 5.5, not add three.js as part of Qt quite at that point due to various reasons. One being we will not have the time to test it properly by that time. We’ll need to do the homework on some of the issues we have before we can add three.js as part of Qt officially (meaning you can then just say import blah in your QML to get three.js included). My own estimate/guess is that could be around Qt 5.6 and I’d hope that before this point we could have the delta so minimal that we could reasonably start the discussion with three.js maintaineres about upstreaming the changes we really, really need. Not including changes we have today just because of issues in our own code. Regards, Pasi On 14/01/15 04:06, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: On Tuesday 13 January 2015 03:20:38 Kevin Kofler wrote: Sorry for raining on your parade, but… Keränen Pasi wrote: 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. … we distribution packagers REALLY hate bundled libraries… Same here. 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. … and especially FORKED bundled libraries (where we stand no realistic chance of actually unbundling them). I couldn't agree more. And also thanks Thiago for pointing that the lib should be minimized by the build system, else we wouldn't be able to ship it, even in it's embedded form. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ 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?
On Tuesday 13 January 2015 03:20:38 Kevin Kofler wrote: Sorry for raining on your parade, but… Keränen Pasi wrote: 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. … we distribution packagers REALLY hate bundled libraries… Same here. 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. … and especially FORKED bundled libraries (where we stand no realistic chance of actually unbundling them). I couldn't agree more. And also thanks Thiago for pointing that the lib should be minimized by the build system, else we wouldn't be able to ship it, even in it's embedded form. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ 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?
Sorry for raining on your parade, but… Keränen Pasi wrote: 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. … we distribution packagers REALLY hate bundled libraries… 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. … and especially FORKED bundled libraries (where we stand no realistic chance of actually unbundling them). Distributions really want to have one system version of a library, (for the reasons explained, e.g., under https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries ). (That said, for JavaScript stuff, at least in Fedora, we do not have a general, application-independent way of handling this issue yet, see: https://fedoraproject.org/wiki/Packaging:JavaScript .) Kevin Kofler ___ 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 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] 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] 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
Re: [Development] Adding new third party component three.js to Qt?
On 08/01/15 18:05, Thiago Macieira thiago.macie...@intel.com wrote: On Thursday 08 January 2015 12:47:04 Keränen Pasi wrote: Size without minification is 824kBytes. Unfortunately minification currently fails due to the placeholder TypedArray wrappers in Qt Canvas3D. Minification is to be done by the buildsystem. We need to ship the source in the format that developers prefer to make modifications to. Yes, agree. We should ship the full source if we add it. License and size is ok for me, so feel free to add it to canvas3d. Just add me as reviewer when you have the patch. Cheers, Lars ___ 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?
Size without minification is 824kBytes. Unfortunately minification currently fails due to the placeholder TypedArray wrappers in Qt Canvas3D. Pasi On 08/01/15 12:52, Hausmann Simon simon.hausm...@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 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? Sounds like a good idea to me. What's the size (lines of code) that we are talking about here? Is it just one big minified .js file? Simon ___ 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?
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 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? Sounds like a good idea to me. What's the size (lines of code) that we are talking about here? Is it just one big minified .js file? Simon Out of curiosity, how large are the changes that were required to port the library? -- Louai ___ 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?
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 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? Sounds like a good idea to me. What's the size (lines of code) that we are talking about here? Is it just one big minified .js file? Simon ___ 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?
On Thursday 08 January 2015 12:47:04 Keränen Pasi wrote: Size without minification is 824kBytes. Unfortunately minification currently fails due to the placeholder TypedArray wrappers in Qt Canvas3D. Minification is to be done by the buildsystem. We need to ship the source in the format that developers prefer to make modifications to. -- 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
[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? 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
