Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Friday, 9 February 2024 06:45:30 PST Volker Hilsheimer via Development 
wrote:
> The 3 big C++20 features people ask us about are modules, co-routines, and
> concepts. We have no compelling answers here. You can’t build Qt into a set
> of modules; we have no APIs using co-routines; none of our template
> constraints are expressed, or at least documented, as concepts, and there
> is no draft of a concept library for things that might be interesting for
> Qt users.

This change requires one concept:
https://codereview.qt-project.org/c/qt/qtbase/+/536993/7

I added a fallback to C++17. I make no promises that it has the same level of 
compatibility as the C++20 official concept. In fact, I know it doesn't. It 
will 
reject some types and accept others that it shouldn't.

That's QHash. That means we need to be sure we won't cause problems for 
existing users. I have absolutely no problem in making this feature only 
accessible in C++20, if need be.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Raising the minimum to C++20

[Giuseppe D'Angelo via Development]

Il 09/02/24 15:45, Volker Hilsheimer via Development ha scritto:
So, as much as I’d like for some of the things I’m working on to be able 
to benefit from C++ 20, I’d also say that we should rather slow down, 
and only require C++20 if we have something to show for it. We can 
perhaps still make improvements to better enable C++20 features, such as 
std::ranges, in application code; but that should neither require Qt to 
be built with C++20, nor require applications that don’t use std::ranges 
to use C++20.


An orthogonal but related question, do we see any advantage at requiring 
a C++20 build of Qt in order to use C++20 features with it? Insofar 
we've provided C++20-related APIs as entirely inline (under #ifdef 
protection, plus some export-relating shenanigans -- Q_POST_CXX17_API 
and so on). I'm not sure if somewhere we'd really like to move stuff out 
of line and thus require a C++20 build of Qt if you want to use those 
features.


My 2 c,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence



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

Re: [Development] Raising the minimum to C++20

[apoenitz]

On Fri, Feb 09, 2024 at 06:51:44PM +0100, Philippe wrote:
> >So, as much as I'd like for some of the things I'mworking on to be
> >able to benefit from C++ 20, I'd also say that we should rather slow
> >down, and only require C++20 if we have something to show for it.
> 
> C++20 makes for a more enjoyable coding experience; this human factor
> should not be ruled out of the equation.
>
> With the key to sometimes more readable code and a certain gain in
> productivity.

This is an argument in favour of making it possible to /use/ Qt in a
C++20-using environment or application.

This is already possible right now. Nobody stops anyone from using C++20
in their own code of a Qt-based application and enjoy all the coding
experience found that way,

But that's only loosely related to the suggestion in the original
message in this thread which was asking to make C++20 mandatory to use
for all Qt users, which has the potential to leave behind people and
projects who cannot simply use a C++20, be it that there is no such
thing as a C++20-capable compiler in the environment they (have to)
live in, or that they are simply lacking the resources to adapt
their enviroment, or that they have other restrictions in their
overall setup that prevent arbitrary changes to their environment.

Qt benefits from a very broad range of users. For me it seems
counter-productive to leave people behind needlessly. Insofar I agree
with the previously voiced sentiments that convincing arguments to
_force_ people into a C++20 environment (or drop the use of Qt) have
not been presented yet.

This is not saying such argument cannot exist, it's just not clear - at
least to me - what they may be. So if you - who is apparently a happy
user of C++20 - have examples what C++20 features make the coding
experience better to a degree to compensate for the potential loss on
the other side, I am all eears.

Andre'

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

Re: [Development] Raising the minimum to C++20

[Ahmad Samir]

On 9/2/24 16:45, Volker Hilsheimer via Development wrote:

I haven’t heard any convincing argument for us raising the minimum to C++ 20 in 
the foreseeable future. Not for building Qt, and not for using Qt.

At most we get some convenience constructs for ourselves. There’s value in that, of 
course. But unless I miss something huge, then that value is quite small. We have a 
working implementation of e.g. atomics that is sufficient for our own needs; we have 
our own implementation of . We now also have QSpan, which we practically 
don’t use anywhere in Qt so far. And that value is of practically no relevance to 
users of Qt - they can use C++20 in their application, together with Qt.

The 3 big C++20 features people ask us about are modules, co-routines, and 
concepts. We have no compelling answers here. You can’t build Qt into a set of 
modules; we have no APIs using co-routines; none of our template constraints 
are expressed, or at least documented, as concepts, and there is no draft of a 
concept library for things that might be interesting for Qt users.

Do we really want to go out and say that C++20 is now mandatory to build or use 
Qt, while we have no convincing story on any of that? Do we want to ask people 
to make a significant investment if they want to work with the latest Qt 
version, but even then they don’t get any support for any of the big three 
features?

So, as much as I’d like for some of the things I’m working on to be able to 
benefit from C++ 20, I’d also say that we should rather slow down, and only 
require C++20 if we have something to show for it. We can perhaps still make 
improvements to better enable C++20 features, such as std::ranges, in 
application code; but that should neither require Qt to be built with C++20, 
nor require applications that don’t use std::ranges to use C++20.


Volker




The way KDE Frameworks and Plasma have raised the minimum required C++ version 
was
asking distributions "do you have a problem if we require C++17?" and the answer
was "we have recent enough gcc/clang, so go ahead if you want", so Plasma 5 and 
KF5 raised the minimum required to C++17 during the lifetime of KF5 (with the 
caveat, IIRC, of not using C++17-only headers unconditionally in public header 
files). Last time I checked, Plasma 6.0 now requires C++20, using the same process 
outlined above.


I wonder if this can be done here too. Can you survey Linux distro 
developers/maintainers, your customers and other point-of-contacts? This way you 
will have a clearer picture of the situation, and can make an informed decision.


For example I've started compiling with C++20 locally about 4-5 months ago, the CI 
still uses C++17, I have seen very few issues.


My 2p's.

Regards,
Ahmad Samir



On 9 Feb 2024, at 10:41, Vladimir Minenko via Development 
 wrote:

Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” 
(https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 6.12+”

and "C++20 is required for the development and buiding of Qt itself (Phase II)” 
(https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 6.9-6.11”

With all the respect to the power of C++20 and enthusiasm to use it from Qt 
Project developers, what should we expect from all other users if we would make 
this change in 6.8, considering:

a) just 4 months left to the Feature Freeze for 6.8
b) there is zero communication to users beyond the above issues on Qt But 
Reports and discussions on this mailing list (which is actually for Qt 
developers and not Qt users, BTW)
c) there is no other communication about the done and ongoing works introducing 
C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 
and careful reading of “What’s New” pages

Qt crashed such a change on users with C++11 and with C++17 in the past. Each time 
after this, there were much more negative responses than “thank you”s. I still hope 
we find a way to do this better this time. And just “faster” is not “better"

In the current shape, my vote is “no”.

--
Vladimir

On 3. Feb 2024, at 18:15, Thiago Macieira  wrote:

On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote:
I don't have access to QNX and INTEGRITY toolchain information, so I'd like
to request that they simply match the feature list above, with minimal
workarounds.

What's the current state for those, for supporting Qt 6.8 or 6.9?

We have VxWorks coming in and I'd like it to meet a higher minimum bar than
"legacy". That is, I'd like VxWorks to require a C++20-compliant compiler
before being enabled in our CI, but that's only fair if we have a line-of-
sight to bringing everyone to C++20.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

--
Development mailing list
Development@qt-project.org

Re: [Development] Raising the minimum to C++20

[Philippe]

>So, as much as I’d like for some of the things I’m working on to be
>able to benefit from C++ 20, I’d also say that we should rather slow
>down, and only require C++20 if we have something to show for it.

C++20 makes for a more enjoyable coding experience; this human factor
should not be ruled out of the equation.
With the key to sometimes more readable code and a certain gain in
productivity.

Philippe

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

Re: [Development] Raising the minimum to C++20

[David C. Partridge]

As a Qt user I am 100% with the sentiments expressed below by Volker.   Qt 
should not require users to build with C++20 until or unless it has a 
compelling reason to do so.   Allowing users to use C++20 or C++23 is a 
different question.

 

David Partridge

 

From: Development  On Behalf Of Volker 
Hilsheimer via Development
Sent: 09 February 2024 14:46
To: Vladimir Minenko ; development@qt-project.org
Subject: Re: [Development] Raising the minimum to C++20

 

I haven’t heard any convincing argument for us raising the minimum to C++ 20 in 
the foreseeable future. Not for building Qt, and not for using Qt.

 

At most we get some convenience constructs for ourselves. There’s value in 
that, of course. But unless I miss something huge, then that value is quite 
small. We have a working implementation of e.g. atomics that is sufficient for 
our own needs; we have our own implementation of . We now also have QSpan, 
which we practically don’t use anywhere in Qt so far. And that value is of 
practically no relevance to users of Qt - they can use C++20 in their 
application, together with Qt.

 

The 3 big C++20 features people ask us about are modules, co-routines, and 
concepts. We have no compelling answers here. You can’t build Qt into a set of 
modules; we have no APIs using co-routines; none of our template constraints 
are expressed, or at least documented, as concepts, and there is no draft of a 
concept library for things that might be interesting for Qt users.

 

Do we really want to go out and say that C++20 is now mandatory to build or use 
Qt, while we have no convincing story on any of that? Do we want to ask people 
to make a significant investment if they want to work with the latest Qt 
version, but even then they don’t get any support for any of the big three 
features?

 

So, as much as I’d like for some of the things I’m working on to be able to 
benefit from C++ 20, I’d also say that we should rather slow down, and only 
require C++20 if we have something to show for it. We can perhaps still make 
improvements to better enable C++20 features, such as std::ranges, in 
application code; but that should neither require Qt to be built with C++20, 
nor require applications that don’t use std::ranges to use C++20.

 

 

Volker

 





On 9 Feb 2024, at 10:41, Vladimir Minenko via Development 
 wrote:

 

Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” 
(https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 
6.12+” 

 

and "C++20 is required for the development and buiding of Qt itself (Phase II)” 
(https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 
6.9-6.11”

 

With all the respect to the power of C++20 and enthusiasm to use it from Qt 
Project developers, what should we expect from all other users if we would make 
this change in 6.8, considering:

 

a) just 4 months left to the Feature Freeze for 6.8

b) there is zero communication to users beyond the above issues on Qt But 
Reports and discussions on this mailing list (which is actually for Qt 
developers and not Qt users, BTW)

c) there is no other communication about the done and ongoing works introducing 
C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 
and careful reading of “What’s New” pages

 

Qt crashed such a change on users with C++11 and with C++17 in the past. Each 
time after this, there were much more negative responses than “thank you”s. I 
still hope we find a way to do this better this time. And just “faster” is not 
“better"

 

In the current shape, my vote is “no”. 


--
Vladimir 





On 3. Feb 2024, at 18:15, Thiago Macieira mailto:thiago.macie...@intel.com> > wrote:

 

On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote:



I don't have access to QNX and INTEGRITY toolchain information, so I'd like
to request that they simply match the feature list above, with minimal
workarounds.


What's the current state for those, for supporting Qt 6.8 or 6.9?

We have VxWorks coming in and I'd like it to meet a higher minimum bar than 
"legacy". That is, I'd like VxWorks to require a C++20-compliant compiler 
before being enabled in our CI, but that's only fair if we have a line-of-
sight to bringing everyone to C++20.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
 Cloud Software Architect - Intel DCAI Cloud Engineering
-- 
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

 

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

Re: [Development] Raising the minimum to C++20

[Volker Hilsheimer via Development]

I haven’t heard any convincing argument for us raising the minimum to C++ 20 in 
the foreseeable future. Not for building Qt, and not for using Qt.

At most we get some convenience constructs for ourselves. There’s value in 
that, of course. But unless I miss something huge, then that value is quite 
small. We have a working implementation of e.g. atomics that is sufficient for 
our own needs; we have our own implementation of . We now also have QSpan, 
which we practically don’t use anywhere in Qt so far. And that value is of 
practically no relevance to users of Qt - they can use C++20 in their 
application, together with Qt.

The 3 big C++20 features people ask us about are modules, co-routines, and 
concepts. We have no compelling answers here. You can’t build Qt into a set of 
modules; we have no APIs using co-routines; none of our template constraints 
are expressed, or at least documented, as concepts, and there is no draft of a 
concept library for things that might be interesting for Qt users.

Do we really want to go out and say that C++20 is now mandatory to build or use 
Qt, while we have no convincing story on any of that? Do we want to ask people 
to make a significant investment if they want to work with the latest Qt 
version, but even then they don’t get any support for any of the big three 
features?

So, as much as I’d like for some of the things I’m working on to be able to 
benefit from C++ 20, I’d also say that we should rather slow down, and only 
require C++20 if we have something to show for it. We can perhaps still make 
improvements to better enable C++20 features, such as std::ranges, in 
application code; but that should neither require Qt to be built with C++20, 
nor require applications that don’t use std::ranges to use C++20.


Volker


On 9 Feb 2024, at 10:41, Vladimir Minenko via Development 
 wrote:

Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” 
(https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 
6.12+”

and "C++20 is required for the development and buiding of Qt itself (Phase II)” 
(https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 
6.9-6.11”

With all the respect to the power of C++20 and enthusiasm to use it from Qt 
Project developers, what should we expect from all other users if we would make 
this change in 6.8, considering:

a) just 4 months left to the Feature Freeze for 6.8
b) there is zero communication to users beyond the above issues on Qt But 
Reports and discussions on this mailing list (which is actually for Qt 
developers and not Qt users, BTW)
c) there is no other communication about the done and ongoing works introducing 
C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 
and careful reading of “What’s New” pages

Qt crashed such a change on users with C++11 and with C++17 in the past. Each 
time after this, there were much more negative responses than “thank you”s. I 
still hope we find a way to do this better this time. And just “faster” is not 
“better"

In the current shape, my vote is “no”.

--
Vladimir

On 3. Feb 2024, at 18:15, Thiago Macieira  wrote:

On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote:
I don't have access to QNX and INTEGRITY toolchain information, so I'd like
to request that they simply match the feature list above, with minimal
workarounds.

What's the current state for those, for supporting Qt 6.8 or 6.9?

We have VxWorks coming in and I'd like it to meet a higher minimum bar than
"legacy". That is, I'd like VxWorks to require a C++20-compliant compiler
before being enabled in our CI, but that's only fair if we have a line-of-
sight to bringing everyone to C++20.

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Cloud Software Architect - Intel DCAI Cloud Engineering
--
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

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

Re: [Development] Let's drop MSVC 2019 for dev (6.8)

[Kai Köhne via Development]

> MSVC2019 and MSVC2022 is supposed to be compatible. So in theory at least
> packages made with MSVC2022 is still usable for MSVC2019 as well. It is just a
> question of which compiler we use to generate the binaries with.

That's not the case, at least according to Microsoft 
(https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170):
 
 You can mix binaries built by different versions of the v140, v141, v142, 
and v143 toolsets. However, you must link by using a toolset at least as recent 
as the most recent binary in your app. 

As almost all Qt users link against the Qt libraries, they need to, therefore, 
use at least the Microsoft Compiler version that the CI uses.

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

Re: [Development] Let's drop MSVC 2019 for dev (6.8)

[Allan Sandfeld Jensen]

On Friday, 9 February 2024 10:59:07 CET Vladimir Minenko via Development 
wrote:
> Hi,
> 
> I also think we should first get the 2022 compiler packages available for
> installation in parallel to the 2019 ones. This should be available for
> users for a while so that they have a transition period. Along with this,
> we should announce that the 2019 compiler will be dismissed by a specific
> date.
 
> As we introduce Linux on ARM desktops and later Windows on ARM desktops,
> this can only be done IMHO after work on the release of 6.7 is finished,
> meaning in some of the 6.7.x slots.
 
> Considering removal of MSVC 2019 in "Supported Configurations” in
> https://doc.qt.io/qt-6/windows.html should come after we provide a
> transition solution, IMHO
 
MSVC2019 and MSVC2022 is supposed to be compatible. So in theory at least 
packages made with MSVC2022 is still usable for MSVC2019 as well. It is just a 
question of which compiler we use to generate the binaries with.

Best regards
Allan


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

Re: [Development] Let's drop MSVC 2019 for dev (6.8)

[Jani Heikkinen via Development]

Hi!

I wouldn't once again duplicate these msvc binary packages if that isn't really 
mandatory; we already have so many packages and more is coming all the time so 
something has to be dropped as well. msvc2022 is quite old already so I would 
just replace msvc2019 with msvc2022 from Qt 6.8 ->

br,
Jani

From: Development  On Behalf Of Vladimir 
Minenko via Development
Sent: perjantai 9. helmikuuta 2024 11.59
To: development@qt-project.org
Subject: Re: [Development] Let's drop MSVC 2019 for dev (6.8)

Hi,

I also think we should first get the 2022 compiler packages available for 
installation in parallel to the 2019 ones. This should be available for users 
for a while so that they have a transition period. Along with this, we should 
announce that the 2019 compiler will be dismissed by a specific date.

As we introduce Linux on ARM desktops and later Windows on ARM desktops, this 
can only be done IMHO after work on the release of 6.7 is finished, meaning in 
some of the 6.7.x slots.

Considering removal of MSVC 2019 in "Supported Configurations" in 
https://doc.qt.io/qt-6/windows.html should come after we provide a transition 
solution, IMHO

I fully appreciate the enthusiasm for using new capabilities in the newer 
compiler, but we should not forget the fact there are more users preferring the 
predictability of changes, and none like surprises with these topics.

--
Vladimir



On 6. Feb 2024, at 08:28, Allan Sandfeld Jensen 
mailto:k...@carewolf.com>> wrote:

On Tuesday, 6 February 2024 06:57:34 CET Jani Heikkinen via Development wrote:

How about instead we drop at an LTS+2 release? The next one is actually
6.7.
We can't switch this in 6.7 at this point anymore; we don't have packages
for MSVC2022 at the moment and doing this (adding new packages + removing
ones) change this late of process is too risky
Could you please switch packaging to msvc2022 in dev then, so we don\t have
this discussion and excuse yet again in 6 months?

Br
Allan



--
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] Let's drop MSVC 2019 for dev (6.8)

[Vladimir Minenko via Development]

Hi,

I also think we should first get the 2022 compiler packages available for 
installation in parallel to the 2019 ones. This should be available for users 
for a while so that they have a transition period. Along with this, we should 
announce that the 2019 compiler will be dismissed by a specific date.

As we introduce Linux on ARM desktops and later Windows on ARM desktops, this 
can only be done IMHO after work on the release of 6.7 is finished, meaning in 
some of the 6.7.x slots.

Considering removal of MSVC 2019 in "Supported Configurations” in 
https://doc.qt.io/qt-6/windows.html should come after we provide a transition 
solution, IMHO

I fully appreciate the enthusiasm for using new capabilities in the newer 
compiler, but we should not forget the fact there are more users preferring the 
predictability of changes, and none like surprises with these topics.

--
Vladimir


On 6. Feb 2024, at 08:28, Allan Sandfeld Jensen  wrote:

On Tuesday, 6 February 2024 06:57:34 CET Jani Heikkinen via Development wrote:
How about instead we drop at an LTS+2 release? The next one is actually
6.7.
We can't switch this in 6.7 at this point anymore; we don't have packages
for MSVC2022 at the moment and doing this (adding new packages + removing
ones) change this late of process is too risky

Could you please switch packaging to msvc2022 in dev then, so we don\t have
this discussion and excuse yet again in 6 months?

Br
Allan



--
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] Raising the minimum to C++20

[Vladimir Minenko via Development]

Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” 
(https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 
6.12+”

and "C++20 is required for the development and buiding of Qt itself (Phase II)” 
(https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 
6.9-6.11”

With all the respect to the power of C++20 and enthusiasm to use it from Qt 
Project developers, what should we expect from all other users if we would make 
this change in 6.8, considering:

a) just 4 months left to the Feature Freeze for 6.8
b) there is zero communication to users beyond the above issues on Qt But 
Reports and discussions on this mailing list (which is actually for Qt 
developers and not Qt users, BTW)
c) there is no other communication about the done and ongoing works introducing 
C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 
and careful reading of “What’s New” pages

Qt crashed such a change on users with C++11 and with C++17 in the past. Each 
time after this, there were much more negative responses than “thank you”s. I 
still hope we find a way to do this better this time. And just “faster” is not 
“better"

In the current shape, my vote is “no”.

--
Vladimir

On 3. Feb 2024, at 18:15, Thiago Macieira  wrote:

On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote:
I don't have access to QNX and INTEGRITY toolchain information, so I'd like
to request that they simply match the feature list above, with minimal
workarounds.

What's the current state for those, for supporting Qt 6.8 or 6.9?

We have VxWorks coming in and I'd like it to meet a higher minimum bar than
"legacy". That is, I'd like VxWorks to require a C++20-compliant compiler
before being enabled in our CI, but that's only fair if we have a line-of-
sight to bringing everyone to C++20.

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Cloud Software Architect - Intel DCAI Cloud Engineering
--
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