[Development] Houston, qint128 has a problem

[Marc Mutz via Development]

Hi,

After spending countless hours between Ivan and myself fighting GCC's 
mysteriously-vanishing  support for __int128_t (= qint128), 
it turns out that with -ansi/-std=c++NN, not even the most basic of 
 work: std::is_signed_v is _false_! I repeat: _FALSE_.

The following is /my/ professional opinion, Ivan may chime in himself:

I think we need to mandate that if you want qint128 support, then you 
must compile with gnu++NN, which is actually the default on both GCC and 
Clang. We seem to switch that off (-ansi on).

We cannot fight a broken stdlib. If the compiler says that these things 
don't exist as integral types, then who is Qt to disagree? It slows down 
development, and all those work-arounds slow down compilations, too:

  - std::is_integral_v
  + std::disjunction_v,
  +std::is_same,
  +std::is_same>

Unless someone can present a solution where  and  
work for q(u)int128 under -ansi — even for users — I would undef 
QT_SUPPORTS_INT128 when __STRICT_ANSI__ is in effect, then drop the 
-ansi from Qt builds to make sure the symbols that contain qint128 are 
present in the library. User projects can then use whichever one they want.

We have a similar issue with qfloat16::NativeFloat. On GCC-13, the 
traits only work (tested: ) when compiling in C++23 mode, yet we 
insist on using the types before, eagerly grabbing _some_ definition 
from wherever we can (C20, platform-specifics, ...).

And yes, that means we'll have BC issues from that, too.

References:
- https://bugreports.qt.io/browse/QTBUG-119901
- 
https://codereview.qt-project.org/c/qt/qtbase/+/478199/comment/bcbe8aca_d5d65018/
- https://codereview.qt-project.org/c/qt/qtbase/+/507383

Opinions? Comments?

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Volker Hilsheimer via Development]

Hi Elias,

Thanks for taking the time to share your input to this! See comments inline.

> On 8 Dec 2023, at 15:33, Elias Steurer via Development 
>  wrote:
> 
> Hi Volker,
> Thanks for the update on the Qt Contributors Summit. It's great to hear about 
> the initiatives to make the contribution process smoother, especially for 
> newcomers.
> However, while setting up a Gerrit group for hand-holding new contributors is 
> a step in the right direction, I believe we might be missing a crucial point. 
> The core issue isn't just about guiding new contributors through the existing 
> process; it's about the inherent complexity and user-unfriendliness of the 
> current workflow.


On the positive side, these things are not mutually exclusive: we can improve 
the process and the documentation while providing a better welcome-experience 
and support for new people that want to contribute, but struggle with what we 
have. In fact, I’d claim that hand-holding people through some personal contact 
is always going to be a good idea, even if Qt would be a simple code base that 
anyone could build, write tests for, and make fixes in without having to learn 
anything new.


> From installing a plethora of tools to dealing with the confusing repo 
> cloning process, Perl dependencies and Perl path issues,  the barriers to 
> entry are high.


Yes, setting up a local development environment that can build Qt is not 
trivial, esp if you want to build all submodules, and want to work on Windows 
on the one hand, but on the other hand want to use something other than the 
native compiler and SDK for that platform ;) And if you want to make sure that 
your code compiles and that tests pass with your modifications just on the main 
desktop platforms, then you’ll be busy setting things up for a while.

There is certainly room for improvement, but I think the complexity is a bit in 
the nature of the beast as well (that beast being not just Qt, but C++, several 
development platforms, even more cross-compile targets etc).
Can we make that fundamentally easier? Should that be our goal and what we 
spend our time on? Would it make a huge difference if we didn’t require perl 
(and IIRC we only need it for the init-repository script)? You need cmake, 
ninja, and your compiler and platform-specific SDK (which is mostly trivial on 
Windows and macOS; on Linux it’s a bit of a piece-meal). But none of that 
strikes me as particular esoteric stuff. Well, unless you want to build 
webengine, or check all the SQL-driver boxes.

Anyway, if you can make specific suggestions on how we can improve the build 
system of Qt and reduce dependencies to tools or libraries, then please do so.

> Then, there's the challenge of navigating the Gerrit setup, which is far from 
> straightforward. The documentation is inconsistent and sometimes 
> contradictory, adding to the confusion. And that's before even getting into 
> the complexities of submitting patches and managing code reviews. If you want 
> I can send you my personal notes, that I have written down recently while 
> setting up Qt locally for the first time in years. Most of it is about my 
> frustration why a solved problem, like contributing to an open source 
> project, is so unnecessary complicated.
> In essence, the current workflow is daunting, even with a support group. I 
> suggest we consider moving towards a more streamlined and "sane" workflow. 
> Simplifying the entire contribution process from the ground up will make Qt 
> more accessible to everyone. Once a more intuitive and welcoming workflow is 
> establish, guiding new contributors will be much more effective. After all, 
> the best hand-holding is the one you don't need because the path is clear and 
> easy to follow. 


If step one has to be that we simplify the entire contribution process from the 
ground up, then this will get us exactly nowhere any time soon. This is not 
only because there is a variety of differences in the Qt project contributor 
community about what we should optimize for. Many of us consider gerrit’s code 
review user experience vastly superior to github’s or gitlabs; many of us 
believe that the history of a patch is a critical piece of data that is easily 
lost, or hard to find, in the github/lab workflow. I don’t know if it’s 
possible by now to comment on the commit message in github/lib/ea (it wasn’t 
last time I checked), but not being able to do so would be a total showstopper 
for me personally, and I don’t understand how projects that care about their 
git history can function if reviewers cannot give structured feedback to the 
most important part of any change, esp to new people.

So building consensus of what “simplification” means in practice is going to 
take a while.

But even if by Christmas we all agreed that we should move things to 
github/lab/ea, it will take a significant investment of time and money to 
actually make that move. There exists a significant amount of tooling, 

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Thiago Macieira]

On Friday, 8 December 2023 07:22:30 PST Dominik Holland via Development wrote:
> Although not part of qt5.git the interface framework is part of Qt DCE
> for quite some time already and also used by customers. From a
> qt-project standpoint that module doesn't exist and is not part of
> source/binary compatibility promises, but what's our standpoint for qt
> commercial customers ?

I think that question, as asked, is irrelevant. Why does anyone care what a 
module is called? We can freely move libraries between modules. They are just 
a packaging artefact. At worst, changing them breaks some build scripts. 
Should be a 10-minute job to fix it, assuming everyone isn't simply getting the 
fix from the Yocto Project.

API and library names, on the other hand, are more important. Any code 
imported into the Qt Project needs to b reviewed, though the fact it may come 
with existing users may inform us in how much breakage we/they are willing to 
accept.

-- 
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] Requesting a repository for Qt Interface Framework Reference APIs

[Dominik Holland via Development]

Am 08.12.23 um 11:40 schrieb Volker Hilsheimer via Development:
The request at hand is to move two of the reference APIs that are 
based on the interface framework out into a separate qt-labs 
repository. Those two APIs are, as Dominik pointed out, very 
automotive specific. But just because they are based on the interface 
framework doesn’t mean that we need to use “interface framework” in 
the name.


After trying to wrap my head around what the Qt Interface Framework 
does and how the reference APIs fit into that, and given that they are 
automotive specific, I’d call that new module perhaps 
“qt-labs/qtvehicleservices.git” or even 
“qt-labs/qtvehiclecabinservices.git” (since the modules under 
discussion are all about things in the cabin - airflow, windows, radio 
and other media - and not about engine- or driving-related stuff).


I like “qt-labs/qtvehicleservices.git” for the parts which should be 
moved out to qtlabs.





I do think that we should rename the overly generically named 
"interface framework" module before we make it part of a Qt release. 
It combines a number of different abstractions for building loosely 
coupled systems. Interface definitions and API abstractions are 
perhaps just “implementation details”. The core functionality of the 
interface framework seems to be service definition and discovery, 
enabling the building of modular systems. I don’t know if 
“qtservicediscoveryframework” is much of an improvement though, but 
that we don’t have a good name for that yet doesn’t have to block 
moving out of the vehicle-services-code.


Although not part of qt5.git the interface framework is part of Qt DCE 
for quite some time already and also used by customers. From a 
qt-project standpoint that module doesn't exist and is not part of 
source/binary compatibility promises, but what's our standpoint for qt 
commercial customers ? Giving the module a better name in the 
documentation and the repo is not a big deal, but what about changing 
the all class names and CMake macros, those start with QIf* as well.


Dominik




Volker


On 7 Dec 2023, at 20:01, Maurice Kalinowski via Development 
 wrote:


You are absolutely correct that this module started with a pure 
automotive focus, back then called Qt IVI.
However, we recognized that its functionality can also be utilized in 
a generic way, which was the reason for the rename and generalization 
efforts done in the past. There might still be some leftovers.
There are developers/customers using it in their production 
environment already, also outside of the automotive sector.

BR,
Maurice
*From:*Development *On Behalf 
Of*Tor Arne Vestbø via Development

*Sent:*Thursday, 7 December 2023 18:37
*To:*Tuukka Turunen 
*Cc:*Macieira, Thiago ; 
development@qt-project.org
*Subject:*Re: [Development] Requesting a repository for Qt Interface 
Framework Reference APIs
If it’s an option to rename this module we should take the 
opportunity to do so I think.
The problem of the generic naming came up in the past, but the 
understanding was that it was too late to change.

If that is not the case after all, we should strongly consider it.
The documentation at 
https://doc.qt.io/QtInterfaceFramework/ describes it as:
"The Qt Interface Framework module provides both the tools and the 
core APIs, for you to implement Middleware APIs, Middleware Back 
ends, and Middleware Services. “



So is this the Qt Middleware module?


On the other hand, the module seems to also provide a lot more than 
just core primitives. E.g. this set of classes for in-viechle 
infotainment systems:

https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html

So is this a Qt for Automotive specific module? These APIs seem to 
indicate that as well:
https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html 

If we do want to promote this to a Qt module, should the core 
functionality be split off, and the rest stay Qt for Automotive specific?

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html
Cheers,
Tor Arne


On 7 Dec 2023, at 17:02, Tuukka Turunen via Development
 wrote:
Hi,
Thiago is right, we can change the name as the module technically
is not part of Qt release
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).
That said, we can also decide not to change the name. Like
mentioned by Dominik, it has existing since a while with the
current name (https://doc.qt.io/QtInterfaceFramework/) and
repository
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially
it had a different name, so the current one is already a new
name, which is probably better than the initial at least.
So the question is what should this module be called, if it would
be renamed? And another question, is it feasible to implement the
renaming at this point?
Moving the proposed items out from it to labs modules makes sense
to me. The naming of labs 

Re: [Development] Nominating Semih Yavuz as an approver for the Qt project

[Sami Shalayel via Development]

Hi,

Semih has been doing good work for the QML Language Server and the 
QmlDom, +1 from me.


Disclaimer: He is working in my team and we share the same office.

Best regards,

Sami

On 07.12.23 15:45, Fabian Kosmale via Development wrote:

Hi,

I would like to nominate Semih Yavuz for approver rights to the Qt project.

Semih has been working on the Qt project since September 2022. He has been 
mainly focusing
on the QML tooling story, including work on qmlformat and the QML language 
server. In addition,
he is also taking care of the (non-LSP based ) Qt Creator QML integration.
Finally, he has also been reviewing changes in all parts of QML.

I fully trust his judgement in reviewing and approving changes.

Changes where he is the author: 
https://codereview.qt-project.org/q/owner:semih.yavuz%2540qt.io
Changes where he commented/voted on: 
https://codereview.qt-project.org/q/commentby:semih.yavuz%2540qt.io

Disclosure: Semih is working in my team and we share the same office.

Kind Regards,
Fabian

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

Re: [Development] Buddy group to help new contributors

[Elias Steurer via Development]

Hi Volker,

Thanks for the update on the Qt Contributors Summit. It's great to hear 
about the initiatives to make the contribution process smoother, 
especially for newcomers.


However, while setting up a Gerrit group for hand-holding new 
contributors is a step in the right direction, I believe we might be 
missing a crucial point. The core issue isn't just about guiding new 
contributors through the existing process; it's about the inherent 
complexity and user-unfriendliness of the current workflow.


From installing a plethora of tools to dealing with the confusing repo 
cloning process, Perl dependencies and Perl path issues 
,  
the barriers to entry are high. Then, there's the challenge of 
navigating the Gerrit setup, which is far from straightforward. The 
documentation is inconsistent and sometimes contradictory, adding to the 
confusion. And that's before even getting into the complexities of 
submitting patches and managing code reviews. If you want I can send you 
my personal notes, that I have written down recently while setting up Qt 
locally for the first time in years. Most of it is about my frustration 
why a solved problem, like contributing to an open source project, is so 
unnecessary complicated.


In essence, the current workflow is daunting, even with a support group. 
I suggest we consider moving towards a more streamlined and "sane" 
workflow. Simplifying the entire contribution process from the ground up 
will make Qt more accessible to everyone. Once a more intuitive and 
welcoming workflow is establish, guiding new contributors will be much 
more effective. *After all, the best hand-holding is the one you don't 
need because the path is clear and easy to follow. *


It might be worth considering a migration to GitLab, which has been a 
successful move for other open-source projects like KDE and Arch. Given 
that Qt already uses an internal GitLab instance, this could be a good 
platform for future collaboration. Alternatively, adopting Gitea, as 
used by the Blender Foundation, could also be a viable option if Gitlab 
licensing is a no-go.


I strongly believe the focus should be on overhauling the workflow 
first. Everything else, including smoother onboarding of new 
contributors, will naturally follow.


There was also an discussion about this recently on Reddit. 



Best,

Eli

On 12/5/2023 9:57 AM, Volker Hilsheimer via Development wrote:

At the Qt Contributors Summit in Berlin last week, we discussed various ideas 
around improving the contribution experience, esp for new people.

One action that came out of that was setting up a gerrit group of people that are 
able and willing to hand-hold new contributors through the process. This includes 
setting up your local development environment, gerrit configuration and workflow, 
and finding out what to work on from e.g. Jira. The basic idea is that we establish 
a (gerrit, probably) group with buddies; we can already identify “first gerrit 
reviews" for a new user, and then we can proactively reach out with a welcome 
message, and add the group of buddies as a reviewer.

A few people raised their hand at the event, but I don’t think anyone took down 
the names, and I was busy juggling microphones. And either way, this is of 
course open to anyone! So please reply to this, either to all or privately to 
me, if you want to be part of that group.

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

[Development] HEADS-UP: Qt 6.7 Feature Freeze

[Jani Heikkinen via Development]

Hi!



Qt 6.7 Feature Freeze will be in effect today. If your changes are ready and 
approved by the end of today, you can still continue staging those in 'dev' 
over the weekend. The plan is to branch from "6.7" to "dev" on Monday morning 
next week.



If your feature isn't ready by the end of today, you'll either need to postpone 
it to Qt 6.8 or request an exception.



br,

Jani Heikkinen

Release Manager

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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Tor Arne Vestbø via Development]

On 8 Dec 2023, at 11:40, Volker Hilsheimer  wrote:

The request at hand is to move two of the reference APIs that are based on the 
interface framework out into a separate qt-labs repository. Those two APIs are, 
as Dominik pointed out, very automotive specific. But just because they are 
based on the interface framework doesn’t mean that we need to use “interface 
framework” in the name.

After trying to wrap my head around what the Qt Interface Framework does and 
how the reference APIs fit into that, and given that they are automotive 
specific, I’d call that new module perhaps “qt-labs/qtvehicleservices.git” or 
even “qt-labs/qtvehiclecabinservices.git” (since the modules under discussion 
are all about things in the cabin - airflow, windows, radio and other media - 
and not about engine- or driving-related stuff).

I do think that we should rename the overly generically named "interface 
framework" module before we make it part of a Qt release. It combines a number 
of different abstractions for building loosely coupled systems. Interface 
definitions and API abstractions are perhaps just “implementation details”. The 
core functionality of the interface framework seems to be service definition 
and discovery, enabling the building of modular systems. I don’t know if 
“qtservicediscoveryframework” is much of an improvement though, but that we 
don’t have a good name for that yet doesn’t have to block moving out of the 
vehicle-services-code.

Agreed. And moving those services out to an automative specific labs repo might 
make it easier to find a good name for the leftovers (service discovery seems 
like the general theme indeed).

Cheers,
Tor Arne




Volker


On 7 Dec 2023, at 20:01, Maurice Kalinowski via Development 
 wrote:

You are absolutely correct that this module started with a pure automotive 
focus, back then called Qt IVI.
However, we recognized that its functionality can also be utilized in a generic 
way, which was the reason for the rename and generalization efforts done in the 
past. There might still be some leftovers.

There are developers/customers using it in their production environment 
already, also outside of the automotive sector.

BR,
Maurice


From: Development  On Behalf Of Tor Arne 
Vestbø via Development
Sent: Thursday, 7 December 2023 18:37
To: Tuukka Turunen 
Cc: Macieira, Thiago ; development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs

If it’s an option to rename this module we should take the opportunity to do so 
I think.

The problem of the generic naming came up in the past, but the understanding 
was that it was too late to change.

If that is not the case after all, we should strongly consider it.

The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:

"The Qt Interface Framework module provides both the tools and the core APIs, 
for you to implement Middleware APIs, Middleware Back ends, and Middleware 
Services. “


So is this the Qt Middleware module?


On the other hand, the module seems to also provide a lot more than just core 
primitives. E.g. this set of classes for in-viechle infotainment systems:

https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html


So is this a Qt for Automotive specific module? These APIs seem to indicate 
that as well:

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html

If we do want to promote this to a Qt module, should the core functionality be 
split off, and the rest stay Qt for Automotive specific?

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html

Cheers,
Tor Arne


On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
mailto:development@qt-project.org>> wrote:

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a 

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Volker Hilsheimer via Development]

The request at hand is to move two of the reference APIs that are based on the 
interface framework out into a separate qt-labs repository. Those two APIs are, 
as Dominik pointed out, very automotive specific. But just because they are 
based on the interface framework doesn’t mean that we need to use “interface 
framework” in the name.

After trying to wrap my head around what the Qt Interface Framework does and 
how the reference APIs fit into that, and given that they are automotive 
specific, I’d call that new module perhaps “qt-labs/qtvehicleservices.git” or 
even “qt-labs/qtvehiclecabinservices.git” (since the modules under discussion 
are all about things in the cabin - airflow, windows, radio and other media - 
and not about engine- or driving-related stuff).

I do think that we should rename the overly generically named "interface 
framework" module before we make it part of a Qt release. It combines a number 
of different abstractions for building loosely coupled systems. Interface 
definitions and API abstractions are perhaps just “implementation details”. The 
core functionality of the interface framework seems to be service definition 
and discovery, enabling the building of modular systems. I don’t know if 
“qtservicediscoveryframework” is much of an improvement though, but that we 
don’t have a good name for that yet doesn’t have to block moving out of the 
vehicle-services-code.


Volker


On 7 Dec 2023, at 20:01, Maurice Kalinowski via Development 
 wrote:

You are absolutely correct that this module started with a pure automotive 
focus, back then called Qt IVI.
However, we recognized that its functionality can also be utilized in a generic 
way, which was the reason for the rename and generalization efforts done in the 
past. There might still be some leftovers.

There are developers/customers using it in their production environment 
already, also outside of the automotive sector.

BR,
Maurice


From: Development  On Behalf Of Tor Arne 
Vestbø via Development
Sent: Thursday, 7 December 2023 18:37
To: Tuukka Turunen 
Cc: Macieira, Thiago ; development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs

If it’s an option to rename this module we should take the opportunity to do so 
I think.

The problem of the generic naming came up in the past, but the understanding 
was that it was too late to change.

If that is not the case after all, we should strongly consider it.

The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:

"The Qt Interface Framework module provides both the tools and the core APIs, 
for you to implement Middleware APIs, Middleware Back ends, and Middleware 
Services. “


So is this the Qt Middleware module?


On the other hand, the module seems to also provide a lot more than just core 
primitives. E.g. this set of classes for in-viechle infotainment systems:

https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html


So is this a Qt for Automotive specific module? These APIs seem to indicate 
that as well:

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html

If we do want to promote this to a Qt module, should the core functionality be 
split off, and the rest stay Qt for Automotive specific?

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html

Cheers,
Tor Arne


On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
mailto:development@qt-project.org>> wrote:

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
>