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. On 8 January 2015 at 07:37, William Hallatt goblincod...@gmail.com wrote: Shot, thanks Robert! I'm making progress. Kind regards. William. On 7 January 2015 at 16:40, Robert Löhning robert.loehn...@theqtcompany.com wrote: Hi William, you can let the commit-msg hook do that for you, see http://qt-project.org/wiki/Setting-up-Gerrit Best Regards, Robert Am 07.01.2015 um 14:56 schrieb William Hallatt: Hi Jens, That is exactly what I did (amongst some other, minor syntactic and layout stuff). Feel free to have a look: https://github.com/goblincoding/qt-labs-gimp-qmlexporter For now I am battling to figure out how to add Change-Id's with 'git rebase -i' so that I can push to Gerrit...so far no luck (it is a bit of a learning curve for me, my git exposure to date has involved little more than pushing, pulling and committing to my own personal repo's). Thanks so much for the epic work you did on this script! It has saved me a lot of pain and suffering. Kind regards, William. On 7 January 2015 at 13:49, jen...@gmail.com wrote: I would actually be curious as to what functionality you are planning on adding aside from obviously updating it to Qt 5. The main reason I abandoned the plugin 5 years ago was the lack of support for grouped layers in Gimp at the time. I know this is no longer an issue so it should be possible to use layer groups in order to create and keep a hierarchy of QML items now. At least this would make it significantly better suited for QML exports. Regards, Jens On 07 Jan 2015, at 10:42, William Hallatt goblincod...@gmail.com wrote: Thanks for the replies! I am making progress...now to figure out how to get the Change-Id's in after the fact... :) On 7 January 2015 at 10:42, Liang Qi cavendish...@gmail.com wrote: I guess you mean this on github, https://github.com/qtproject/qt-labs-gimp-qmlexporter Then please contribute to https://codereview.qt-project.org/#/admin/projects/qt-labs/gimp-qmlexporter Good luck! Regards, Liang On 7 January 2015 at 08:33, William Hallatt goblincod...@gmail.com wrote: Good day, I forked and made some changes to Jens Bache-Wiig's original QML exporter script (GIMP only) on GitHub and was wondering if I could simply create a pull request for my changes? I have searched for the project on Gerrit, but it does not seem to exist there. Advice would be appreciated. Kind regards, William Hallatt -- Robert Löhning, Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: robert.loehn...@theqtcompany.com | Mobile: + 49 151 1634 9248 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ 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 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] GIMP QML exporter script (project not on Gerrit)
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.commailto:goblincod...@gmail.com Date: Friday 9 January 2015 07:02 To: William Hallatt goblincod...@gmail.commailto:goblincod...@gmail.com Cc: development@qt-project.orgmailto:development@qt-project.org development@qt-project.orgmailto: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
[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
Hello
I think it's time to institute a policy that we should fix our sources to use
the new C++11 keywords. 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. For example, the new QIODevice::readLine overloads
QByteArray readLine(qint64 maxSize);
bool readLine(QByteArray *line, qint64 maxSize = -1);
In C++11, you could write
if (dev.readLine(Q_NULLPTR))// read a line and discard
But the code above would be ambiguous in C++98, so you can't use it.
Special: update code using Q_NULLPTR as you would update whitespace.
* Q_DECL_EQ_DEFAULT - really discouraged
I can't think of any case where you could use this and let the code still
compile in C++98, so don't use it
* Q_DECL_EQ_DELETE - strongly encouraged, use with care
Let's the compiler print an error instead of allowing a linker error for an
unresolved symbol.
* Q_DECL_CONSTEXPR / Q_DECL_RELAXED_CONSTEXPR - strongly encouraged
Use where it makes sense. If possible, use the C++11 restricted constexpr as
we have still too few compilers with C++14 relaxed constexpr support (Clang
3.5, GCC 5), but feel free to use Q_DECL_RELAXED_CONSTEXPR when there's benefit
for constexprness but impossible to solve in C++11
* 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.
* 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.
* Q_CONSTEXPR - use only where required
You probably don't need this. You'll need it when accessing const data from a
Q_DECL_CONSTEXPR function. Otherwise, you won't need it.
You could use this to create a static-initialisation-time const variable of a
non-POD type, but since our sources still compile in C++98 and we still have a
rule against non-POD statics, you should not do this.
* Q_DECL_NOTHROW / Q_DECL_NOEXCEPT - strongly encouraged
To public functions (all modules); any function in modules compiled with
exception (QtCore, QtXmlPatterns, QtConcurrent).
You probably want Q_DECL_NOTHROW instead of Q_DECL_NOEXCEPT.
Do not add to functions that:
* allocate memory
* call functions that may throw, especially user functions
* call POSIX cancellation points
* have narrow contracts -- that is, you could conceivably add a Q_ASSERT on
input parameters
If the function is an inline template function and the exception depends on
the template argument, use Q_DECL_NOEXCEPT_EXPR.
Non-C++11 but also useful:
* Q_DECL_{PURE,CONST}_FUNCTION - encouraged
A pure function is a function that will return the same value if called twice
with the same parameters. Pure functions are allowed to read from pointers
passed to it, including the this pointer. Pure functions are not allowed to
have observable side-effects (rule of thumb: no writing to dereferenced
pointers or to global variables).
A const function is a function that is pure and does not dereference any
pointers.
Quite by definition, const and pure functions cannot return void. Any such
calls would be discarded by the compiler.
--
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?
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] HEADS UP: Qt 5.4.1 release coming
Hi! And Happy New Year to you all! '5.4.1' branch is now available, please start using it for the changes targeted to Qt5.4.1 release. As written below we will merge '5.4' branch to '5.4.1' Friday 16th January so there should be enough time to finalize ongoing changes in '5.4'. All new changes for Qt5.4.1 should be done in '5.4.1' branch from now on. Br, Jani From: development-bounces+jani.heikkinen=theqtcompany@qt-project.org [mailto:development-bounces+jani.heikkinen=theqtcompany@qt-project.org] On Behalf Of Heikkinen Jani Sent: 22. joulukuuta 2014 8:05 To: development@qt-project.org Cc: releas...@qt-project.org Subject: [Development] HEADS UP: Qt 5.4.1 release coming Importance: High Hi all, Unfortunately there has been some severe issues in Qt 5.4.0 release so we need to start preparing Qt 5.4.1 release a bit earlier than planned. We are hoping we could put 5.4.1 out already during January and so on we need to branch '5.4.1' from '5.4' latest 16.1.2015. We will use 'soft branching' scheme like we did with 5.4.0 meaning Qt 5.4.1 branch will be created (latest) during week 2/2015 and downmerge from '5.4' to '5.4.1' will be done Friday 16th January 2015. That way everyone should have enough time to finalize ongoing changes in '5.4' branch start using '5.4.1' branch for the changes targeted to Qt 5.4.1 release. After 16th Jan '5.4' is for changes targeted to 5.4.2. And remember, we are doing patch level release now meaning do not put any new features / nice to have fix in it! There has been discussions with the developers that each change in the patch level release should have own change log entry as well. If change doesn't need change log entry then it doesn't belong to patch level release at all ;) Please make sure all issues blocking the Qt 5.4.1 release are linked to blocker meta bug: https://bugreports.qt-project.org/browse/QTBUG-43201 Also make sure all those are fixed early enough. We are already creating snapshots for 5.4.1 in http://download.qt.io/snapshots/qt/5.4/5.4.1/ for your testing verification purposes. br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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. 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? Regards, Konstantin Podsvirov ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A better headersclean test
-Original Message- From: development-bounces+mitch.curtis=theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira Sent: Tuesday, 6 January 2015 4:53 PM To: development@qt-project.org Subject: Re: [Development] A better headersclean test On Tuesday 06 January 2015 10:14:35 Curtis Mitch wrote: For development I usually do debug builds, so it would be nice to avoid the extra build time (and extra nagging during the build) most of the time, and just let CI enforce it, as long as that is reliable. +1 So I guess both of you are ok with having the option to opt-out with the default being to compile headers. Yeah, that's fine. -- 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 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] GIMP QML exporter script (project not on Gerrit)
I would actually be curious as to what functionality you are planning on adding aside from obviously updating it to Qt 5. The main reason I abandoned the plugin 5 years ago was the lack of support for grouped layers in Gimp at the time. I know this is no longer an issue so it should be possible to use layer groups in order to create and keep a hierarchy of QML items now. At least this would make it significantly better suited for QML exports. Regards, Jens On 07 Jan 2015, at 10:42, William Hallatt goblincod...@gmail.com wrote: Thanks for the replies! I am making progress...now to figure out how to get the Change-Id's in after the fact... :) On 7 January 2015 at 10:42, Liang Qi cavendish...@gmail.com mailto:cavendish...@gmail.com wrote: I guess you mean this on github, https://github.com/qtproject/qt-labs-gimp-qmlexporter https://github.com/qtproject/qt-labs-gimp-qmlexporter Then please contribute to https://codereview.qt-project.org/#/admin/projects/qt-labs/gimp-qmlexporter https://codereview.qt-project.org/#/admin/projects/qt-labs/gimp-qmlexporter Good luck! Regards, Liang On 7 January 2015 at 08:33, William Hallatt goblincod...@gmail.com mailto:goblincod...@gmail.com wrote: Good day, I forked and made some changes to Jens Bache-Wiig's original QML exporter script (GIMP only) on GitHub and was wondering if I could simply create a pull request for my changes? I have searched for the project on Gerrit, but it does not seem to exist there. Advice would be appreciated. Kind regards, William Hallatt ___ Development mailing list Development@qt-project.org mailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development http://lists.qt-project.org/mailman/listinfo/development -- http://www.qiliang.net http://www.qiliang.net/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jens Bache-Wiig http://www.cutehacks.com http://www.cutehacks.com/ Cross Platform Apps and Services ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++ QML Interface thoughts
Hi Bo, Thank you for your advice. I think one fault lies is my confidence of whether QML is right for the job due to my inexperience. Currently my GUI is QML which is fantastic but I'm still unsure on the best approach I will take for the backend. The motivation for the question is justifying the long term design, such as potentially supporting other language bindings, user defined scripting / implementations.One case study that made me think of using this approach, is from a talk at Dev Days 2012 for Ipo.Plan (https://www.youtube.com/watch?v=kvWeE3kurEQ) I know my reply isn't technical but perhaps someone knows a good resource that may help? Also, would you be happy to send a pdf of your slides from the talk you held Qt Dev Days? Huge Thanks, Luke On 7 January 2015 at 12:17, Bo Thorsen b...@vikingsoft.eu wrote: Den 06-01-2015 kl. 12:47 skrev Luke Parry: I am having issues trying to implement a c++ qml interface/wrapper that supports virtual overrides. Something functionally similar to boost::python would be excellent. This should be generic enough to also support non-QObject classes too so it rules out signals and slots. On first glance, it is fairly trivial to implement a wrapper that calls methods for the pointer, however implementing virtual overrides soon becomes difficult. I want to achieve something like this ( http://pastebin.com/t3k957Hf ) In principle, this would work creating instances in QML but not the other way transforming from a c++ instance. Is this feasible with QML without some compromise? I would like to think I'm missing something subtle or something blatantly obvious. Sounds to me like you're basically recreating the QObject based connection between QML and C++ without using QObject. That seems silly to me. If you're going to do this, accept that you're using QObject based subobjects and then you don't need to do this at all. Anyway, if you insist on doing this, the trick would probably be to make the QObject wrapper object have a pointer to the real non-QObject object. Use aggregation instead of inheritance. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ 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 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
