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
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²
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,
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:
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
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.
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,
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
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
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
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
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.
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
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
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
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
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
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
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
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?
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
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
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
=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
] 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
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
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
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
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
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
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
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
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
33 matches
Mail list logo
