Re: [Development] QML preprocessor

[Thiago Macieira]

On Tuesday, 19 March 2019 09:03:16 PDT Jason H wrote:
> I don't know why you can't just use a C/C++ preprocessor to generate the
> qml? For Clang,   -E : Only run the preprocessor

qglobal.h is assembler-safe too. -D__ASSEMBLER__ and it won't produce C or C++ 
code that would confuse your parser.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] QML preprocessor

[Jason H]

> On 18/03/19 12:11, Pierre-Yves Siret wrote:
> > This can be done with QQmlFileSelector :
> > 
> >     QQmlApplicationEngine engine;
> >     QQmlFileSelector* qmlFileSelector = QQmlFileSelector::get();
> > 
> > #if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0)
> >     qmlFileSelector->setExtraSelectors({"5.12"});
> > #endif
> > 
> >     engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
> > 
> > This will load qrc:/+5.12/main.qml (if there's one) instead of
> > qrc:/main.qml when the Qt version is >= 5.12.
> 
> Of all suggestions, this is probably the one having the least
> performance impact and greater readability. It still doesn't solve the
> code duplication issue (Samuel's does, but with a greater runtime
> impact), though. :-(
> 
> Anyway, thanks all!
> 
> (I'm still looking forward to see this issue addressed at the QML
> language level, though :-) )

I don't know why you can't just use a C/C++ preprocessor to generate the qml?
For Clang,   -E : Only run the preprocessor

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

Re: [Development] Coin production update

[Aapo Keskimölö]

Due to poor performance and stale integrations we have decided to revert 
the Coin baseline on


  Tue Mar 19 14:34:03 UTC 2019


Reverted patches from previous state:

https://testresults.qt.io/ci/aakeskim/production_updates/changelog_20190319_reverted


Currently active production:

https://testresults.qt.io/ci/aakeskim/production_updates/HEAD

https://testresults.qt.io/ci/aakeskim/production_updates/cherrypicks


On 3/13/19 2:45 PM, Aapo Keskimölö wrote:
> Hi Qt developers,
>
>
> Coin production has been updated on
>
>
> Wed Mar  13 10:53:55 UTC 2019
>
>
> Merge master->production:
>
> https://testresults.qt.io/ci/aakeskim/production_updates/changelog_20190313 
>
>
> Cherrypicks in production:
>
> https://testresults.qt.io/ci/aakeskim/production_updates/cherrypicks
>
>
> You can find instructions for reporting bugs here:
>
> https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_CI
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Brett Stottlemeyer for Approver status

[Thiago Macieira]

On Monday, 18 March 2019 01:05:22 PDT Ville Voutilainen wrote:
> Brett is the maintainer of Qt Remote Objects. Thus he should be 
> documented as a maintainer, and should also be an approver. Brett has 
> been effectively maintaining QRO since 2014, so it seems like a slam 
> dunk to give him the rights.

+1, of course.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes planned for the online installer

[Sze Howe Koh]

Thanks for the initiative, Tuuka and team. Much appreciated.

As part of the meeting, please review the points raised in previous
discussions [1][2]. Three major pain points were:

(A) Downloading metadata is very time-consuming.
(B) The automatic mirror selection algorithm doesn't always pick
the best mirror.
(C) (New users) It's not clear how to choose what to install.

The changes you described, as well as Fabrice's suggestions, seem to
address (A) quite nicely.

I made a tool to help with (B), but it was meant to be a quick and
dirty hack [3]. I didn't expect it to still be in use 5 years later.
Please provide the ability to override the default mirror within the
installer itself.

I believe the documentation team discussed on-boarding techniques as
part of their workshop last week [4]. Please work with them to address
(C) in a holistic manner.


Regards,
Sze-Howe

[1] https://lists.qt-project.org/pipermail/development/2018-April/032461.html
("To improve UX of the online installer") and subsequent replies
[2] https://bugreports.qt.io/browse/QTIFW-1132
[3] 
https://forum.qt.io/topic/43349/slow-downloads-with-the-online-installer-try-this-tool
[4] https://blog.qt.io/blog/2019/03/01/the-future-of-documentation/

On Tue, 19 Mar 2019 at 21:12, Fabrice Mousset | GEOCEPT GmbH
 wrote:
>
> Hi,
>
> It is great to hear there will be done some update on Maintenance Tool
>
> I don’t know about internal architecture of the software, but it would be 
> great if Maintenance Tool could handle locally a little “cache” to avoid 
> always (re)downloading from server all information about Qt releases.
>
> Each time Maintenance Tool is launched, it downloads almost the same stuff (I 
> think) for Qt Servers. It would be much faster to store this information 
> locally in little “database” (XML or SQLite for example) with a MD5SUM as 
> Checksum. This would speed up the boot process when nothing new on server 
> between 2 starts and, I think, this will also consume less server resources.
>
> My two cents.
>
> Fabrice
>
> 
> Von: Development  Im Auftrag von Tuukka 
> Turunen
> Gesendet: Dienstag, 19. März 2019 13:33
> An: development@qt-project.org; releas...@qt-project.org
> Betreff: [Development] Changes planned for the online installer
>
>
> Hi,
>
> Online installer has over time become quite crowded with different releases 
> and many have noticed that it is getting quite slow at times. Having all this 
> default content is also problematic for those who mirror Qt as it would take 
> a significant amount of disk space to have a complete mirror.
>
> From user viewpoint it could be seen handy that all these different releases 
> are available via the online installer, but there are caveats. One major item 
> is security. We always recommend to take the latest supported patch release, 
> but have offered also all the old ones. It should be more clear than today to 
> users what release to take. Unsupported releases contain multiple known 
> vulnerabilities and should not be used.
>
> With an upcoming version of the online installer, we are planning to make the 
> following changes:
>
> * Separate the pre-releases to its own ‘preview’ category, only visible when 
> enabled
> * Remove all unsupported Qt releases from the online installer
> * Move all but the latest patch releases of supported Qt releases into 
> ‘archive’ category
>
> This allows for greatly improved user experience of the online installer, 
> focuses users to take the latest release with all security updates and 
> reduces the space needed from the mirrors.
>
> Commercial online installer uses Amazon CDN and for the commercial users we 
> are planning to offer some the older, unsupported releases. There is also 
> extended support available for those commercial license holders who are using 
> an otherwise unsupported release of Qt.
>
> Old Qt releases continue to be available for everyone in the download.qt.io 
> historical archive, but in general they should be considered as a historical 
> reference, not used in active projects.
>
> Feedback and thoughts welcome. The topic could also be taken to the agenda of 
> next week’s release team meeting?
>
> Yours,
>
> Tuukka
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes planned for the online installer

[Fabrice Mousset | GEOCEPT GmbH]

Hi,

It is great to hear there will be done some update on Maintenance Tool 
I don’t know about internal architecture of the software, but it would be great 
if Maintenance Tool could handle locally a little “cache” to avoid always 
(re)downloading from server all information about Qt releases.
Each time Maintenance Tool is launched, it downloads almost the same stuff (I 
think) for Qt Servers. It would be much faster to store this information 
locally in little “database” (XML or SQLite for example) with a MD5SUM as 
Checksum. This would speed up the boot process when nothing new on server 
between 2 starts and, I think, this will also consume less server resources.

My two cents.

Fabrice

Von: Development  Im Auftrag von Tuukka 
Turunen
Gesendet: Dienstag, 19. März 2019 13:33
An: development@qt-project.org; releas...@qt-project.org
Betreff: [Development] Changes planned for the online installer


Hi,

Online installer has over time become quite crowded with different releases and 
many have noticed that it is getting quite slow at times. Having all this 
default content is also problematic for those who mirror Qt as it would take a 
significant amount of disk space to have a complete mirror.

From user viewpoint it could be seen handy that all these different releases 
are available via the online installer, but there are caveats. One major item 
is security. We always recommend to take the latest supported patch release, 
but have offered also all the old ones. It should be more clear than today to 
users what release to take. Unsupported releases contain multiple known 
vulnerabilities and should not be used.

With an upcoming version of the online installer, we are planning to make the 
following changes:

  *   Separate the pre-releases to its own ‘preview’ category, only visible 
when enabled
  *   Remove all unsupported Qt releases from the online installer
  *   Move all but the latest patch releases of supported Qt releases into 
‘archive’ category

This allows for greatly improved user experience of the online installer, 
focuses users to take the latest release with all security updates and reduces 
the space needed from the mirrors.

Commercial online installer uses Amazon CDN and for the commercial users we are 
planning to offer some the older, unsupported releases. There is also extended 
support available for those commercial license holders who are using an 
otherwise unsupported release of Qt.

Old Qt releases continue to be available for everyone in the 
download.qt.io historical archive, but in general they 
should be considered as a historical reference, not used in active projects.

Feedback and thoughts welcome. The topic could also be taken to the agenda of 
next week’s release team meeting?

Yours,

Tuukka





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

[Development] Qt 5.13.0 Beta1 released

[Jani Heikkinen]

HI all,

We have released Qt 5.13.0 Beta1 today, see 
https://blog.qt.io/blog/2019/03/19/qt-5-13-0-beta1-released/

Big thanks to everyone involved!

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Changes planned for the online installer

[Tuukka Turunen]

Hi,

Online installer has over time become quite crowded with different releases and 
many have noticed that it is getting quite slow at times. Having all this 
default content is also problematic for those who mirror Qt as it would take a 
significant amount of disk space to have a complete mirror.

From user viewpoint it could be seen handy that all these different releases 
are available via the online installer, but there are caveats. One major item 
is security. We always recommend to take the latest supported patch release, 
but have offered also all the old ones. It should be more clear than today to 
users what release to take. Unsupported releases contain multiple known 
vulnerabilities and should not be used.

With an upcoming version of the online installer, we are planning to make the 
following changes:

  *   Separate the pre-releases to its own ‘preview’ category, only visible 
when enabled
  *   Remove all unsupported Qt releases from the online installer
  *   Move all but the latest patch releases of supported Qt releases into 
‘archive’ category

This allows for greatly improved user experience of the online installer, 
focuses users to take the latest release with all security updates and reduces 
the space needed from the mirrors.

Commercial online installer uses Amazon CDN and for the commercial users we are 
planning to offer some the older, unsupported releases. There is also extended 
support available for those commercial license holders who are using an 
otherwise unsupported release of Qt.

Old Qt releases continue to be available for everyone in the 
download.qt.io historical archive, but in general they 
should be considered as a historical reference, not used in active projects.

Feedback and thoughts welcome. The topic could also be taken to the agenda of 
next week’s release team meeting?

Yours,

Tuukka





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

Re: [Development] Nominating Brett Stottlemeyer for Approver status

[Alex Blasche]

+1 from me too.

--
Alex


From: Development  on behalf of Ville 
Voutilainen 
Sent: Monday, 18 March 2019 9:05:22 AM
To: development@qt-project.org
Subject: [Development] Nominating Brett Stottlemeyer for Approver status

Brett is the maintainer of Qt Remote Objects. Thus he should be
documented as a maintainer, and should also be an approver. Brett has
been effectively maintaining QRO since 2014, so it seems like a slam
dunk to give him the rights.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Continuous Integration for 3rd party projects using Qt

[Jedrzej Nowacki]

On Tuesday, March 19, 2019 7:55:53 AM CET Uwe Rathmann wrote:
> Hi all,
> 
> in the end all advice goes into the direction of using one of the
> standard services in combination with using my own brain when working on
> the code.
> 
> Unfortunately nobody pointed out a realistic way how a 3rd party project
> could make use of the infrastructure used by the Qt project nor did
> anyone seem to like this idea enough to think it through.
> 
> Anyway - thanks for all the valuable thoughts and links,
> 
> Uwe
> 

Hi,

 Coin is able to build and tests practically any qmake and >qt5.6 (soon qt5.9) 
based project. It has to be hosted on codereview.qt-project.org, there is 
limited support for git.qt.io or github.com (can not work as a gate keeper). 
There is no SVN support at all. Qt4 support would be a pain in general, 
because of many reasons.

  Qt project CI is for modules that closely follow Qt, including coding style 
as well as release cycle. It is not a general CI, it could be, as it is not 
that far from it, but it is not. There is an ongoing effort to simplify 
3rdparty modules builds ("Qt modules, API changes and Qt 6" 
https://lists.qt-project.org/pipermail/development/2019-January/035018.html), 
but even then I 
would not expect to build against anything older then the oldest LTS. The 
build system, platform configurations, dependencies are changing too quickly 
and all modules needs to follow.

Cheers,
  Jędrek


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

Re: [Development] Nominating Brett Stottlemeyer for Approver status

[Volker Krause via Development]

I was under the same impression, +1 from me too of course.

Regards,
Volker

On Monday, 18 March 2019 12:23:29 CET Lars Knoll wrote:
> Obvious +1, I thought he had those rights already since a long time.
> 
> Cheers,
> Lars
> 
> On 18 Mar 2019, at 10:07, Simon Hausmann
> mailto:simon.hausm...@qt.io>> wrote:
> 
> 
> +1 to the slam dunk of making Brett approver :). He's great to work with,
> always positive and I certainly trust him on the approval process.
> 
> 
> Simon
> 
> From: Development
> mailto:development-bounces@qt-project.o
> rg>> on behalf of Ville Voutilainen
> mailto:ville.voutilai...@qt.io>> Sent: Monday,
> March 18, 2019 9:05
> To: development@qt-project.org
> Subject: [Development] Nominating Brett Stottlemeyer for Approver status
> 
> Brett is the maintainer of Qt Remote Objects. Thus he should be
> documented as a maintainer, and should also be an approver. Brett has
> been effectively maintaining QRO since 2014, so it seems like a slam
> dunk to give him the rights.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Volker Krause | volker.kra...@kdab.com | Director of Engineering
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel. +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Continuous Integration for 3rd party projects using Qt

[Uwe Rathmann]

Hi all,

in the end all advice goes into the direction of using one of the 
standard services in combination with using my own brain when working on 
the code.

Unfortunately nobody pointed out a realistic way how a 3rd party project 
could make use of the infrastructure used by the Qt project nor did 
anyone seem to like this idea enough to think it through.

Anyway - thanks for all the valuable thoughts and links,

Uwe

 

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