date:20161129

Re: [Development] New library in qtbase

2016-11-29 Thread Samuel Gaist


> On 27 Nov 2016, at 20:44, Thiago Macieira  wrote:
> 
> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
>> Currently there’s macOS and iOS already working.
>> 
>> The plan is to add
>> - Android
>> - Linux through DBus
>> - Win10 (there will be some constraints if I understood their documentation
>> correctly)
> 
> How about the older X11 / XEmbed way?
> 
> -- 
> 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
> 


I was writing the list from memory and I forgot that one.

I haven’t took a deep look yet at it but I don’t see any reason to not have it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New library in qtbase

2016-11-29 Thread Samuel Gaist


> On 28 Nov 2016, at 01:05, Aleix Pol  wrote:
> 
> On Sat, Nov 26, 2016 at 12:51 AM, Samuel Gaist  
> wrote:
>> Hi,
>> 
>> As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d 
>> like to open a discussion about adding a new library in qtbase.
>> 
>> Why this discussion ?
>> 
>> Currently in work a pluggable notification system developed in its own 
>> library in qtbase.
>> 
>> Why add a new library ?
>> 
>> Originally the submission was integrated in QPA however after some thoughts 
>> and discussion, it was reworked to avoid that so that developers of non-GUI 
>> application could also take advantage of notifications without the need of a 
>> QGuiApplication.
>> 
>> One of my motivation to move the code in its own library was that the second 
>> implementation provided a run-time plugin selection mechanism much like the 
>> QtSql module. After further discussion, the plugin selection has been moved 
>> to build-time.
>> 
>> The library as it is currently could even be in its own repository however 
>> the goal in the long run is to replace the code used in QSystemTrayIcon by 
>> calls to this module which at this time duplicates the showMessage logic for 
>> macOS. Therefore having it as a separated repo would mean that qtbase would 
>> depend on it to be build which IMHO is not an option.
>> 
>> So basically we are at this point:
>> 
>> 1) Keep the new notifications module
>> 2) Move the code in the gui module since QImage might be used
>> 
>> In any case, the outcome of this discussion should likely be written in a 
>> QUIP so we have a clear set of rules about adding new libraries in existing 
>> Qt modules.
>> 
>> Thank you for your attention
> 
> This is very interesting! We've missed this in several occasions and
> at the moment it's a bit of a stopper for some KDE applications to
> flourish on some platforms (thinking of KDE Connect at the moment but
> I'm sure that others too).
> 
> IMHO the inflection point it's whether it's going to require
> QCoreApplication or QGuiApplication. Without having sat down into
> details, not only QImage but QIcon should also be part of the API. I'd
> say that QtGui will end up being required.
> 
> Aleix

That’s one of the “trick" I used, I didn’t put the QIcon interface on purpose. 
Without it you don’t need a QGuiApplication.

One possibility might be to do like Jake suggested and have one non-gui and one 
gui library provide by the module.

If we go with Allan's suggestion, putting it in QPA (which corresponds a bit 
like my first implementation), then there would be no way around a 
QGuiApplication.

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

Re: [Development] New library in qtbase

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 09:07:47 PST Samuel Gaist wrote:
> > On 27 Nov 2016, at 20:44, Thiago Macieira 
> > wrote:> 
> > On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
> >> Currently there’s macOS and iOS already working.
> >> 
> >> The plan is to add
> >> - Android
> >> - Linux through DBus
> >> - Win10 (there will be some constraints if I understood their
> >> documentation
> >> correctly)
> > 
> > How about the older X11 / XEmbed way?
> 
> I was writing the list from memory and I forgot that one.
> 
> I haven’t took a deep look yet at it but I don’t see any reason to not have
> it.

So it really looks like this should be part of QtGui with implementation in 
each QPA plugin.

-- 
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] Qt 5.9

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote:
> I have no idea what I'm getting when I download these packages. Why do we
> maintain an inconsistency for macOS versus the other two host platforms? I
> don't see why we can't simplify this process and have ONE platform per
> installer...

I agree with Jake.

People download the one they need first (now!). If they need something else 
later, they can just run the maintenance tool and have it install the rest.


-- 
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] CI error: "creation of work items failed"

2016-11-29 Thread Marc Mutz

Hi,

I'm seeing

 Continuous Integration: Cancelled

 Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
if it is not part of product (qt/qt5)

 Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444

errors on the CI for 5.8 recently (since yesterday?).

Would appreciate if someone looked into it.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
--- Begin Message ---
Qt CI Bot has posted comments on this change.

Change subject: QListViewItem: add constexpr
..


Continuous Integration: Cancelled

 Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
if it is not part of product (qt/qt5)

 Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444

 Tested changes (refs/builds/qtci/5.8/1480407442):
   
https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
 QListViewItem: add constexpr

-- 
To view, visit https://codereview.qt-project.org/173313
To unsubscribe, visit https://codereview.qt-project.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
Gerrit-PatchSet: 2
Gerrit-Project: qt/qtbase
Gerrit-Branch: 5.8
Gerrit-Owner: Marc Mutz 
Gerrit-Reviewer: Friedemann Kleint 
Gerrit-Reviewer: Giuseppe D'Angelo 
Gerrit-Reviewer: Marc Mutz 
Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) 
Gerrit-Reviewer: Qt Sanity Bot 
Gerrit-Reviewer: Sérgio Martins 
Gerrit-Reviewer: Thiago Macieira 
Gerrit-HasComments: No
--- End Message ---
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI error: "creation of work items failed"

2016-11-29 Thread Samuel Gaist


> On 29 Nov 2016, at 09:53, Marc Mutz  wrote:
> 
> Hi,
> 
> I'm seeing
> 
> Continuous Integration: Cancelled
> 
> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
> if it is not part of product (qt/qt5)
> 
> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> 
> errors on the CI for 5.8 recently (since yesterday?).
> 
> Would appreciate if someone looked into it.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> 
> From: "Qt CI Bot (Code Review)" 
> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr
> Date: 29 November 2016 at 09:17:31 GMT+1
> To: Marc Mutz 
> Cc: Friedemann Kleint , Qt Sanity Bot 
> , "Olivier Goffart (Woboq GmbH)" 
> , Thiago Macieira , Sérgio 
> Martins , Giuseppe D'Angelo 
> 
> Reply-To: qt_ci_...@qt-project.org
> 
> 
> Qt CI Bot has posted comments on this change.
> 
> Change subject: QListViewItem: add constexpr
> ..
> 
> 
> Continuous Integration: Cancelled
> 
> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
> if it is not part of product (qt/qt5)
> 
> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> 
> Tested changes (refs/builds/qtci/5.8/1480407442):
>   
> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
>  QListViewItem: add constexpr
> 
> -- 
> To view, visit https://codereview.qt-project.org/173313
> To unsubscribe, visit https://codereview.qt-project.org/settings
> 
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
> Gerrit-PatchSet: 2
> Gerrit-Project: qt/qtbase
> Gerrit-Branch: 5.8
> Gerrit-Owner: Marc Mutz 
> Gerrit-Reviewer: Friedemann Kleint 
> Gerrit-Reviewer: Giuseppe D'Angelo 
> Gerrit-Reviewer: Marc Mutz 
> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) 
> Gerrit-Reviewer: Qt Sanity Bot 
> Gerrit-Reviewer: Sérgio Martins 
> Gerrit-Reviewer: Thiago Macieira 
> Gerrit-HasComments: No
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

I just noticed that the same happened to dev

Regards

Samuel


Qt CI Bot has posted comments on this change.

Change subject: Add configurable connect timeout for QAbstractSocket
..


Continuous Integration: Cancelled

Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if 
it is not part of product (qt/qt5)

Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268

Tested changes (refs/builds/qtci/dev/1480349266):
  
https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z
 Add configurable connect timeout for QAbstractSocket

-- 
To view, visit https://codereview.qt-project.org/141210
To unsubscribe, visit https://codereview.qt-project.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I1dc4051be2c74f925f7a9e0a9ccef332efc2e370
Gerrit-PatchSet: 8
Gerrit-Project: qt/qtbase
Gerrit-Branch: dev
Gerrit-Owner: Samuel Gaist 
Gerrit-Reviewer: Alex Blasche 
Gerrit-Reviewer: Giuseppe D'Angelo 
Gerrit-Reviewer: Lorn Potter 
Gerrit-Reviewer: Markus Goetz (Woboq GmbH) 
Gerrit-Reviewer: Qt Sanity Bot 
Gerrit-Reviewer: Richard J. Moore 
Gerrit-Reviewer: Samuel Gaist 
Gerrit-Reviewer: Thiago Macieira 
Gerrit-HasComments: No

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

Re: [Development] CI error: "creation of work items failed"

2016-11-29 Thread Dominik Holland

Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist:
> 
>> On 29 Nov 2016, at 09:53, Marc Mutz  wrote:
>>
>> Hi,
>>
>> I'm seeing
>>
>> Continuous Integration: Cancelled
>>
>> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
>> if it is not part of product (qt/qt5)
>>
>> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
>>
>> errors on the CI for 5.8 recently (since yesterday?).
>>
>> Would appreciate if someone looked into it.
>>
>> Thanks,
>> Marc
>>
>> -- 
>> Marc Mutz  | Senior Software Engineer
>> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
>> Tel: +49-30-521325470
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> From: "Qt CI Bot (Code Review)" 
>> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr
>> Date: 29 November 2016 at 09:17:31 GMT+1
>> To: Marc Mutz 
>> Cc: Friedemann Kleint , Qt Sanity Bot 
>> , "Olivier Goffart (Woboq GmbH)" 
>> , Thiago Macieira , Sérgio 
>> Martins , Giuseppe D'Angelo 
>> 
>> Reply-To: qt_ci_...@qt-project.org
>>
>>
>> Qt CI Bot has posted comments on this change.
>>
>> Change subject: QListViewItem: add constexpr
>> ..
>>
>>
>> Continuous Integration: Cancelled
>>
>> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
>> if it is not part of product (qt/qt5)
>>
>> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
>>
>> Tested changes (refs/builds/qtci/5.8/1480407442):
>>   
>> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
>>  QListViewItem: add constexpr
>>
>> -- 
>> To view, visit https://codereview.qt-project.org/173313
>> To unsubscribe, visit https://codereview.qt-project.org/settings
>>
>> Gerrit-MessageType: comment
>> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
>> Gerrit-PatchSet: 2
>> Gerrit-Project: qt/qtbase
>> Gerrit-Branch: 5.8
>> Gerrit-Owner: Marc Mutz 
>> Gerrit-Reviewer: Friedemann Kleint 
>> Gerrit-Reviewer: Giuseppe D'Angelo 
>> Gerrit-Reviewer: Marc Mutz 
>> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) 
>> Gerrit-Reviewer: Qt Sanity Bot 
>> Gerrit-Reviewer: Sérgio Martins 
>> Gerrit-Reviewer: Thiago Macieira 
>> Gerrit-HasComments: No
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> Hi,
> 
> I just noticed that the same happened to dev
> 
> Regards
> 
> Samuel
> 
> 
> Qt CI Bot has posted comments on this change.
> 
> Change subject: Add configurable connect timeout for QAbstractSocket
> ..
> 
> 
> Continuous Integration: Cancelled
> 
> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
> if it is not part of product (qt/qt5)
> 
> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268
> 
> Tested changes (refs/builds/qtci/dev/1480349266):
>   
> https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z
>  Add configurable connect timeout for QAbstractSocket
> 

It seems to happen to all projects in the CI, regardless whether they
are part of qt5.git or not.

Dominik

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holl...@pelagicore.com
www.pelagicore.com

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

2016-11-29 Thread Konrad Rosenbaum

Hi,

On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote:
> Currently, MinGW builds in Coin use -system-zlib configuration. It happens
> because MinGW is shipped with zlib headers and libz.a. However, linking zlib
> to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is
> suboptimal, while with -system-zlib one copy in QtCore is shared between
> all modules.

Please be aware that there are quite a few Applications out there that use 
zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt 
does not expose its internal zlib headers, nor does it wrap all functionality 
of zlib. So at the very least qt-zlib needs to be linked in a way that allows 
an additional version of zlib to be linked.

Konrad

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

2016-11-29 Thread Kai Koehne

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Konrad Rosenbaum
> Sent: Tuesday, November 29, 2016 11:03 AM
> To: development@qt-project.org
> Subject: Re: [Development] Proposal: Use -qt-zlib configuration in official
> MinGW builds
> 
> Hi,
> 
> On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote:
> > Currently, MinGW builds in Coin use -system-zlib configuration. It
> > happens because MinGW is shipped with zlib headers and libz.a.
> > However, linking zlib to several Qt modules (at least, QtCore, QtGui,
> > QtNetwork, and QtSvg) is suboptimal, while with -system-zlib one copy
> > in QtCore is shared between all modules.
> 
> Please be aware that there are quite a few Applications out there that use
> zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt
> does not expose its internal zlib headers, nor does it wrap all functionality 
> of
> zlib. So at the very least qt-zlib needs to be linked in a way that allows an
> additional version of zlib to be linked.

This shouldn't be a problem, because the symbol ones from the internal version
are prefixed with "z_". See change 1f461ac45bf in qtbase.

Regards

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

2016-11-29 Thread Konstantin Tokarev



29.11.2016, 13:02, "Konrad Rosenbaum" :
> Hi,
>
> On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote:
>>  Currently, MinGW builds in Coin use -system-zlib configuration. It happens
>>  because MinGW is shipped with zlib headers and libz.a. However, linking zlib
>>  to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is
>>  suboptimal, while with -system-zlib one copy in QtCore is shared between
>>  all modules.
>
> Please be aware that there are quite a few Applications out there that use
> zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt
> does not expose its internal zlib headers, nor does it wrap all functionality
> of zlib.

qt-zlib builds provide zlib headers in include/QtZlib

> So at the very least qt-zlib needs to be linked in a way that allows
> an additional version of zlib to be linked.

zlib in QtCore is built with prefixed symbols.

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

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

2016-11-29 Thread Kai Koehne



> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Konstantin Tokarev
> Sent: Monday, November 28, 2016 3:11 PM
> To: development@qt-project.org
> Subject: [Development] Proposal: Use -qt-zlib configuration in official
> MinGW builds
> 
> Hello,
> 
> Currently, MinGW builds in Coin use -system-zlib configuration. It happens
> because MinGW is shipped with zlib headers and libz.a. However, linking zlib
> to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is
> suboptimal, while with -system-zlib one copy in QtCore is shared between all
> modules.

I think this is a good idea.

Could you create a suggestion for this on bugreports.qt.io, component 
"Packaging & Installer" (https://bugreports.qt.io/browse/QTBUG/component/19211) 
?

Thanks

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

2016-11-29 Thread Konstantin Tokarev



29.11.2016, 13:19, "Kai Koehne" :
>>  -Original Message-
>>  From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
>>  project.org] On Behalf Of Konstantin Tokarev
>>  Sent: Monday, November 28, 2016 3:11 PM
>>  To: development@qt-project.org
>>  Subject: [Development] Proposal: Use -qt-zlib configuration in official
>>  MinGW builds
>>
>>  Hello,
>>
>>  Currently, MinGW builds in Coin use -system-zlib configuration. It happens
>>  because MinGW is shipped with zlib headers and libz.a. However, linking zlib
>>  to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is
>>  suboptimal, while with -system-zlib one copy in QtCore is shared between all
>>  modules.
>
> I think this is a good idea.
>
> Could you create a suggestion for this on bugreports.qt.io, component 
> "Packaging & Installer" 
> (https://bugreports.qt.io/browse/QTBUG/component/19211) ?

Done: https://bugreports.qt.io/browse/QTBUG-57376

>
> Thanks
>
> Kai

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

Re: [Development] CI error: "creation of work items failed"

2016-11-29 Thread Simon Hausmann

Hi,


The bug was a file descriptor memory leak in coin, which was caused by a new 
upstream version of the python sh module. We

didn't pin the version, so we "accidentally" got a new version that had the 
leak. I've reverted to a non-leaking sh version and

am working on a test-case for an upstream bug report.



Simon


From: Development  on 
behalf of Dominik Holland 
Sent: Tuesday, November 29, 2016 10:50:20 AM
To: development@qt-project.org
Subject: Re: [Development] CI error: "creation of work items failed"

Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist:
>
>> On 29 Nov 2016, at 09:53, Marc Mutz  wrote:
>>
>> Hi,
>>
>> I'm seeing
>>
>> Continuous Integration: Cancelled
>>
>> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known
>> if it is not part of product (qt/qt5)
>>
>> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
>>
>> errors on the CI for 5.8 recently (since yesterday?).
>>
>> Would appreciate if someone looked into it.
>>
>> Thanks,
>> Marc
>>
>> --
>> Marc Mutz  | Senior Software Engineer
>> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
>> Tel: +49-30-521325470
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> From: "Qt CI Bot (Code Review)" 
>> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr
>> Date: 29 November 2016 at 09:17:31 GMT+1
>> To: Marc Mutz 
>> Cc: Friedemann Kleint , Qt Sanity Bot 
>> , "Olivier Goffart (Woboq GmbH)" 
>> , Thiago Macieira , Sérgio 
>> Martins , Giuseppe D'Angelo 
>> 
>> Reply-To: qt_ci_...@qt-project.org
>>
>>
>> Qt CI Bot has posted comments on this change.
>>
>> Change subject: QListViewItem: add constexpr
>> ..
>>
>>
>> Continuous Integration: Cancelled
>>
>> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
>> if it is not part of product (qt/qt5)
>>
>> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
>>
>> Tested changes (refs/builds/qtci/5.8/1480407442):
>>   
>> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
>>  QListViewItem: add constexpr
>>
>> --
>> To view, visit https://codereview.qt-project.org/173313
>> To unsubscribe, visit https://codereview.qt-project.org/settings
>>
>> Gerrit-MessageType: comment
>> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
>> Gerrit-PatchSet: 2
>> Gerrit-Project: qt/qtbase
>> Gerrit-Branch: 5.8
>> Gerrit-Owner: Marc Mutz 
>> Gerrit-Reviewer: Friedemann Kleint 
>> Gerrit-Reviewer: Giuseppe D'Angelo 
>> Gerrit-Reviewer: Marc Mutz 
>> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) 
>> Gerrit-Reviewer: Qt Sanity Bot 
>> Gerrit-Reviewer: Sérgio Martins 
>> Gerrit-Reviewer: Thiago Macieira 
>> Gerrit-HasComments: No
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> Hi,
>
> I just noticed that the same happened to dev
>
> Regards
>
> Samuel
>
>
> Qt CI Bot has posted comments on this change.
>
> Change subject: Add configurable connect timeout for QAbstractSocket
> ..
>
>
> Continuous Integration: Cancelled
>
> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
> if it is not part of product (qt/qt5)
>
> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268
>
> Tested changes (refs/builds/qtci/dev/1480349266):
>   
> https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z
>  Add configurable connect timeout for QAbstractSocket
>

It seems to happen to all projects in the CI, regardless whether they
are part of qt5.git or not.

Dominik

--
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holl...@pelagicore.com
www.pelagicore.com

___
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] Nominating Teemu Holappa for Approver and Maintainer status.

2016-11-29 Thread Kalle Viironen

+1 from me.

-Kalle

From: Development 
mailto:development-bounces+kalle.viironen=qt...@qt-project.org>>
 on behalf of Gatis Paeglis mailto:gatis.paeg...@qt.io>>
Date: Thursday 24 November 2016 15:00
To: "development@qt-project.org" 
mailto:development@qt-project.org>>
Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer 
status.

Hi,

I'd like to nominate Teemu Holappa for the Approver status. He joined Digia 
(now The Qt Company) 3+ years ago as a Qt consultant. Teemu has contributed to 
meta-boot2qt and anything else that needs fixing to get Qt for Device Creation 
releases out the door.

Here is his gerrit dashboard:

https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

Teemu also has done a good job at reviewing changes for meta-{boot2qt, qt5, 
mingw} among other projects:

https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

I'd also like to nominate him as the Maintainer of the qtdeviceutilities module 
(http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has heavily 
refactored this module and added significant amount of new features. He is the 
go-to guy in the team when qtdeviceutilities is the topic.

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

Re: [Development] Nominating Teemu Holappa for Approver and Maintainer status.

2016-11-29 Thread Samuli Piippo


On 24.11.2016 15:00, Gatis Paeglis wrote:

Hi,

I'd like to nominate Teemu Holappa for the Approver status. He joined
Digia (now The Qt Company) 3+ years ago as a Qt consultant. Teemu has
contributed to meta-boot2qt and anything else that needs fixing to get
Qt for Device Creation releases out the door.

Here is his gerrit dashboard:

https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

Teemu also has done a good job at reviewing changes for meta-{boot2qt,
qt5, mingw} among other projects:

https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

I'd also like to nominate him as the Maintainer of the qtdeviceutilities
module (http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has
heavily refactored this module and added significant amount of new
features. He is the go-to guy in the team when qtdeviceutilities is the
topic.


+1 for both, Teemu is now doing most of the work on qtdeviceutilities 
and makes sense to have him there as a Maintainer.


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

Re: [Development] Qt 5.9

2016-11-29 Thread Marco Piccolino

We just had a little discussion about this on QtMob (
http://slackin.qtmob.org) where everybody does iOS/Android, and most people
do it on a macOS host.
It looks like people tend to use the online installer.
When it comes to the offline installers (which in our case are mainly used
for checking out betas, it seems) an installer for each platform seems to
be the preferred option.
This said, it seems that the main concern for our mobile devs is actually
the size of the Qt for iOS distribution per se and people would like to
have the option to not install simulator builds.

Br,
Marco Piccolino - QtMob community manager
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

2016-11-29 Thread Jani Heikkinen

>>
>>From: Development  
>>on behalf of Thiago Macieira 
>>Sent: Tuesday, November 29, 2016 10:33 AM
>>To: development@qt-project.org
>>Subject: Re: [Development] Qt 5.9
>>
>>On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote:
>>> I have no idea what I'm getting when I download these packages. Why do we
>>> maintain an inconsistency for macOS versus the other two host platforms? I
>>> don't see why we can't simplify this process and have ONE platform per
>>> installer...
>>
>>I agree with Jake.
>>
>>People download the one they need first (now!). If they need something else
>>later, they can just run the maintenance tool and have it install the rest.

That is the case with online installation. With offline installer they cannot 
update new stuff by using maintenance tool :(  So users should prefer to online 
installers; with that they got biggest flexibility & smallest package size 
(online installer users are able to install just the stuff they need).

But there is still users who need offline installers and that's why combined 
installer (macOS, iOS + Android) is best for their purposes: If they don't need 
mobile platforms at all they can just use pure desktop one. But if they are 
doing mobile as well then they need to use that all-in-one offline solution.

That's why I still think we should proceed as I proposed: Keep online offering 
as it is but drop separate macos + android offline installer (have macOS and 
macOS + mobile targets for macOS offline offering). Decreasing our offline 
installer offering is essential; needed testing effort at the moment is really 
huge & it is increasing all the time because of these parallel releases. That's 
why we need to decrease stuff to be tested to make our live easier. 

And how to encourage users to use online installers instead of offline ones? 
One solution could be that we start using online ones at first & bring offline 
ones later. Earlier we have released beta with offline only so should we do 
this differently with Qt 5.9: 

Qt 5.9 alpha: src only
Qt 5.9 beta: online only
Qt 5.9 rc & final: online + offline

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

Re: [Development] CI error: "creation of work items failed"

2016-11-29 Thread Samuel Gaist


> On 29 Nov 2016, at 11:35, Simon Hausmann  wrote:
> 
> Hi,
> 
> The bug was a file descriptor memory leak in coin, which was caused by a new 
> upstream version of the python sh module. We
> didn't pin the version, so we "accidentally" got a new version that had the 
> leak. I've reverted to a non-leaking sh version and
> am working on a test-case for an upstream bug report.
> 
> 
> Simon

Thanks !

Samuel

> From: Development  
> on behalf of Dominik Holland 
> Sent: Tuesday, November 29, 2016 10:50:20 AM
> To: development@qt-project.org
> Subject: Re: [Development] CI error: "creation of work items failed"
>  
> Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist:
> > 
> >> On 29 Nov 2016, at 09:53, Marc Mutz  wrote:
> >>
> >> Hi,
> >>
> >> I'm seeing
> >>
> >> Continuous Integration: Cancelled
> >>
> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be 
> >> known 
> >> if it is not part of product (qt/qt5)
> >>
> >> Details: 
> >> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> >>
> >> errors on the CI for 5.8 recently (since yesterday?).
> >>
> >> Would appreciate if someone looked into it.
> >>
> >> Thanks,
> >> Marc
> >>
> >> -- 
> >> Marc Mutz  | Senior Software Engineer
> >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> >> Tel: +49-30-521325470
> >> KDAB - The Qt, C++ and OpenGL Experts
> >>
> >> From: "Qt CI Bot (Code Review)" 
> >> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr
> >> Date: 29 November 2016 at 09:17:31 GMT+1
> >> To: Marc Mutz 
> >> Cc: Friedemann Kleint , Qt Sanity Bot 
> >> , "Olivier Goffart (Woboq GmbH)" 
> >> , Thiago Macieira , Sérgio 
> >> Martins , Giuseppe D'Angelo 
> >> 
> >> Reply-To: qt_ci_...@qt-project.org
> >>
> >>
> >> Qt CI Bot has posted comments on this change.
> >>
> >> Change subject: QListViewItem: add constexpr
> >> ..
> >>
> >>
> >> Continuous Integration: Cancelled
> >>
> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be 
> >> known if it is not part of product (qt/qt5)
> >>
> >> Details: 
> >> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> >>
> >> Tested changes (refs/builds/qtci/5.8/1480407442):
> >>   
> >> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
> >>  QListViewItem: add constexpr
> >>
> >> -- 
> >> To view, visit https://codereview.qt-project.org/173313
> >> To unsubscribe, visit https://codereview.qt-project.org/settings
> >>
> >> Gerrit-MessageType: comment
> >> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
> >> Gerrit-PatchSet: 2
> >> Gerrit-Project: qt/qtbase
> >> Gerrit-Branch: 5.8
> >> Gerrit-Owner: Marc Mutz 
> >> Gerrit-Reviewer: Friedemann Kleint 
> >> Gerrit-Reviewer: Giuseppe D'Angelo 
> >> Gerrit-Reviewer: Marc Mutz 
> >> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) 
> >> Gerrit-Reviewer: Qt Sanity Bot 
> >> Gerrit-Reviewer: Sérgio Martins 
> >> Gerrit-Reviewer: Thiago Macieira 
> >> Gerrit-HasComments: No
> >>
> >>
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > Hi,
> > 
> > I just noticed that the same happened to dev
> > 
> > Regards
> > 
> > Samuel
> > 
> > 
> > Qt CI Bot has posted comments on this change.
> > 
> > Change subject: Add configurable connect timeout for QAbstractSocket
> > ..
> > 
> > 
> > Continuous Integration: Cancelled
> > 
> > Creation of work items failed: The module (qt/qtbase) sha1 needs to be 
> > known if it is not part of product (qt/qt5)
> > 
> > Details: 
> > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268
> > 
> > Tested changes (refs/builds/qtci/dev/1480349266):
> >   
> > https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z
> >  Add configurable connect timeout for QAbstractSocket
> > 
> 
> It seems to happen to all projects in the CI, regardless whether they
> are part of qt5.git or not.
> 
> Dominik
> 
> -- 
> Dominik Holland
> SENIOR SOFTWARE ENGINEER
> 
> Pelagicore AG
> Balanstr. 55, 81541 Munich, Germany
> +49 (0)171 760 25 96
> dominik.holl...@pelagicore.com
> www.pelagicore.com
> 
> ___
> 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] HEADS-UP: Branching from '5.8' to '5.8.0' complete

2016-11-29 Thread Oswald Buddenhagen

On Mon, Nov 21, 2016 at 01:50:04PM +, Jani Heikkinen wrote:
> We have started branching from '5.8' to '5.8.0'. Please start using
> '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be
> enough time to finalize ongoing changes in '5.8'; final downmerge will
> happen Monday 28th November.
> 
with just one day of delay, this has happened now.

changes on 5.8 are 5.8.1 material now.

have your release-critical 5.8 changes retargeted to 5.8.0 before you
integrate them. cherry-picks only in extraordinary circumstances, as
usual.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [HEADS-UP] Updates to branching scheme

2016-11-29 Thread Alberto Mardegan


On 11/25/2016 03:40 PM, Oswald Buddenhagen wrote:

i'm expecting a flurry of retargeting requests of changes from 5.6 and
5.7 to 5.8 now.


I have a few changes targeting 5.6 which are waiting for review:
https://codereview.qt-project.org/#/q/owner:%22Alberto+Mardegan%22+branch:5.6+status:open,n,z

Eventually I hope to find the time to propose them on the 5.8 branch, 
but given that these are changes I've already proposed and they are just 
waiting for a +2, and that I'm myself interested in 5.6 only at the 
moment, it would be sooo nice if someone would take care of 
cherry-picking them to 5.8. :-)


Ciao,
  Alberto

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

Re: [Development] New library in qtbase

2016-11-29 Thread Shawn Rutledge

> On 29 Nov 2016, at 09:07, Samuel Gaist  wrote:
> 
>> On 27 Nov 2016, at 20:44, Thiago Macieira  wrote:
>> 
>> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
>>> Currently there’s macOS and iOS already working.
>>> 
>>> The plan is to add
>>> - Android
>>> - Linux through DBus
>>> - Win10 (there will be some constraints if I understood their documentation
>>> correctly)
>> 
>> How about the older X11 / XEmbed way?
> 
> I was writing the list from memory and I forgot that one.
> 
> I haven’t took a deep look yet at it but I don’t see any reason to not have 
> it.

A system tray icon can emit notifications, but you aren’t putting the whole 
tray icon implementation into this library, are you?

XEmbed is a way of rendering tray icons, whereas we don’t need it for 
notifications themselves, right? because they are shown as separate windows.  
In some cases we render them; in others, the rendering is done in another 
desktop-wide process.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New library in qtbase

2016-11-29 Thread Shawn Rutledge

> On 28 Nov 2016, at 01:05, Aleix Pol  wrote:
> 
> This is very interesting! We've missed this in several occasions and
> at the moment it's a bit of a stopper for some KDE applications to
> flourish on some platforms (thinking of KDE Connect at the moment but
> I'm sure that others too).

By which you mean you want to develop an alternative plugin to send desktop 
notifications to a remote device?  Or something else?

I just tried KDE Connect for the first time last night, and was wondering why 
it won’t run outside of a Plasma session.  Is that related?

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

Re: [Development] New library in qtbase

2016-11-29 Thread Samuel Gaist


> On 29 Nov 2016, at 13:39, Shawn Rutledge  wrote:
> 
>> 
>> On 29 Nov 2016, at 09:07, Samuel Gaist  wrote:
>> 
>>> On 27 Nov 2016, at 20:44, Thiago Macieira  wrote:
>>> 
>>> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
 Currently there’s macOS and iOS already working.
 
 The plan is to add
 - Android
 - Linux through DBus
 - Win10 (there will be some constraints if I understood their documentation
 correctly)
>>> 
>>> How about the older X11 / XEmbed way?
>> 
>> I was writing the list from memory and I forgot that one.
>> 
>> I haven’t took a deep look yet at it but I don’t see any reason to not have 
>> it.
> 
> A system tray icon can emit notifications, but you aren’t putting the whole 
> tray icon implementation into this library, are you?
> 
> XEmbed is a way of rendering tray icons, whereas we don’t need it for 
> notifications themselves, right? because they are shown as separate windows.  
> In some cases we render them; in others, the rendering is done in another 
> desktop-wide process.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


No, I’m not. 

The idea is to implement the notification part which would be then used by 
QSystemTrayIcon.


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

Re: [Development] Qt 5.9

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 11:08:15 PST Jani Heikkinen wrote:
> With offline installer they cannot update new stuff by using maintenance
> tool 

Say what? Why not?

-- 
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] Qt 5.9

2016-11-29 Thread Jake Petroules


> On Nov 29, 2016, at 3:08 AM, Jani Heikkinen  wrote:
> 
>>> 
>>> From: Development  
>>> on behalf of Thiago Macieira 
>>> Sent: Tuesday, November 29, 2016 10:33 AM
>>> To: development@qt-project.org
>>> Subject: Re: [Development] Qt 5.9
>>> 
>>> On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote:
 I have no idea what I'm getting when I download these packages. Why do we
 maintain an inconsistency for macOS versus the other two host platforms? I
 don't see why we can't simplify this process and have ONE platform per
 installer...
>>> 
>>> I agree with Jake.
>>> 
>>> People download the one they need first (now!). If they need something else
>>> later, they can just run the maintenance tool and have it install the rest.
> 
> That is the case with online installation. With offline installer they cannot 
> update new stuff by using maintenance tool :( So users should prefer to 
> online installers; with that they got biggest flexibility & smallest package 
> size (online installer users are able to install just the stuff they need).
> 
> But there is still users who need offline installers and that's why combined 
> installer (macOS, iOS + Android) is best for their purposes: If they don't 
> need mobile platforms at all they can just use pure desktop one. But if they 
> are doing mobile as well then they need to use that all-in-one offline 
> solution.
> 
> That's why I still think we should proceed as I proposed: Keep online 
> offering as it is but drop separate macos + android offline installer (have 
> macOS and macOS + mobile targets for macOS offline offering). Decreasing our 
> offline installer offering is essential; needed testing effort at the moment 
> is really huge & it is increasing all the time because of these parallel 
> releases. That's why we need to decrease stuff to be tested to make our live 
> easier.

So don't test them. I'm not joking. There should be no reason to test every 
possible combination; just test each platform through the online installer and 
that should implicitly test that the offline one works.

Our process shouldn't be so flimsy and untrustworthy that we're testing every 
possible combination. Let the community do it, and if there's a problem, we'll 
surely know soon enough.

> And how to encourage users to use online installers instead of offline ones? 
> One solution could be that we start using online ones at first & bring 
> offline ones later. Earlier we have released beta with offline only so should 
> we do this differently with Qt 5.9: 
> 
> Qt 5.9 alpha: src only
> Qt 5.9 beta: online only
> Qt 5.9 rc & final: online + offline
> 
> br,
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Qt 5.9

2016-11-29 Thread Jake Petroules

> On Nov 29, 2016, at 2:54 AM, Marco Piccolino  
> wrote:
> 
> We just had a little discussion about this on QtMob 
> (http://slackin.qtmob.org) where everybody does iOS/Android, and most people 
> do it on a macOS host.
> It looks like people tend to use the online installer.
> When it comes to the offline installers (which in our case are mainly used 
> for checking out betas, it seems) an installer for each platform seems to be 
> the preferred option.
> This said, it seems that the main concern for our mobile devs is actually the 
> size of the Qt for iOS distribution per se and people would like to have the 
> option to not install simulator builds.

I guarantee you we'll never do that while qmake remains the Qt build system. 
But in Qt 5.9 when Qt is built as shared libraries for iOS, a lot of the excess 
size should be moved out into external dSYM (debug symbol) files which can be 
made an optional component in the online installer.

Also, 32-bit iOS is not long for this world, so we may be able to halve the 
size within the next few years when Apple removes all  32-bit support (even for 
applications) from iOS.

> Br,
> Marco Piccolino - QtMob community manager
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Qt 5.9

2016-11-29 Thread Alexander Nassian

Installing additional versions is broken and, more annoyingly (but I personally 
only have limited need for that) using the online installer behind a proxy is 
also broken (can't download meta).

Beste Grüße / Best regards,
Alexander Nassian

> Am 29.11.2016 um 18:22 schrieb Jake Petroules :
> 
> 
>> On Nov 29, 2016, at 2:54 AM, Marco Piccolino  
>> wrote:
>> 
>> We just had a little discussion about this on QtMob 
>> (http://slackin.qtmob.org) where everybody does iOS/Android, and most people 
>> do it on a macOS host.
>> It looks like people tend to use the online installer.
>> When it comes to the offline installers (which in our case are mainly used 
>> for checking out betas, it seems) an installer for each platform seems to be 
>> the preferred option.
>> This said, it seems that the main concern for our mobile devs is actually 
>> the size of the Qt for iOS distribution per se and people would like to have 
>> the option to not install simulator builds.
> 
> I guarantee you we'll never do that while qmake remains the Qt build system. 
> But in Qt 5.9 when Qt is built as shared libraries for iOS, a lot of the 
> excess size should be moved out into external dSYM (debug symbol) files which 
> can be made an optional component in the online installer.
> 
> Also, 32-bit iOS is not long for this world, so we may be able to halve the 
> size within the next few years when Apple removes all  32-bit support (even 
> for applications) from iOS.
> 
>> Br,
>> Marco Piccolino - QtMob community manager
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Jake Petroules - jake.petrou...@qt.io
> The Qt Company - Silicon Valley
> Qbs build tool evangelist - qbs.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] Qt 5.9

2016-11-29 Thread Roland Winklmeier

> On 28 Nov 2016, at 16:40, Alexander Blasche  wrote:
> 
> Ok, let's summarize and restate the package list for Qt 5.9 based on the 
> comments provided on this mail thread. The list describes the delta to Qt 5.8 
> packages:
> 
> * MinGW remains 5.3 using 32 bit

Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins for flight 
simulator applications which exist in 32 and 64 bit), I would be very happy to 
have both as official MinGW installers. Especially since the MinGW debug 
binaries are huge compared to the MSVC ones. So I tend to use 64 bit ones (up 
to now self compiled from source) whenever possible.
Would it be an option to add the MinGW 64 bit installer and keep the 32 bit one?

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

[Development] two questions about the build system of Qt

2016-11-29 Thread Cor-Paul Bezemer

Hi, I am a researcher in a team that is working on build systems and we are
doing a case study on missing dependencies in the Qt 5.3.0 build system. I
know that Qt 5.3.0 is an old version but the case study is part of a paper
that has been under review for more than a year now.

We found two things that we cannot explain.. Could anyone confirm/clarify
to me whether these are bugs in the build system or features?

1. In the Makefile in qtbase/tests/auto/other/qaccessibilitylinux, the
target cache_adaptor.h has no dependencies on the header files (e.g.
Qtcore/QObject) that it uses. Hence, if those header files change,
cache_adaptor.h (and therefore cache_adaptor.cpp) are never rebuilt, which
will leave .obj/cache_adaptor.o outdated. Or am I overlooking something?


2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has
a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build,
the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would
read the c++ file during the build? E.g. because c and c++ code is being
mixed? We do not observe similar behaviour (i.e., the c file being read by
g++) for targets that are compiled from .cpp files.

Thank you!

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

Re: [Development] Qt 5.9

2016-11-29 Thread Sergio Ahumada


On 29.11.2016 16:55, Thiago Macieira wrote:

On terça-feira, 29 de novembro de 2016 11:08:15 PST Jani Heikkinen wrote:

With offline installer they cannot update new stuff by using maintenance
tool


Say what? Why not?



I think he meant that you can't add new stuff .. say if you have a 
iOS-only offline installer, then you can't use that maintenance tool to 
install the android stuff .. you would need to download the android-only 
offline installer to install android (which, if it hasn't been fixed, 
will install a second instance of QtCreator)


that's why (AFAIR) the offline installer has everything 
(desktop+ios+android), if you only want iOS, then you unselect Android 
and problem solved


--
Sergio Ahumada
sahum...@texla.cl

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

Re: [Development] Qt 5.9

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 20:17:23 PST Sergio Ahumada wrote:
> > Say what? Why not?
> 
> I think he meant that you can't add new stuff .. say if you have a
> iOS-only offline installer, then you can't use that maintenance tool to
> install the android stuff .. you would need to download the android-only
> offline installer to install android (which, if it hasn't been fixed,
> will install a second instance of QtCreator)

I got it that you can't do it today.

The question is why we haven't fixed that. Sounds like a reasonable feature: 
you download the offline once and you only use the maintenance tool to update.

And if you can't even share the same Qt Creator installation, then it's an 
important bug.

> that's why (AFAIR) the offline installer has everything
> (desktop+ios+android), if you only want iOS, then you unselect Android
> and problem solved

Right, but that's upside down.

-- 
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] Qt 5.9

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 18:49:51 PST Roland Winklmeier wrote:
> > On 28 Nov 2016, at 16:40, Alexander Blasche 
> > wrote:
> > 
> > Ok, let's summarize and restate the package list for Qt 5.9 based on the
> > comments provided on this mail thread. The list describes the delta to Qt
> > 5.8 packages:
> > 
> > * MinGW remains 5.3 using 32 bit
> 
> Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins for
> flight simulator applications which exist in 32 and 64 bit), I would be
> very happy to have both as official MinGW installers. Especially since the
> MinGW debug binaries are huge compared to the MSVC ones. So I tend to use
> 64 bit ones (up to now self compiled from source) whenever possible. Would
> it be an option to add the MinGW 64 bit installer and keep the 32 bit one?

Agreed with Roland. I thought one of the major conclusions from this thread is 
that we would provide 64-bit MinGW with Qt 5.9. I don't see that in Alex's 
conclusion email.

-- 
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] two questions about the build system of Qt

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 13:53:41 PST Cor-Paul Bezemer wrote:
> 1. In the Makefile in qtbase/tests/auto/other/qaccessibilitylinux, the
> target cache_adaptor.h has no dependencies on the header files (e.g.
> Qtcore/QObject) that it uses. Hence, if those header files change,
> cache_adaptor.h (and therefore cache_adaptor.cpp) are never rebuilt, which
> will leave .obj/cache_adaptor.o outdated. Or am I overlooking something?

That file is generated during the build. It's created by qdbusxml2cpp by 
parsing src/3rdparty/atspi2/xml/Cache.xml. Since it's generated, it doesn't 
exist yet when qmake scans the source files for the dependencies. And we don't 
update that when compiling or when updating the Makefile.

> 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has
> a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build,
> the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would
> read the c++ file during the build? E.g. because c and c++ code is being
> mixed? We do not observe similar behaviour (i.e., the c file being read by
> g++) for targets that are compiled from .cpp files.

I can confirm it with strace. Seems like a bug because there is no C++ code 
mixed in for that particular compilation. You should check with GCC folks.

-- 
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] two questions about the build system of Qt

2016-11-29 Thread Thiago Macieira

On terça-feira, 29 de novembro de 2016 12:14:55 PST Thiago Macieira wrote:
> > 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has
> > a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build,
> > the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would
> > read the c++ file during the build? E.g. because c and c++ code is being
> > mixed? We do not observe similar behaviour (i.e., the c file being read by
> > g++) for targets that are compiled from .cpp files.
> 
> I can confirm it with strace. Seems like a bug because there is no C++ code
> mixed in for that particular compilation. You should check with GCC folks.

Looks like it's normal behaviour. Strace shows:

open("./.pch/Qt5Gui.t.gch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("./.pch/Qt5Gui.t.gch/c++", O_RDONLY|O_NOCTTY) = 4
open("./.pch/Qt5Gui.t.gch/c", O_RDONLY|O_NOCTTY) = 4

So it's actually reading from the directory and opening all files it finds 
there 
until it finds one that is a valid GCC preprocessor output for the current 
language. Since the buildsystem creates the C++ preprocessed header first (more 
files depend on it), it's first in the directory listing.

This is confirmed by running gcc with -H option. It prints:

x ./.pch/Qt5Gui.t.gch/c++
! ./.pch/Qt5Gui.t.gch/c

Its documentation says:

'-H'
 Print the name of each header file used, in addition to other
 normal activities.  Each name is indented to show how deep in the
 '#include' stack it is.  Precompiled header files are also printed,
 even if they are found to be invalid; an invalid precompiled header
 file is printed with '...x' and a valid one with '...!' .

-- 
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] two questions about the build system of Qt

2016-11-29 Thread Cor-Paul Bezemer

Thanks Thiago!

On Tue, Nov 29, 2016 at 3:37 PM, Thiago Macieira 
wrote:

> On terça-feira, 29 de novembro de 2016 12:14:55 PST Thiago Macieira wrote:
> > > 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui
> has
> > > a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the
> build,
> > > the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc
> would
> > > read the c++ file during the build? E.g. because c and c++ code is
> being
> > > mixed? We do not observe similar behaviour (i.e., the c file being
> read by
> > > g++) for targets that are compiled from .cpp files.
> >
> > I can confirm it with strace. Seems like a bug because there is no C++
> code
> > mixed in for that particular compilation. You should check with GCC
> folks.
>
> Looks like it's normal behaviour. Strace shows:
>
> open("./.pch/Qt5Gui.t.gch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("./.pch/Qt5Gui.t.gch/c++", O_RDONLY|O_NOCTTY) = 4
> open("./.pch/Qt5Gui.t.gch/c", O_RDONLY|O_NOCTTY) = 4
>
> So it's actually reading from the directory and opening all files it finds
> there
> until it finds one that is a valid GCC preprocessor output for the current
> language. Since the buildsystem creates the C++ preprocessed header first
> (more
> files depend on it), it's first in the directory listing.
>
> This is confirmed by running gcc with -H option. It prints:
>
> x ./.pch/Qt5Gui.t.gch/c++
> ! ./.pch/Qt5Gui.t.gch/c
>
> Its documentation says:
>
> '-H'
>  Print the name of each header file used, in addition to other
>  normal activities.  Each name is indented to show how deep in the
>  '#include' stack it is.  Precompiled header files are also printed,
>  even if they are found to be invalid; an invalid precompiled header
>  file is printed with '...x' and a valid one with '...!' .
>
> --
> 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] Qt 5.9

2016-11-29 Thread Sze Howe Koh

On 30 Nov. 2016 04:04, "Thiago Macieira"  wrote:
>
> On terça-feira, 29 de novembro de 2016 20:17:23 PST Sergio Ahumada wrote:
> > > Say what? Why not?
> >
> > I think he meant that you can't add new stuff .. say if you have a
> > iOS-only offline installer, then you can't use that maintenance tool to
> > install the android stuff .. you would need to download the android-only
> > offline installer to install android (which, if it hasn't been fixed,
> > will install a second instance of QtCreator)
>
> I got it that you can't do it today.
>
> The question is why we haven't fixed that. Sounds like a reasonable
feature:
> you download the offline once and you only use the maintenance tool to
update.

There's a related discussion at https://bugreports.qt.io/browse/QTBUG-32122

> And if you can't even share the same Qt Creator installation, then it's an
> important bug.

Yep, we can't even share the same Qt Creator installation:
https://forum.qt.io/topic/36275/how-to-install-multiple-qt-5-2-versions-on-windows-using-offline-installers

> > that's why (AFAIR) the offline installer has everything
> > (desktop+ios+android), if you only want iOS, then you unselect Android
> > and problem solved
>
> Right, but that's upside down.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center

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

Re: [Development] Qt 5.9

2016-11-29 Thread Alexander Blasche



> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: Tuesday, 29 November 2016 21:05
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.9
> 
> On terça-feira, 29 de novembro de 2016 18:49:51 PST Roland Winklmeier wrote:
> > > On 28 Nov 2016, at 16:40, Alexander Blasche
> > > 
> > > wrote:
> > >
> > > Ok, let's summarize and restate the package list for Qt 5.9 based on
> > > the comments provided on this mail thread. The list describes the
> > > delta to Qt
> > > 5.8 packages:
> > >
> > > * MinGW remains 5.3 using 32 bit
> >
> > Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins
> > for flight simulator applications which exist in 32 and 64 bit), I
> > would be very happy to have both as official MinGW installers.
> > Especially since the MinGW debug binaries are huge compared to the
> > MSVC ones. So I tend to use
> > 64 bit ones (up to now self compiled from source) whenever possible.
> > Would it be an option to add the MinGW 64 bit installer and keep the 32 bit
> one?
> 
> Agreed with Roland. I thought one of the major conclusions from this thread is
> that we would provide 64-bit MinGW with Qt 5.9. I don't see that in Alex's
> conclusion email.

The big problem is that there are still plenty of 32bit users because they 
truly use 32bit platforms or 3rdparty software forces them to do so. Moving to 
64 bit excludes users without alternatives. 32 bit does not exclude. Yes, I 
know this is a chicken and egg problem but right now we have reduced the 32bit 
package count for 5.9 already. Let's not rush too much.

> > 64 bit ones (up to now self compiled from source) whenever possible.
Mind you, Roland himself stated the continued need for 32 bit.

> > Would it be an option to add the MinGW 64 bit installer and keep the 32 bit
> one?

There are already 11 windows binary types/packages in the current setup and 
that's too many. I see some opportunity when 2013 drops out in the future.

--
Alex

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

Re: [Development] Qt 5.9

2016-11-29 Thread Alexander Blasche

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Jake Petroules

> > That's why I still think we should proceed as I proposed: Keep online 
> > offering
> as it is but drop separate macos + android offline installer (have macOS and
> macOS + mobile targets for macOS offline offering). Decreasing our offline
> installer offering is essential; needed testing effort at the moment is 
> really huge
> & it is increasing all the time because of these parallel releases. That's 
> why we
> need to decrease stuff to be tested to make our live easier.
> 
> So don't test them. I'm not joking. There should be no reason to test every
> possible combination; just test each platform through the online installer and
> that should implicitly test that the offline one works.

Sorry but that's not going to fly.

> Our process shouldn't be so flimsy and untrustworthy that we're testing every
> possible combination. Let the community do it, and if there's a problem, we'll
> surely know soon enough.

Software is a living and breathing thing. Its nature is such that it evolves 
changes each time. Not testing is not an option. We could have more confidence 
if history wouldn't proof us constantly wrong. Jake, even you had your fair 
share of breaks during release time. Stop breaking other platforms with your 
iOS changes and we can talk again ;)

You can use the online installer if you want only one mobile platform but not 
the other. Sure there is more MBs to download with offline but the releasing 
and testing effort is an even greater concern.

Dropping 32bit once Apple says so is a much more rewarding and likely 
opportunity.

> One solution could be that we start using online ones at first & bring 
> offline ones
> later. Earlier we have released beta with offline only so should we do this
> differently with Qt 5.9:
> >
> > Qt 5.9 alpha: src only
> > Qt 5.9 beta: online only

I am against this. Online installers are much harder to handle when you have to 
continuously install competing Qt versions. Testing requires to install 4 
different builds of Qt during for example beta time. Both types of builds have 
their advantage and testing/trialing is not one where the online installer 
shines.

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

Re: [Development] Qt 5.9

2016-11-29 Thread Thiago Macieira

On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote:
> The big problem is that there are still plenty of 32bit users because they
> truly use 32bit platforms or 3rdparty software forces them to do so. Moving
> to 64 bit excludes users without alternatives. 32 bit does not exclude.
> Yes, I know this is a chicken and egg problem but right now we have reduced
> the 32bit package count for 5.9 already. Let's not rush too much.

Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if 
possible to 5.8 too.

> There are already 11 windows binary types/packages in the current setup and
> that's too many. I see some opportunity when 2013 drops out in the future.

How are there 11? There are currently 3 compilers and 2 architectures for 
desktop Windows, so the maximum number possible is 6.

-- 
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] Qt 5.9

2016-11-29 Thread Jake Petroules


> On Nov 29, 2016, at 11:28 PM, Thiago Macieira  
> wrote:
> 
> On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote:
>> The big problem is that there are still plenty of 32bit users because they
>> truly use 32bit platforms or 3rdparty software forces them to do so. Moving
>> to 64 bit excludes users without alternatives. 32 bit does not exclude.
>> Yes, I know this is a chicken and egg problem but right now we have reduced
>> the 32bit package count for 5.9 already. Let's not rush too much.
> 
> Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and 
> if 
> possible to 5.8 too.
> 
>> There are already 11 windows binary types/packages in the current setup and
>> that's too many. I see some opportunity when 2013 drops out in the future.
> 
> How are there 11? There are currently 3 compilers and 2 architectures for 
> desktop Windows, so the maximum number possible is 6.

I think you're forgetting WinRT? Also 2015 x86+x86_64+armv7 + 2013 x86 + 
armv7(phone), making 11.

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

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Qt 5.9

2016-11-29 Thread Jake Petroules

> On Nov 29, 2016, at 11:28 PM, Alexander Blasche  
> wrote:
> 
>> -Original Message-
>> From: Development [mailto:development-
>> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Jake Petroules
> 
>>> That's why I still think we should proceed as I proposed: Keep online 
>>> offering
>> as it is but drop separate macos + android offline installer (have macOS and
>> macOS + mobile targets for macOS offline offering). Decreasing our offline
>> installer offering is essential; needed testing effort at the moment is 
>> really huge
>> & it is increasing all the time because of these parallel releases. That's 
>> why we
>> need to decrease stuff to be tested to make our live easier.
>> 
>> So don't test them. I'm not joking. There should be no reason to test every
>> possible combination; just test each platform through the online installer 
>> and
>> that should implicitly test that the offline one works.
> 
> Sorry but that's not going to fly.
> 
>> Our process shouldn't be so flimsy and untrustworthy that we're testing every
>> possible combination. Let the community do it, and if there's a problem, 
>> we'll
>> surely know soon enough.
> 
> Software is a living and breathing thing. Its nature is such that it evolves 
> changes each time. Not testing is not an option. We could have more 
> confidence if history wouldn't proof us constantly wrong. Jake, even you had 
> your fair share of breaks during release time. Stop breaking other platforms 
> with your iOS changes and we can talk again ;)
> 
> You can use the online installer if you want only one mobile platform but not 
> the other. Sure there is more MBs to download with offline but the releasing 
> and testing effort is an even greater concern.
> 
> Dropping 32bit once Apple says so is a much more rewarding and likely 
> opportunity.

How about we have one package per host platform which includes all possible 
hosts and targets compatible with it? Then we have 3 packages, ever.

If our releasing and testing effort is the #1 concern over anything else, then 
having multi-gigabyte packages should not be a problem. We can then have:

Windows host: includes Windows 
(i386-2015,x86_64-2015,i386-2015-winrt,x86_64-2015-winrt,armv7-2015-winrt) + 
Android (armv7,x86)
macOS host: includes macOS (x86_64) + iOS (armv7,arm64,i386,x86_64) + Android 
(armv7,x86)
Linux host: includes Linux (x86_64) + Android (armv7,x86) + QNX (armv7,x86)?

By this estimation the Windows one would be around 3.5 GB (maybe less), about 
the same as the combined macOS+iOS+Android installer. In fact, because the 
WinRT and desktop binaries should be identical or very similar in many cases, 
they might compress even better than that (and/or we can look into the 
possibility of creating a unified Windows build whose DLLs work in either a 
classic desktop OR WinRT environment, and switch on the platform plugin. not 
sure to what degree that's possible)

We could add the two 2013 builds (2013 WinRT is dead, so 2, not 4 or 5) and the 
MinGW to the Windows installer, ballooning it to around 6 GB or so (again, this 
may be totally fine), or we could separate those into 1 or 2 extra installers. 
Then we have between 3 and 5 rather than 13 like the 5.8 beta has currently.

I don't know how useful the offline installers really are, so having the few 
users suffer a bit over longer download times should be OK given the nice 
tradeoff in testing. 90% of users should be on the online installer anyways.

So, any good reasons we shouldn't do this?

> 
>> One solution could be that we start using online ones at first & bring 
>> offline ones
>> later. Earlier we have released beta with offline only so should we do this
>> differently with Qt 5.9:
>>> 
>>> Qt 5.9 alpha: src only
>>> Qt 5.9 beta: online only
> 
> I am against this. Online installers are much harder to handle when you have 
> to continuously install competing Qt versions. Testing requires to install 4 
> different builds of Qt during for example beta time. Both types of builds 
> have their advantage and testing/trialing is not one where the online 
> installer shines.
> 
> --
> Alex

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

41 matches

Mail list logo