Re: [Development] Adding new third party component three.js to Qt?

[Knoll Lars]

On 08/01/15 18:05, "Thiago Macieira"  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)

[Turunen Tuukka]

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 mailto:goblincod...@gmail.com>>
Date: Friday 9 January 2015 07:02
To: William Hallatt mailto:goblincod...@gmail.com>>
Cc: "development@qt-project.org" 
mailto:development@qt-project.org>>
Subject: Re: [Development] GIMP QML exporter script (project not on Gerrit)

Thanks for all the assistance folks.  Finally managed to submit to Gerrit and 
sort out all the sanity bot's reviews :)

Have a good weekend,
William.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] GIMP QML exporter script (project not on Gerrit)

[William Hallatt]

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  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,  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 
>> 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  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 
>> >>> 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

[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Thiago Macieira]

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?

[Thiago Macieira]

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

Re: [Development] C++ QML Interface thoughts

[Luke Parry]

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  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] GIMP QML exporter script (project not on Gerrit)

[jensbw]

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  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  > 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  > 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 
> http://lists.qt-project.org/mailman/listinfo/development 
> 
> 
> 
> 
> 
> -- 
> 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 
Cross Platform Apps and Services

___
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

[Heikkinen Jani]

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] Adding new third party component three.js to Qt?

[Keränen Pasi]

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" 
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?

[Al-Khanji Louai]

> 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?

[Simon Hausmann]

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] A better headersclean test

[Curtis Mitch]

> -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] [QtIFW] Offline from online?

[Konstantin Podsvirov]

17.12.2014, 12:53, "Koehne Kai" :
> > - 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