From jani.heikkinen at qt.io  Mon Mar  2 07:16:12 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Mon, 2 Mar 2026 06:16:12 +0000
Subject: [Development] HEADS-UP: Branching from '6.10' to '6.10.3' is done
Message-ID: <AMBPR02MB117612A51C12C33C68FCE698A9D7EA@AMBPR02MB11761.eurprd02.prod.outlook.com>

Hi!

We have branched ?6.10.3? from ?6.10? now. So from now on all changes targeted to Qt 6.10.3 release must have ?Pick-to: 6.10.3?.

As usual, staging in ?6.10.3? is restricted to release team only and we will monitor incoming changes automatically. The target is to release Qt 6.10.3 ~mid March 2026. And the plan is that Qt 6.10.3 will be the last release from Qt 6.10 series.

br,
Jani Heikkinen
Release Manager

From Christian.Stromme at qt.io  Mon Mar  2 09:15:11 2026
From: Christian.Stromme at qt.io (=?Windows-1252?Q?Christian_Str=F8mme?=)
Date: Mon, 2 Mar 2026 08:15:11 +0000
Subject: [Development] Stepping down as maintainer for QtWebView
Message-ID: <DB4PR02MB8533373459DCCC21D8F62DB3F77EA@DB4PR02MB8533.eurprd02.prod.outlook.com>

I?d like to pass on the maintainer role of QtWebView to someone who can give it more attention than I?ve been able to. I?ve had minimal involvement for a while, and lately the QtWebEngine team and Allan have taken over all maintenance and new development. I therefore would like to nominate Allan Jensen to take over the official maintainer role.


--
Christian


Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260302/51bfed01/attachment.htm>

From Shawn.Rutledge at qt.io  Mon Mar  2 10:16:27 2026
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Mon, 2 Mar 2026 09:16:27 +0000
Subject: [Development] Stepping down as maintainer for QtWebView
In-Reply-To: <DB4PR02MB8533373459DCCC21D8F62DB3F77EA@DB4PR02MB8533.eurprd02.prod.outlook.com>
References: <DB4PR02MB8533373459DCCC21D8F62DB3F77EA@DB4PR02MB8533.eurprd02.prod.outlook.com>
Message-ID: <8FED864E-8E74-4276-BF39-7F47595A98A1@qt.io>

+1 for Allan

On Mar 2, 2026, at 09:15, Christian Str?mme via Development <development at qt-project.org> wrote:

I?d like to pass on the maintainer role of QtWebView to someone who can give it more attention than I?ve been able to. I?ve had minimal involvement for a while, and lately the QtWebEngine team and Allan have taken over all maintenance and new development. I therefore would like to nominate Allan Jensen to take over the official maintainer role.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260302/cf80f80f/attachment-0001.htm>

From jani.heikkinen at qt.io  Tue Mar  3 09:25:35 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 3 Mar 2026 08:25:35 +0000
Subject: [Development] Qt 6.11.0 RC released
Message-ID: <AMBPR02MB11761B1C9EE27E782F69841649D7FA@AMBPR02MB11761.eurprd02.prod.outlook.com>

Hi all!

We have released the Qt 6.11.0 RC.  As earlier you can get it via online installer. Src packages are also available in the Qt Account and download.qt.io. Delta to the beta3 attached. 

Please test the RC now to see if it is OK for the final Qt 6.11.0 release and report all findings in Jira. Please also make sure all blockers for Qt 6.11.0 release are visible in Qt 6.11.0 blocker list (https://qt-project.atlassian.net/issues/?filter=19114).

The target is to release Qt 6.11.0 17th of March 2026.

br,
Jani Heikkinen
Release Manager

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: delta_qt6.11.0-beta3_qt6.11.0-rc.txt
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260303/a97b3130/attachment-0001.txt>

From jani.heikkinen at qt.io  Tue Mar  3 12:25:03 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 3 Mar 2026 11:25:03 +0000
Subject: [Development] HEADS-UP: Qt 6.11.0 release note review
Message-ID: <AMBPR02MB11761F2D3B61E2988A14593499D7FA@AMBPR02MB11761.eurprd02.prod.outlook.com>

Hi!

Here is Qt 6.11.0 release note draft: https://codereview.qt-project.org/c/qt/qtreleasenotes/+/716667

Please review it (&do needed corrections) asap; we need to finalize it before official release, which is planned to happen 17th March 2026.

 

br,

Jani

From ariel at edis.mx  Tue Mar  3 18:49:32 2026
From: ariel at edis.mx (Ariel Molina)
Date: Tue, 3 Mar 2026 11:49:32 -0600
Subject: [Development] Interest in a MCP QML server like Chrome dev tools?
 Think Claude + QML
Message-ID: <CA+AEP38_TG1yn1T+BN7q1GCzuH0EZAkuz8dtO7S7-3XWj3QoYw@mail.gmail.com>

Hi,

I've started developing an MCP QML and QML tooling for QtQuick. Currently,
it supports several similarities to Chrome dev tools + Chrome MCP. I've
tested it on Claude and it works very well.

This tool offers the QSG tree and uses a WebSocket protocol to receive
requests for AI tools like Claude. It works wonders for live editing, and I
suspect it also works for automated testing on GUI.

At my company we are pushing to opensource it, as creating autotesting
tools or AI MCPs and whatnot isn't part of our business model. If it sparks
enough interest it would be much better to offer it to the community.

*Expected Usage Flow*
> 1. Compile the IntrospectServer plugin (Phase 1):
>    make && make install
>>
>> 2. Add to the app's QML:
>>    import mx.edis.debug 1.0
>>    Window { EdisMcpServer { port: 7003 } ... }
>> 3. Compile the MCP server (Phase 2):
>>    cd tools/mcp-qml && npm install && npm run build
>> 4. Configure .mcp.json in the project
>> 5. Start the Qt Quick app
>> 6. Open Claude Code in the project
>> Claude Code automatically:
>>   - Launches the MCP server as a subprocess
>>   - Detects the tools: qml_snapshot, qml_screenshot, etc.
>>   - Can use them when the user asks to design/modify QML
>> Example session:
>>   User: "Move the title 50px to the right"
>>   Claude:  qml_snapshot() -> sees the tree, finds Text id "0.0.0"
>>   Claude:  qml_get_property("0.0.0", "x") -> 100
>>   Claude:  qml_set_property("0.0.0", "x", 150) -> ok
>>   Claude:  qml_screenshot() -> verifies visually
>>   Claude:  "Done, moved the text from x:100 to x:150"
>
>
Also, I tested it by offering a crude PNG to Claude Code and magically
having it create a quick UI prototype. *Turn hand sketches into UI in
seconds! Perfect them in minutes!*

Ariel

-- 
Ariel Molina R.
+52 2226 758874

[image: EDIS] <http://edis.mx>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260303/35bf507b/attachment.htm>

From jani.heikkinen at qt.io  Wed Mar  4 07:15:56 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 4 Mar 2026 06:15:56 +0000
Subject: [Development] Meeting minutes from Qt Release Team meeting
 03.03.2026
Message-ID: <AMBPR02MB11761C5279DB8947625D02C0F9D7FA@AMBPR02MB11761.eurprd02.prod.outlook.com>

Qt 6.10 status
- Qt 6.10.3 preparations are ongoing
   * Branching from '6.10' to '6.10.3' is done
   * The target is to freeze the release content by the end of this week
   * The target is to release Qt 6.10.3 Thu 12th March

Qt 6.11 status
- Qt 6.11 RC is released and testing is ongoing
- The target is to release Qt 6.11.0 Tue 17th March 2026
   * Release blocker list here: https://qt-project.atlassian.net/issues/?filter=19114

Next meeting Tue 10th March 2026 16:00 CET

br,
Jani

irc log below:
[17:00:08] <jaheikki3> blasche: akseli: carewolf: frkleint: lars_: mapaaso: The-Compiler: thiago: vohi[M]: ping
[17:00:13] <carewolf> pong
[17:01:33] <jaheikki3> Time to start qt release team meeting
[17:01:38] <jaheikki3> on agenda today:
[17:01:42] <jaheikki3> Qt 6.10 status
[17:01:45] <jaheikki3> Qt 6.11 status
[17:01:54] <jaheikki3> Any additional item to the agenda?
[17:02:17] <vohi[M]> jaheikki3: pong :)
[17:03:05] <jaheikki3> Let's start from 6.10 status
[17:03:14] <jaheikki3> Qt 6.10.3 preparation ongoing
[17:03:21] <jaheikki3> Branching from '6.10' to '6.10.3' done
[17:03:35] <jaheikki3> The target is to freeze release content by the end of this week
[17:04:30] <jaheikki3> then create release packages, test those and release Qt 6.10.3 by the end of next week. Current release target is Thu 12th March
[17:04:53] <jaheikki3> that's all about 6.10 status at this time. Any comments or questions?
[17:06:47] <jaheikki3> Then Qt 6.11 status
[17:06:58] <jaheikki3> Qt 6.11 RC is released and testing ongoing
[17:07:36] <jaheikki3> The target is to freeze final release content latest Wed 11th March
[17:07:48] <thiago> jaheikki3: pong (sorry for the delay)
[17:07:48] <jaheikki3> And the target is to release Qt 6.11.0 Tue 17th March 2026
[17:08:13] <jaheikki3> Release blocker list here: https://qt-project.atlassian.net/issues/?filter=19114
[17:08:40] <jaheikki3> Blocker list is empty at the moment but I bet something will be found during the testing
[17:09:01] <jaheikki3> That's all about Qt 6.11 status at this time. Any comments or questions?
[17:11:39] <jaheikki3> It was all at this time so let's end this meeting now & have next one Tue 10th March at this same time
[17:11:55] <jaheikki3> Thanks for your participation, bye!
[17:12:01] <vohi[M]> see you next week, bye!
[17:13:44] <thiago> bye

From alexander.blasche at qt.io  Fri Mar  6 08:17:33 2026
From: alexander.blasche at qt.io (Alex Blasche)
Date: Fri, 6 Mar 2026 07:17:33 +0000
Subject: [Development] Nominating Pavel Dubsky as an approver
In-Reply-To: <PA6PR02MB105910F05E2BB979AEB16ED7B8E8DA@PA6PR02MB10591.eurprd02.prod.outlook.com>
References: <PA6PR02MB105910F05E2BB979AEB16ED7B8E8DA@PA6PR02MB10591.eurprd02.prod.outlook.com>
Message-ID: <DB8PR02MB5897389817AAA08F30205A61E77AA@DB8PR02MB5897.eurprd02.prod.outlook.com>

Hi,

congratulations to Pavel. Approver rights have been granted.

Thank you Artem for pointing out my missing action here.


--

Alex



Confidential
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Artem Dyomin via Development <development at qt-project.org>
Sent: Friday, 16 January 2026 15:31
To: List for announcements regarding Qt releases and development via Announce via Development <development at qt-project.org>
Subject: [Development] Nominating Pavel Dubsky as an approver

Hey,

I want to nominate Pavel D as an approver for the Qt project.

Pavel has worked at The Qt Company for almost three years. He used to focus on the Qt Multimedia domain, specifically on HDR, the multimedia rendering pipeline, FFmpeg provisioning, and related areas.
He is now mostly working on the Windows platform layer, specifically ActiveX, window transparency, and window embedding, and is doing extensive research in this area.
I believe that granting Pavel approval rights would definitely reflect his expertise and contributions.

Pavel?s changes:
https://codereview.qt-project.org/q/owner:pavel.dubsky at qt.io

Reviews:
https://codereview.qt-project.org/q/commentby:pavel.dubsky at qt.io+-owner:pavel.dubsky at qt.io

Investigations:
https://git.qt.io/pavel.dubsky

Regards
Artem


Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260306/761d22ab/attachment.htm>

From announce at qt-project.org  Fri Mar  6 12:57:34 2026
From: announce at qt-project.org (List for announcements regarding Qt releases and development via Announce)
Date: Fri, 6 Mar 2026 11:57:34 +0000
Subject: [Development] [Announce] Qt 6.5.12 LTS Commercial released
Message-ID: <mailman.5326.1772798271.837.announce@qt-project.org>

Hi all,

we have released Qt 6.5.12 LTS Commercial today. Please see the blog post: https://www.qt.io/blog/commercial-lts-qt-6.5.12-released

You?ll find the list of fixes and the overview of all important changes in Qt 6.5.12 in the release note.
It is available via Qt Customer Portal (https://login.qt.io/login): in Downloads, select Product: Qt and Version: 6.5.12.

Also, the Qt for Python content is available via Qt Installer and Qt Customer Portal.

Please note that Standard support for Qt 6.5 will end after April 3, 2026. See the blog post https://www.qt.io/blog/qt-6.5-reaches-end-of-support<https://www.qt.io/blog/qt-6.5-reaches-end-of-support?hsLang=en> for more information about options for legacy Qt 6.5 and updating to the latest Qt 6 version.

Big thanks to everyone involved in Qt 6.5 development!

Best regards,
Tarja Sundqvist
Release Manager



Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260306/588e5a40/attachment.htm>
-------------- next part --------------
_______________________________________________
Announce mailing list
Announce at qt-project.org
https://lists.qt-project.org/listinfo/announce

From Marcus.Tillmanns at qt.io  Mon Mar  9 08:09:48 2026
From: Marcus.Tillmanns at qt.io (Marcus Tillmanns)
Date: Mon, 9 Mar 2026 07:09:48 +0000
Subject: [Development] Interest in a MCP QML server like Chrome dev
 tools? Think Claude + QML
In-Reply-To: <CA+AEP38_TG1yn1T+BN7q1GCzuH0EZAkuz8dtO7S7-3XWj3QoYw@mail.gmail.com>
References: <CA+AEP38_TG1yn1T+BN7q1GCzuH0EZAkuz8dtO7S7-3XWj3QoYw@mail.gmail.com>
Message-ID: <0E22D195-8B00-41BA-BA92-1583670A0714@qt.io>

Hi Ariel,

That sounds interesting indeed. I?d love to try it out.

Cheers,
Marcus

On 3. Mar 2026, at 18:49, Ariel Molina <ariel at edis.mx> wrote:

Hi,

I've started developing an MCP QML and QML tooling for QtQuick. Currently, it supports several similarities to Chrome dev tools + Chrome MCP. I've tested it on Claude and it works very well.

This tool offers the QSG tree and uses a WebSocket protocol to receive requests for AI tools like Claude. It works wonders for live editing, and I suspect it also works for automated testing on GUI.

At my company we are pushing to opensource it, as creating autotesting tools or AI MCPs and whatnot isn't part of our business model. If it sparks enough interest it would be much better to offer it to the community.

Expected Usage Flow
1. Compile the IntrospectServer plugin (Phase 1):
   make && make install
2. Add to the app's QML:
   import mx.edis.debug 1.0
   Window { EdisMcpServer { port: 7003 } ... }
3. Compile the MCP server (Phase 2):
   cd tools/mcp-qml && npm install && npm run build
4. Configure .mcp.json in the project
5. Start the Qt Quick app
6. Open Claude Code in the project
Claude Code automatically:
  - Launches the MCP server as a subprocess
  - Detects the tools: qml_snapshot, qml_screenshot, etc.
  - Can use them when the user asks to design/modify QML
Example session:
  User: "Move the title 50px to the right"
  Claude:  qml_snapshot() -> sees the tree, finds Text id "0.0.0"
  Claude:  qml_get_property("0.0.0", "x") -> 100
  Claude:  qml_set_property("0.0.0", "x", 150) -> ok
  Claude:  qml_screenshot() -> verifies visually
  Claude:  "Done, moved the text from x:100 to x:150"

Also, I tested it by offering a crude PNG to Claude Code and magically having it create a quick UI prototype. Turn hand sketches into UI in seconds! Perfect them in minutes!

Ariel

--
Ariel Molina R.
+52 2226 758874

[EDIS]<http://edis.mx/>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260309/ca656c9e/attachment.htm>

From volker.hilsheimer at qt.io  Mon Mar  9 15:51:30 2026
From: volker.hilsheimer at qt.io (Volker Hilsheimer)
Date: Mon, 9 Mar 2026 14:51:30 +0000
Subject: [Development] Stepping down as maintainer of QtHttpServer
In-Reply-To: <CAEsNbQfgRMuKv9BN4Cq0vMEdhowcXNzfGw6HjvPEVLZ4HPeQeA@mail.gmail.com>
References: <CAEsNbQfgRMuKv9BN4Cq0vMEdhowcXNzfGw6HjvPEVLZ4HPeQeA@mail.gmail.com>
Message-ID: <E23DFDA2-C1E7-460A-B967-BE02AD037AA1@qt.io>

> On 16 Feb 2026, at 13:38, Mikhail Svetkin <mikhail.svetkin at gmail.com> wrote:
> 
> Hello everyone,
> I would like to let you know that I am stepping down as maintainer of the QtHttpServer.
> Over the past years, I haven?t been able to contribute to the module as actively as it deserves. Given this limited involvement, I believe it is the right time to formally hand over the responsibility to someone who can dedicate the necessary time and attention to it.
> I would like to nominate ?ystein Heskestad as the new maintainer. He is familiar with the module and its current state, and I am confident he will take great care of its future development.
> Best regards,
> Mikhail

Thanks Mikhail for taking the initiative on this module together with Jesus many moons ago. Looks like we got something even without depending on co-routines ;)

With several supporters and no objections during the last 15 workdays I?ve updated our list of Maintainers [1]. Thank you ?ystein for stepping up!

[1] https://wiki.qt.io/Maintainers


Cheers,
Volker


From jani.heikkinen at qt.io  Wed Mar 11 07:21:54 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 11 Mar 2026 06:21:54 +0000
Subject: [Development] Meeting minutes from Qt Release Team meeting
 10.03.2026
Message-ID: <AMBPR02MB117617AB0567DEBD991521DB09D46A@AMBPR02MB11761.eurprd02.prod.outlook.com>

Qt 6.11 status
- Qt 6.11.0 release blocker list is empty and Qt 6.11.0 release content is frozen
- We will release Qt 6.11.0 Tue 17th March 2026 as planned

?Qt 6.10 status
- Qt 6.10.3 release content is frozen and testing is started
- We will release Qt 6.10.3 when testing is done and we are ready for the release
   * Most probably we can't release Qt 6.10.3 Thu 12th March as planned. Qt 6.10.3 release might be delayed after the Qt 6.11.0 release

Next meeting Tue 17th March 2026 16:00 CET

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:09] <jaheikki3> ablasche: akseli: carewolf: frkleint: lars_: mapaaso: The-Compiler: thiago: vohi[M]: ping
[17:00:20] <vohi[M]> jaheikki3: pong
[17:00:41] <thiago> jaheikki3: pong
[17:01:24] <jaheikki3> Time to start qt release team meeting
[17:01:29] <jaheikki3> on agenda today:
[17:01:34] <jaheikki3> Qt 6.11 status
[17:01:37] <jaheikki3> Qt 6.10 status
[17:01:49] <jaheikki3> Any additional item to the agenda?
[17:03:13] <jaheikki3> Let's start from Qt 6.11.0 status
[17:03:47] <jaheikki3> Qt 6.11.0 release blocker list is empty and Qt 6.11.0 release content is frozen
[17:03:55] <thiago> \o/
[17:04:14] <jaheikki3> Final dependency update round is in its final steps
[17:04:52] <jaheikki3> Package testing will start tomorrow and we will release Qt 6.10.3 Thu 12th March as planned
[17:05:10] <jaheikki3> That's all about 6.11 status at this time. Any comments or questions?
[17:06:02] <vohi[M]> the 6.10.3 release date in the 6.11 status is a bit confusing ;) 6.11.0 is still ETA March 17th, right?
[17:06:32] <jaheikki3> vohi[M]: sorry, I don't know what I wrote :D 
[17:06:43] <jaheikki3> Maybe a bit tired
[17:07:17] <jaheikki3> But you are right, we will release Qt 6.11.0 Tue 17th March as planned
[17:08:14] <jaheikki3> Then Qt 6.10 status
[17:09:21] <jaheikki3> Qt 6.10.3 release content is frozen and package creation ongoing. Some packages already ready and testing also started
[17:10:18] <jaheikki3> But most probably we can't release Qt 6.10.3 Thu 12th March as planned, we don't have enough time to test packages
[17:11:32] <jaheikki3> Let's see if we can release 6.10.3 before 6.11.0 or not. If not, we will release Qt 6.10.3 later next week, after Qt 6.11.0 release
[17:12:10] <jaheikki3> That's all about 6.10 status at this time. Any comments or questions?
[17:14:32] <jaheikki3> Let's then end this meeting now & have new one Tue 17th March at this same time
[17:14:43] <jaheikki3> thanks for your participation, bye!
[17:14:48] <frkleint> bye
[17:15:27] <vohi[M]> bye!

From jani.heikkinen at qt.io  Wed Mar 11 09:34:35 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 11 Mar 2026 08:34:35 +0000
Subject: [Development] HEADS-UP: Qt 6.10.3 release note review
Message-ID: <AMBPR02MB117612DC66AB568E9E4D97EED9D47A@AMBPR02MB11761.eurprd02.prod.outlook.com>

Hi!

Qt 6.10.3 release note draft here: https://codereview.qt-project.org/c/qt/qtreleasenotes/+/720341

Please review it (&do needed corrections) asap; we need to finalize it before official release, which will be released soon.

br,
Jani
?

From alexander.blasche at qt.io  Wed Mar 11 12:43:33 2026
From: alexander.blasche at qt.io (Alex Blasche)
Date: Wed, 11 Mar 2026 11:43:33 +0000
Subject: [Development] Nominating Thomas Senyk for approver rights
In-Reply-To: <28ba19d0-a332-4f97-91dc-a3dccbdfd25c@qt.io>
References: <28ba19d0-a332-4f97-91dc-a3dccbdfd25c@qt.io>
Message-ID: <DB8PR02MB58974F5D1A8665353FFF04C4E747A@DB8PR02MB5897.eurprd02.prod.outlook.com>

Congratulations to Thomas. Approver rights have been granted.


--

Alex



Confidential
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Robert Griebl via Development <development at qt-project.org>
Sent: Wednesday, 18 February 2026 16:39
To: development at qt-project.org <development at qt-project.org>
Subject: [Development] Nominating Thomas Senyk for approver rights

Hi,

I'd like to nominate Thomas Senyk as approver for the Qt project.

He is - like everyone in PS - not working full-time on Qt, but he's been
contributing to all layers of the graphics stack through the years. He
also is the author of the Wayland compositor side of the application
manager and currently starting to work more on that project again.

https://codereview.qt-project.org/q/owner:senyk

Disclaimer: We work in the same team.

cu
Robert

--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260311/01d0dc9d/attachment.htm>

From announce at qt-project.org  Thu Mar 12 11:00:00 2026
From: announce at qt-project.org (List for announcements regarding Qt releases and development via Announce)
Date: Thu, 12 Mar 2026 10:00:00 +0000
Subject: [Development] [Announce] Security advisory: Recently reported
 dr_wav issue impacts Qt
Message-ID: <mailman.5658.1773309636.837.announce@qt-project.org>

Hi,
A recently reported issue regarding the loading of specifically crafted wave files in dr_wav has been confirmed as impacting the Qt Multimedia module.
Affected versions: From 6.10.0 through to 6.10.2
Impact: This is a reported issue for the 3rd party component ? dr_wav ? which is used in Qt Multimedia and will be fixed in version 0.14.6 of dr_wav. This impacts Qt Multimedia when using these files as it can cause a crash in Qt.
Mitigation: Ensure that all wave files are only from trusted sources.
Solution: Apply the following patches or update to Qt 6.10.3 or 6.11.0
Patches:
dev: https://codereview.qt-project.org/c/qt/qtmultimedia/+/718730 and https://codereview.qt-project.org/c/qt/qtmultimedia/+/719013
Qt 6.10: https://download.qt.io/official_releases/qt/6.10/dr_wav-qtmultimedia-6.10.patch or https://codereview.qt-project.org/c/qt/qtmultimedia/+/718944 and https://codereview.qt-project.org/c/qt/qtmultimedia/+/719206



Kind regards,
Andy
--
Andy Shaw,
The Qt Company

Confidential

Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260312/df9a93b5/attachment.htm>
-------------- next part --------------
_______________________________________________
Announce mailing list
Announce at qt-project.org
https://lists.qt-project.org/listinfo/announce

From announce at qt-project.org  Thu Mar 12 12:53:07 2026
From: announce at qt-project.org (List for announcements regarding Qt releases and development via Announce)
Date: Thu, 12 Mar 2026 11:53:07 +0000
Subject: [Development] [Announce] Qt Creator 19 released
Message-ID: <mailman.5665.1773316401.837.announce@qt-project.org>

We are happy to announce the release of Qt Creator 19!

https://www.qt.io/blog/qt-creator-19-released

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
eike.ziller at qt.io
https://qt.io

Gesch?ftsf?hrer: Mika P?lsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


_______________________________________________
Announce mailing list
Announce at qt-project.org
https://lists.qt-project.org/listinfo/announce

From giuseppe.dangelo at kdab.com  Thu Mar 12 20:38:00 2026
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Thu, 12 Mar 2026 20:38:00 +0100
Subject: [Development] PSA: Lack of Coverity Scan builds
In-Reply-To: <14092416-21A1-4204-A0B5-A2A6E114D44C@qt.io>
References: <2be8c729-8ab2-46d6-85ad-283037cb5469@kdab.com>
 <5179681.OV4Wx5bFTl@tjmaciei-mobl5>
 <437ba582-9e84-4195-8e56-f6bbc443218e@kdab.com>
 <14092416-21A1-4204-A0B5-A2A6E114D44C@qt.io>
Message-ID: <9c6ad4b4-c71a-44bb-843d-4a763f32b2a6@kdab.com>

Hi,

Il 04/02/25 14:16, Volker Hilsheimer ha scritto:
>> Well, the tool itself is built just fine; it's binary identical to one built without Coverity. It's more likely that Coverity is doing something like tracing it during the build process and something goes wrong there, so host tools aren't going to make a difference I'm afraid :(
>>
> Thanks for looking after this Peppe, looks like things are working again? At least I got a few reports from Coverity Scan in the last days.

Volker managed to nerd-snipe me yesterday, and I had a second look at 
why qsb would still crash when running under Coverity.

I still don't know the _why_, but at least I have a workaround. Now 
QtQuick, QtMultimedia, QtLottie, and many more things that depended on 
qsb are now being built, so expect a massive surge of "newly found 
issues"...

Thanks,


? The nitty gritty details after investigating, Coverity seems to 
overwrite execve(2) and inject itself via LD_PRELOAD into all the 
processes spawned during a build. How come this works for moc, uic, etc. 
but not for qsb? I have no idea. I've even replaced qsb with a dummy 
binary that just touches the outputs -- still crashes. The "solution" 
was to rename qsb, and add in its place a little C executable, 
statically linked, that cleans up LD_PRELOAD and issues a 
syscall(SYS_execve) calling the real binary. I have NO idea why this works.


-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260312/45b56274/attachment.bin>

From Kai.Koehne at qt.io  Mon Mar 16 12:50:03 2026
From: Kai.Koehne at qt.io (=?Windows-1252?Q?Kai_K=F6hne?=)
Date: Mon, 16 Mar 2026 11:50:03 +0000
Subject: [Development] Update of QUIP-14 (Module Criteria)
Message-ID: <GV1PR02MB8756E1B4DC1A547D284560719840A@GV1PR02MB8756.eurprd02.prod.outlook.com>

Hi,

I?d like to do some changes to QUIP-14 , concerned with criteria for Qt modules.

Patch series is here: https://codereview.qt-project.org/c/meta/quips/+/720511/3

QUIP-14: Fix indentation<https://codereview.qt-project.org/c/meta/quips/+/720509/1?usp=related-change> and QUIP-14: Fix capitalization of Qt GUI<https://codereview.qt-project.org/c/meta/quips/+/720510/1?usp=related-change> are purely editorial.

QUIP-14: Remove mentioning of \modulestate<https://codereview.qt-project.org/c/meta/quips/+/720511/3?usp=related-change> changes how we should document modules in TP / deprecations inside the Qt module documentation. Since Qt 6.11, we should just use the \obsolete and \deprecated qdoc commands, instead of using the \modulestate command.

Any feedback welcome,

Kai

--

Kai K?hne, Director R&D | The Qt Company



The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin

Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Jouni Lintunen

Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260316/18450507/attachment.htm>

From axel.spoerl at qt.io  Tue Mar 17 13:10:12 2026
From: axel.spoerl at qt.io (Axel Spoerl)
Date: Tue, 17 Mar 2026 12:10:12 +0000
Subject: [Development] qt5.git broken / staging restricted
Message-ID: <AS8PR02MB1041116CD4927AEDC7EBAE974FE41A@AS8PR02MB10411.eurprd02.prod.outlook.com>

Hi all,

Staging on qt5.git shall remain restricted until further notice, because toplevel builds are broken.
We're also cancelling ongoing integrations, as they are bound to fail.
Fixing is ongoing and we will keep you posted.

Sorry for the inconvenience!
Axel

Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260317/55251dc3/attachment.htm>

From volker.hilsheimer at qt.io  Thu Mar 19 15:22:43 2026
From: volker.hilsheimer at qt.io (Volker Hilsheimer)
Date: Thu, 19 Mar 2026 14:22:43 +0000
Subject: [Development] Nominating Vladimir Belyavsky as Qt Project approver
Message-ID: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>

Hello World,

I?d like to nominate Vladimir Belyavsky as approver in the Qt Project.

Vladimir has made a large number of contributions [1], provided substantial and high-quality reviews [2], and reported and given comments to plenty of tickets in Jira, covering a wide range of topics.

[1] https://codereview.qt-project.org/q/owner:belyavskyv at gmail.com
[2] https://codereview.qt-project.org/q/-owner:belyavskyv at gmail.com+commentby:belyavskyv at gmail.com

After starting to contribute in 2022, Vladimir made it into the top contributor lists in both 2023 and 2024:

https://www.qt.io/blog/qt-project-top-contributors-of-2023
https://www.qt.io/blog/top-contributors-of-2024

Based on what I have seen and how I experience collaborating with him, I trust that Vladimir will use his approver privileges responsibly and in the best interest of the Qt Project.


Disclaimer: I don?t know Vladimir in real life; he lives in Minsk. Given the state of the world, I respect that this might be a cause for concern. He has been using Qt for ~20 years, and his employer for the last 11 years has been Rakuten Viber, which has its HQ in Luxemburg, where he is using Qt professionally as a Team Lead. Vladimir has been very responsive to me when I asked some relevant questions over email. If you want to raise objection and don?t want to do so on a public channel, feel free to do so to me directly.


Volker


From alexander.blasche at qt.io  Thu Mar 19 16:34:58 2026
From: alexander.blasche at qt.io (Alex Blasche)
Date: Thu, 19 Mar 2026 15:34:58 +0000
Subject: [Development] How to indicate regressions in Jira
Message-ID: <DB8PR02MB5897B9B92CA748E93CDF360EE74FA@DB8PR02MB5897.eurprd02.prod.outlook.com>

Hi,

I would like to highlight a new Jira field for regression handling. It is called "Last Working Versions" and is a multiple version picker field. Rather than adding [REG 6.8.3 ->6.5.4] to the Summary/Title field of a bug, we want to use traditional Jira version fields. In the case of the mentioned example you should set "Affects Versions" to 6.8.4 and "Last Working Versions" to 6.8.3. We will convert existing regressions to this new world order.

I have updated the official Bug Reporting wiki to reflect this: https://wiki.qt.io/Reporting_Bugs#Last_Working_Versions

Why the change? 

It provides a less error prone and more structured way to highlight regressions. A simple search for all regressions in the system would be the following JQL: "Last Working Versions" IS NOT EMPTY.

If there are any issues please contact jira-admin at qt-project.org

?--
Alex


From axel.spoerl at qt.io  Fri Mar 20 13:53:13 2026
From: axel.spoerl at qt.io (Axel Spoerl)
Date: Fri, 20 Mar 2026 12:53:13 +0000
Subject: [Development] =?utf-8?q?Pilot=3A_Automatic_Re=E2=80=91Staging_in?=
 =?utf-8?q?_Gerrit_for_CI-Unrelated_Failures?=
Message-ID: <AS8PR02MB10411E75971A294E8DA948FB4FE4CA@AS8PR02MB10411.eurprd02.prod.outlook.com>

TL;DR:
Starting Tuesday, March 24th, we will pilot automatic re?staging in Gerrit when CI failures when it is fair to assume they are unrelated.
Runs happen at 21:00 and 01:00 CET. Opt?out available on commit level.

Hi Qt developers,
Starting Tuesday, March 24th, we will roll out a pilot that automatically re?stages Gerrit commits under a clearly defined set of conditions.
The goal is to reduce manual babysitting of changes that were perfectly fine, but had the misfortune of encountering a flaky CI failure or pairing with a bad commit.
A commit?s latest patchset will be automatically re?staged if all of the following are true:

  *   The patchset was staged and its integration failed.
  *
QtCIAnalysisBot left a comment indicating that the failure was unrelated to the patch, i.e. recommending a re-stage.
  *   The patchset has not already been auto?re?staged by the tool.

Practical notes:

  *   The pilot applies to all submodules except qt5.git.
  *
Automatic re?staging runs will occur daily at 21:00 and 01:00 CET. Additional runs may take place as we see need and fit.
  *   During the pilot, re?staging will be performed using my personal Gerrit user.
  *
Each action will leave a Gerrit comment: ?This commit was auto?restaged.?
  *
Committs are eligible for auto-re-stage by default. During the pilot phase, opting in / out works on commit level via a comment.
=> Opt out: Add a comment starting with "auto-restage:off"
=> Opt in (after opt out): Add a comment starting with "auto-restage:on"

Time frame:
The pilot will run for approx. 2 weeks.
Based your feedback and experience made, we will implement a permanent solution.
If you have questions, suggestions, or concerns about the pilot, I?m happy to discuss.
Best regards and have a wonderful weekend,
Axel

PS:
Fun fact for David Faure and Peppe (and anyone else with a healthy appreciation for good APIs):
The auto?re?staging tool is written in Qt. It uses a QAbstractItemModel to hold and analyse commit metadata. QAbstractItemModel rocks!

Public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260320/94ca4945/attachment.htm>

From Eskil.Abrahamsen-Blomfeldt at qt.io  Fri Mar 20 15:00:18 2026
From: Eskil.Abrahamsen-Blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt)
Date: Fri, 20 Mar 2026 14:00:18 +0000
Subject: [Development] Nominating Vladimir Belyavsky as Qt Project
 approver
In-Reply-To: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
References: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
Message-ID: <GVUPR02MB117814600311D9D0D80FE513ED34CA@GVUPR02MB11781.eurprd02.prod.outlook.com>

+1 from me. I have reviewed several of Vladimir's patches and consider him a solid contributor.

--
Eskil Abrahamsen Blomfeldt
Principal Manager, Graphics Engines

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfeldt at qt.io
http://qt.io

Confidential
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Volker Hilsheimer via Development <development at qt-project.org>
Sent: Thursday, March 19, 2026 3:22 PM
To: development at qt-project.org <development at qt-project.org>
Subject: [Development] Nominating Vladimir Belyavsky as Qt Project approver

Hello World,

I?d like to nominate Vladimir Belyavsky as approver in the Qt Project.

Vladimir has made a large number of contributions [1], provided substantial and high-quality reviews [2], and reported and given comments to plenty of tickets in Jira, covering a wide range of topics.

[1] https://codereview.qt-project.org/q/owner:belyavskyv at gmail.com
[2] https://codereview.qt-project.org/q/-owner:belyavskyv at gmail.com+commentby:belyavskyv at gmail.com

After starting to contribute in 2022, Vladimir made it into the top contributor lists in both 2023 and 2024:

https://www.qt.io/blog/qt-project-top-contributors-of-2023
https://www.qt.io/blog/top-contributors-of-2024

Based on what I have seen and how I experience collaborating with him, I trust that Vladimir will use his approver privileges responsibly and in the best interest of the Qt Project.


Disclaimer: I don?t know Vladimir in real life; he lives in Minsk. Given the state of the world, I respect that this might be a cause for concern. He has been using Qt for ~20 years, and his employer for the last 11 years has been Rakuten Viber, which has its HQ in Luxemburg, where he is using Qt professionally as a Team Lead. Vladimir has been very responsive to me when I asked some relevant questions over email. If you want to raise objection and don?t want to do so on a public channel, feel free to do so to me directly.


Volker

--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260320/d2d53a68/attachment-0001.htm>

From fabian.kosmale at qt.io  Fri Mar 20 15:12:28 2026
From: fabian.kosmale at qt.io (Fabian Kosmale)
Date: Fri, 20 Mar 2026 15:12:28 +0100
Subject: [Development] Nominating Vladimir Belyavsky as Qt Project
 approver
In-Reply-To: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
References: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
Message-ID: <2cd45185-ae6c-4e11-9373-7336c6e3959d@qt.io>

+1 from me, too. I reviewed some of his patches, and also interacted
with him in the review process. Based on that, I'm confident that he'll
use the approver rights conscientiously.

Fabian

On 3/19/26 15:22, Volker Hilsheimer via Development wrote:
> Hello World,
> 
> I?d like to nominate Vladimir Belyavsky as approver in the Qt Project.
> 
> Vladimir has made a large number of contributions [1], provided substantial and high-quality reviews [2], and reported and given comments to plenty of tickets in Jira, covering a wide range of topics.
> 
> [1] https://codereview.qt-project.org/q/owner:belyavskyv at gmail.com
> [2] https://codereview.qt-project.org/q/-owner:belyavskyv at gmail.com+commentby:belyavskyv at gmail.com
> 
> After starting to contribute in 2022, Vladimir made it into the top contributor lists in both 2023 and 2024:
> 
> https://www.qt.io/blog/qt-project-top-contributors-of-2023
> https://www.qt.io/blog/top-contributors-of-2024
> 
> Based on what I have seen and how I experience collaborating with him, I trust that Vladimir will use his approver privileges responsibly and in the best interest of the Qt Project.
> 
> 
> Disclaimer: I don?t know Vladimir in real life; he lives in Minsk. Given the state of the world, I respect that this might be a cause for concern. He has been using Qt for ~20 years, and his employer for the last 11 years has been Rakuten Viber, which has its HQ in Luxemburg, where he is using Qt professionally as a Team Lead. Vladimir has been very responsive to me when I asked some relevant questions over email. If you want to raise objection and don?t want to do so on a public channel, feel free to do so to me directly.
> 
> 
> Volker
> 

-- 
Fabian Kosmale
Manager R&D

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosmale at qt.io
+49 1638686070


From thiago.macieira at intel.com  Fri Mar 20 18:13:47 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 20 Mar 2026 10:13:47 -0700
Subject: [Development] Nominating Vladimir Belyavsky as Qt Project
 approver
In-Reply-To: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
References: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
Message-ID: <3199157.lGaqSPkdTl@tjmaciei-mobl5>

On Thursday, 19 March 2026 07:22:43 Pacific Daylight Time Volker Hilsheimer via 
Development wrote:
> I?d like to nominate Vladimir Belyavsky as approver in the Qt Project.
> 
> Vladimir has made a large number of contributions [1], provided substantial
> and high-quality reviews [2], and reported and given comments to plenty of
> tickets in Jira, covering a wide range of topics.
> 
> [1] https://codereview.qt-project.org/q/owner:belyavskyv at gmail.com
> [2]
> https://codereview.qt-project.org/q/-owner:belyavskyv at gmail.com+commentby:b
> elyavskyv at gmail.com

+1 from me too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260320/8db7454e/attachment.bin>

From Shawn.Rutledge at qt.io  Fri Mar 20 18:45:41 2026
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Fri, 20 Mar 2026 17:45:41 +0000
Subject: [Development] Nominating Vladimir Belyavsky as Qt Project
 approver
In-Reply-To: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
References: <C718CA4C-FFAE-4172-9312-3DA40B5A957E@qt.io>
Message-ID: <1DF890B7-DB0E-4853-9EC9-3D87430BC67E@qt.io>

+1 from me too

> On Mar 19, 2026, at 15:22, Volker Hilsheimer via Development <development at qt-project.org> wrote:
> 
> Hello World,
> 
> I?d like to nominate Vladimir Belyavsky as approver in the Qt Project.

From announce at qt-project.org  Mon Mar 23 11:11:54 2026
From: announce at qt-project.org (List for announcements regarding Qt releases and development via Announce)
Date: Mon, 23 Mar 2026 10:11:54 +0000
Subject: [Development] [Announce] Qt 6.11.0 Released
Message-ID: <mailman.6176.1774260723.837.announce@qt-project.org>

Hi all,

Qt 6.11.0 has been officially released!
You can find more details about the release here: https://www.qt.io/blog/qt-6.11-released

A big thank you to everyone who contributed to making this happen!

Best regards,
Jani Heikkinen
Release Manager
_______________________________________________
Announce mailing list
Announce at qt-project.org
https://lists.qt-project.org/listinfo/announce

From axel.spoerl at qt.io  Mon Mar 23 12:12:21 2026
From: axel.spoerl at qt.io (Axel Spoerl)
Date: Mon, 23 Mar 2026 11:12:21 +0000
Subject: [Development] qt5.git broken / staging restricted
In-Reply-To: <AS8PR02MB1041116CD4927AEDC7EBAE974FE41A@AS8PR02MB10411.eurprd02.prod.outlook.com>
References: <AS8PR02MB1041116CD4927AEDC7EBAE974FE41A@AS8PR02MB10411.eurprd02.prod.outlook.com>
Message-ID: <AS8PR02MB1041165BBA5C88101B6F16978FE4BA@AS8PR02MB10411.eurprd02.prod.outlook.com>

Hi all,

staging in qt5 is possible again.
My colleague Jimis has already informed the mailing list last Thursday. However, for some reason his e-mail hasn't made it to the mailing list archive.

Again, sorry for the inconvenience and thanks for your patience!
Axel


Confidential
________________________________
From: Axel Spoerl <axel.spoerl at qt.io>
Sent: Tuesday, 17 March 2026 13:10
To: development <development at qt-project.org>
Subject: qt5.git broken / staging restricted

Hi all,

Staging on qt5.git shall remain restricted until further notice, because toplevel builds are broken.
We're also cancelling ongoing integrations, as they are bound to fail.
Fixing is ongoing and we will keep you posted.

Sorry for the inconvenience!
Axel

Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260323/3d8fa3ed/attachment.htm>

From jani.heikkinen at qt.io  Wed Mar 25 06:48:27 2026
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 25 Mar 2026 05:48:27 +0000
Subject: [Development] Deciding on EOL for Visual Studio 2022
In-Reply-To: <5005141.OV4Wx5bFTl@tjmaciei-mobl5>
References: <2456515.cojqenx9y0@tjmaciei-mobl5>
 <3898376.LZWGnKmheA@tjmaciei-mobl5>
 <PH3PPF7D4C631E30C18FDDBC269966D043FA9DBA@PH3PPF7D4C631E3.namprd10.prod.outlook.com>
 <5005141.OV4Wx5bFTl@tjmaciei-mobl5>
Message-ID: <VI0PR02MB117745F8B1963857B7036FC689D49A@VI0PR02MB11774.eurprd02.prod.outlook.com>

Hi!
Has this already received a final decision? If not, I think we should complete this as soon as possible. The same applies the 'Windows 10 EOL in Qt  thread' here: https://lists.qt-project.org/pipermail/development/2026-February/046970.html

br,
Jani


________________________________________
From: Development <development-bounces at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Monday, December 1, 2025 10:57 PM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Deciding on EOL for Visual Studio 2022


On Monday, 1 December 2025 11:51:31 Pacific Standard Time Scott Bloom wrote:
> > Anyway, I think the proposal I made for VS2026 still makes sense for the
> > Qt Project:
> > * 2026-2027: toolchains 14.44 (VS2022), 14.50, sliding 14.51-53
> > * 2028-2029: toolchains 14.50, 14.54, sliding 14.55-57
> > * 2029-2030: toolchains 14.54, 14.58, sliding 14.59-61
> > 
> > This would mean Qt 6.12 still supports VS2022, but Qt 6.16 (Oct 2028) does
> > not.
> 
> --
> Just my 2 bits from a user POV.
> 
> Please allow 18 to 24 months before you REQUIRE 2026 for building a Qt
> project.? Meaning any new C++ features that 2026 has that 2022's latest
> patch does not support be held off in use in the public API for up to two
> years after the release of 2026.

>From the plan above, VS2026 won't be required until 2028, specifically starting 
with Qt 6.15. That's over 24 months from today.

But I agree on sufficient notice, which means we should make this decision in 
time for the Qt 6.11 release announcement.

It's a different story to about adding content to our headers that requires 
VS2026. At that point, it won't be about just Visual C++. It's highly unlikely 
the compilers holding us back now will have been updated in 24 months time.

But I repeat we should add new, optional features that depend on C++20 or even 
23. People who won't upgrade simply will have to settle for doing things the 
way they're doing them today. I personally do not plan on writing any non-
concept code for any new template function.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
? Principal Engineer - Intel DCG - Platform & Sys. Eng.



From igor at khanin.biz  Wed Mar 25 10:22:45 2026
From: igor at khanin.biz (Igor Khanin)
Date: Wed, 25 Mar 2026 11:22:45 +0200
Subject: [Development] Disabling Pull Requests on GitHub Mirrors
Message-ID: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>

Hello,

I'm not sure who is responsible for administering the mirrors of Qt 
source code in GitHub under https://github.com/qt, but now that GitHub 
has made this an option - I think that the pull requests tab should 
probably be disabled in the repositories there. People still seem to 
routinely try to make a contribution through the usual GitHub flow and 
then wonder why their PRs are ignored. This could be coupled with 
copying the CONTRIBUTING.md file from the top level qt5 repository also 
to the main module repositories (qtbase,? qtdeclarative, etc) as GitHub 
highlights its' content in the UI.

All the best,
Igor



From Cristian.Maureira-Fredes at qt.io  Wed Mar 25 10:52:46 2026
From: Cristian.Maureira-Fredes at qt.io (=?UTF-8?Q?Cristi=C3=A1n_Maureira-Fredes?=)
Date: Wed, 25 Mar 2026 10:52:46 +0100
Subject: [Development] Disabling Pull Requests on GitHub Mirrors
In-Reply-To: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>
References: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>
Message-ID: <3c42acdc-0357-458d-8d6d-74128d495caf@qt.io>



On 3/25/26 10:22 AM, Igor Khanin wrote:
> Hello,
> 
> I'm not sure who is responsible for administering the mirrors of Qt 
> source code in GitHub under https:// 
> eur01.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Fgithub.com%2Fqt&data=05%7C02%7C%7Cd1315c47e56947ddacca08de8a506041%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C639100275035196762%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9ol38zWlUUOMlt3x1cbO%2FbecW8C2cr%2Fyxk2M1cYl8Qs%3D&reserved=0, but now that GitHub has made this an option - I think that the pull requests tab should probably be disabled in the repositories there. People still seem to routinely try to make a contribution through the usual GitHub flow and then wonder why their PRs are ignored. This could be coupled with copying the CONTRIBUTING.md file from the top level qt5 repository also to the main module repositories (qtbase,? qtdeclarative, etc) as GitHub highlights its' content in the UI.
> 
> All the best,
> Igor


Good catch,
I have disabled it for qt5 and all its submodules.
In case I missed one, please let me know.

Cheers!

-- 
Dr. Cristian Maureira-Fredes
Principal R&D Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Gesch?ftsf?hrer: Mika P?lsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--


From Kai.Koehne at qt.io  Wed Mar 25 11:05:32 2026
From: Kai.Koehne at qt.io (=?utf-8?B?S2FpIEvDtmhuZQ==?=)
Date: Wed, 25 Mar 2026 10:05:32 +0000
Subject: [Development] Disabling Pull Requests on GitHub Mirrors
In-Reply-To: <3c42acdc-0357-458d-8d6d-74128d495caf@qt.io>
References: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>
 <3c42acdc-0357-458d-8d6d-74128d495caf@qt.io>
Message-ID: <DB4PR02MB877526BD229FD786DA02B0E19849A@DB4PR02MB8775.eurprd02.prod.outlook.com>

Hi,

For the CONTRIBUTING.md file: I?ve created https://codereview.qt-project.org/c/qt/qt5/+/724054 , so that we point to contribute.qt-project.org .

If we can agree on this, I?m happy to push this file to all repositories ?

Kai



Confidential

From: Development <development-bounces at qt-project.org> on behalf of Cristi?n Maureira-Fredes via Development <development at qt-project.org>
Date: Wednesday, 25. March 2026 at 10:54
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Disabling Pull Requests on GitHub Mirrors



On 3/25/26 10:22 AM, Igor Khanin wrote:
> Hello,
>
> I'm not sure who is responsible for administering the mirrors of Qt
> source code in GitHub under https://
> eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Fqt&data=05%7C02%7C%7Cd1315c47e56947ddacca08de8a506041%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C639100275035196762%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9ol38zWlUUOMlt3x1cbO%2FbecW8C2cr%2Fyxk2M1cYl8Qs%3D&reserved=0, but now that GitHub has made this an option - I think that the pull requests tab should probably be disabled in the repositories there. People still seem to routinely try to make a contribution through the usual GitHub flow and then wonder why their PRs are ignored. This could be coupled with copying the CONTRIBUTING.md file from the top level qt5 repository also to the main module repositories (qtbase,  qtdeclarative, etc) as GitHub highlights its' content in the UI.
>
> All the best,
> Igor


Good catch,
I have disabled it for qt5 and all its submodules.
In case I missed one, please let me know.

Cheers!

--
Dr. Cristian Maureira-Fredes
Principal R&D Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Gesch?ftsf?hrer: Mika P?lsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--

--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260325/ecefb347/attachment-0001.htm>

From Kai.Koehne at qt.io  Wed Mar 25 12:57:55 2026
From: Kai.Koehne at qt.io (=?utf-8?B?S2FpIEvDtmhuZQ==?=)
Date: Wed, 25 Mar 2026 11:57:55 +0000
Subject: [Development] Disabling Pull Requests on GitHub Mirrors
In-Reply-To: <DB4PR02MB877526BD229FD786DA02B0E19849A@DB4PR02MB8775.eurprd02.prod.outlook.com>
References: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>
 <3c42acdc-0357-458d-8d6d-74128d495caf@qt.io>
 <DB4PR02MB877526BD229FD786DA02B0E19849A@DB4PR02MB8775.eurprd02.prod.outlook.com>
Message-ID: <DB4PR02MB8775224E703A74CE36DA08979849A@DB4PR02MB8775.eurprd02.prod.outlook.com>

Thanks for the reviews!

If anyone now has 46 +2 ?s to spare ? ?

https://codereview.qt-project.org/q/topic:%22contributing_md%22

Kai



Confidential

From: Development <development-bounces at qt-project.org> on behalf of Kai K?hne via Development <development at qt-project.org>
Date: Wednesday, 25. March 2026 at 11:08
To: Cristi?n Maureira-Fredes <Cristian.Maureira-Fredes at qt.io>, development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Disabling Pull Requests on GitHub Mirrors

Hi,

For the CONTRIBUTING.md file: I?ve created https://codereview.qt-project.org/c/qt/qt5/+/724054 , so that we point to contribute.qt-project.org .

If we can agree on this, I?m happy to push this file to all repositories ?

Kai



Confidential

From: Development <development-bounces at qt-project.org> on behalf of Cristi?n Maureira-Fredes via Development <development at qt-project.org>
Date: Wednesday, 25. March 2026 at 10:54
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Disabling Pull Requests on GitHub Mirrors



On 3/25/26 10:22 AM, Igor Khanin wrote:
> Hello,
>
> I'm not sure who is responsible for administering the mirrors of Qt
> source code in GitHub under https://
> eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Fqt&data=05%7C02%7C%7Cd1315c47e56947ddacca08de8a506041%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C639100275035196762%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9ol38zWlUUOMlt3x1cbO%2FbecW8C2cr%2Fyxk2M1cYl8Qs%3D&reserved=0, but now that GitHub has made this an option - I think that the pull requests tab should probably be disabled in the repositories there. People still seem to routinely try to make a contribution through the usual GitHub flow and then wonder why their PRs are ignored. This could be coupled with copying the CONTRIBUTING.md file from the top level qt5 repository also to the main module repositories (qtbase,  qtdeclarative, etc) as GitHub highlights its' content in the UI.
>
> All the best,
> Igor


Good catch,
I have disabled it for qt5 and all its submodules.
In case I missed one, please let me know.

Cheers!

--
Dr. Cristian Maureira-Fredes
Principal R&D Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Gesch?ftsf?hrer: Mika P?lsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--

--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260325/7ee1ca6d/attachment.htm>

From Paul.Wicking at qt.io  Wed Mar 25 13:07:07 2026
From: Paul.Wicking at qt.io (Paul Wicking)
Date: Wed, 25 Mar 2026 12:07:07 +0000
Subject: [Development] Disabling Pull Requests on GitHub Mirrors
In-Reply-To: <DB4PR02MB8775224E703A74CE36DA08979849A@DB4PR02MB8775.eurprd02.prod.outlook.com>
References: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>
 <3c42acdc-0357-458d-8d6d-74128d495caf@qt.io>
 <DB4PR02MB877526BD229FD786DA02B0E19849A@DB4PR02MB8775.eurprd02.prod.outlook.com>
 <DB4PR02MB8775224E703A74CE36DA08979849A@DB4PR02MB8775.eurprd02.prod.outlook.com>
Message-ID: <FA080D63-E203-4CED-A8C8-DA29B4D1F8F3@qt.io>

Done. Shoutout for good use of Gerrit's topic feature :)

//! Paul

On 25 Mar 2026, at 12:57, Kai K?hne via Development <development at qt-project.org> wrote:

Thanks for the reviews!

If anyone now has 46 +2 ?s to spare ? ?

https://codereview.qt-project.org/q/topic:%22contributing_md%22

Kai



Confidential

From: Development <development-bounces at qt-project.org> on behalf of Kai K?hne via Development <development at qt-project.org>
Date: Wednesday, 25. March 2026 at 11:08
To: Cristi?n Maureira-Fredes <Cristian.Maureira-Fredes at qt.io>, development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Disabling Pull Requests on GitHub Mirrors

Hi,

For the CONTRIBUTING.md file: I?ve created https://codereview.qt-project.org/c/qt/qt5/+/724054 , so that we point to contribute.qt-project.org .

If we can agree on this, I?m happy to push this file to all repositories ?

Kai



Confidential

From: Development <development-bounces at qt-project.org> on behalf of Cristi?n Maureira-Fredes via Development <development at qt-project.org>
Date: Wednesday, 25. March 2026 at 10:54
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Disabling Pull Requests on GitHub Mirrors



On 3/25/26 10:22 AM, Igor Khanin wrote:
> Hello,
>
> I'm not sure who is responsible for administering the mirrors of Qt
> source code in GitHub under https://
> eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Fqt&data=05%7C02%7C%7Cd1315c47e56947ddacca08de8a506041%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C639100275035196762%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9ol38zWlUUOMlt3x1cbO%2FbecW8C2cr%2Fyxk2M1cYl8Qs%3D&reserved=0, but now that GitHub has made this an option - I think that the pull requests tab should probably be disabled in the repositories there. People still seem to routinely try to make a contribution through the usual GitHub flow and then wonder why their PRs are ignored. This could be coupled with copying the CONTRIBUTING.md file from the top level qt5 repository also to the main module repositories (qtbase,  qtdeclarative, etc) as GitHub highlights its' content in the UI.
>
> All the best,
> Igor


Good catch,
I have disabled it for qt5 and all its submodules.
In case I missed one, please let me know.

Cheers!

--
Dr. Cristian Maureira-Fredes
Principal R&D Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Gesch?ftsf?hrer: Mika P?lsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260325/8fe7c55f/attachment-0001.htm>

From thiago.macieira at intel.com  Wed Mar 25 16:30:38 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 25 Mar 2026 08:30:38 -0700
Subject: [Development] Deciding on EOL for Visual Studio 2022
In-Reply-To: <VI0PR02MB117745F8B1963857B7036FC689D49A@VI0PR02MB11774.eurprd02.prod.outlook.com>
References: <2456515.cojqenx9y0@tjmaciei-mobl5>
 <5005141.OV4Wx5bFTl@tjmaciei-mobl5>
 <VI0PR02MB117745F8B1963857B7036FC689D49A@VI0PR02MB11774.eurprd02.prod.outlook.com>
Message-ID: <2880655.fDdHjke4Dd@tjmaciei-mobl5>

On Tuesday, 24 March 2026 22:48:27 Pacific Daylight Time Jani Heikkinen via 
Development wrote:
> Has this already received a final decision? If not, I think we should
> complete this as soon as possible. The same applies the 'Windows 10 EOL in
> Qt  thread' here:
> https://lists.qt-project.org/pipermail/development/2026-February/046970.htm
> l

I'm going to ask for silent consensus on the proposal, which I reiterate:
* 2026-2027: toolchains 14.44 (VS2022), 14.50, sliding 14.51-53
* 2028-2029: toolchains 14.50, 14.54, sliding 14.55-57
* 2029-2030: toolchains 14.54, 14.58, sliding 14.59-61

This would mean Qt 6.12 still supports VS2022, but Qt 6.16 (Oct 2028) does 
not.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260325/152403fc/attachment.bin>

From thiago.macieira at intel.com  Wed Mar 25 16:31:59 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 25 Mar 2026 08:31:59 -0700
Subject: [Development] Disabling Pull Requests on GitHub Mirrors
In-Reply-To: <FA080D63-E203-4CED-A8C8-DA29B4D1F8F3@qt.io>
References: <852f1216-f0ae-475b-9c6d-30dba9486359@khanin.biz>
 <DB4PR02MB8775224E703A74CE36DA08979849A@DB4PR02MB8775.eurprd02.prod.outlook.com>
 <FA080D63-E203-4CED-A8C8-DA29B4D1F8F3@qt.io>
Message-ID: <5968605.IbC2pHGDlb@tjmaciei-mobl5>

On Wednesday, 25 March 2026 05:07:07 Pacific Daylight Time Paul Wicking via 
Development wrote:
> Done. Shoutout for good use of Gerrit's topic feature ?

Shout out to Gerrit in general. I hate reviewing on GitHub...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260325/9ecf667f/attachment.bin>

From scott at towel42.com  Wed Mar 25 20:43:23 2026
From: scott at towel42.com (Scott Bloom)
Date: Wed, 25 Mar 2026 19:43:23 +0000
Subject: [Development] Windows 11 Printing
Message-ID: <PH3PPF7D4C631E36780650FF4DD5395EB71A949A@PH3PPF7D4C631E3.namprd10.prod.outlook.com>

The new windows 11 print dialog, has a built in preview, effectively making the QPrintPreviewDialog obsolete.

However, Qt doesn't interact with the new dialog for the preview aspect.

Is there any timeline for this to be supported?

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260325/c82ed0b3/attachment-0001.htm>

From szehowe.koh at gmail.com  Thu Mar 26 07:13:36 2026
From: szehowe.koh at gmail.com (Sze Howe Koh)
Date: Thu, 26 Mar 2026 14:13:36 +0800
Subject: [Development] Copy initialization vs. direct initialization?
Message-ID: <CALW8pfW=d0p0=pKgtaux=0Q-edOMC=4LEwJD2wSYAG+XLxod5A@mail.gmail.com>

Does the Qt Project have a preference between the following?

    QVector2D myVector = QVector2D(x, y);

vs.

    QVector2D myVector(x, y);

Context: https://codereview.qt-project.org/c/qt/qtdeclarative/+/642149
used the former;
https://codereview.qt-project.org/c/qt/qtdeclarative/+/724447 copies
the older patch's logic while trying the latter syntax. I plan to make
them consistent with each other, but I don't know which way is
preferred.

https://wiki.qt.io/Qt_Coding_Style and
https://wiki.qt.io/Coding_Conventions don't discuss this.


Regards,
Sze-Howe

From giuseppe.dangelo at kdab.com  Thu Mar 26 08:50:47 2026
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Thu, 26 Mar 2026 08:50:47 +0100
Subject: [Development] Copy initialization vs. direct initialization?
In-Reply-To: <CALW8pfW=d0p0=pKgtaux=0Q-edOMC=4LEwJD2wSYAG+XLxod5A@mail.gmail.com>
References: <CALW8pfW=d0p0=pKgtaux=0Q-edOMC=4LEwJD2wSYAG+XLxod5A@mail.gmail.com>
Message-ID: <a1e69dbe-3450-48ab-a30f-93a3fcf3ecbb@kdab.com>

Hi,

Il 26/03/26 07:13, Sze Howe Koh ha scritto:
> Does the Qt Project have a preference between the following?
> 
>      QVector2D myVector = QVector2D(x, y);
> 
> vs.
> 
>      QVector2D myVector(x, y);
> 
> Context: https://codereview.qt-project.org/c/qt/qtdeclarative/+/642149
> used the former;
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/724447 copies
> the older patch's logic while trying the latter syntax. I plan to make
> them consistent with each other, but I don't know which way is
> preferred.
> 
> https://wiki.qt.io/Qt_Coding_Style and
> https://wiki.qt.io/Coding_Conventions don't discuss this.

No, it's up to the author's preferences, hopefully by mimicking the 
surrounding style. There's a minor preference towards using copy 
initialization in general and/or braced initialization (in order to 
avoid the most vexing parse), but again it's up to you. To be honest I 
don't think anyone would write `QVector2D myvector = {x, y}` (I 
certainly wouldn't).

Do note that the two forms you posted above are absolutely equivalent, 
and in neither case there's copy initialization.

[insert meme on how many different syntaxes C++ has for initialization 
and how each one is subtly broken]


Thank you,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260326/0f65ec66/attachment.bin>

From oliver.wolff at qt.io  Thu Mar 26 09:04:13 2026
From: oliver.wolff at qt.io (Oliver Wolff)
Date: Thu, 26 Mar 2026 09:04:13 +0100
Subject: [Development] Deciding on EOL for Visual Studio 2022
In-Reply-To: <2880655.fDdHjke4Dd@tjmaciei-mobl5>
References: <2456515.cojqenx9y0@tjmaciei-mobl5>
 <5005141.OV4Wx5bFTl@tjmaciei-mobl5>
 <VI0PR02MB117745F8B1963857B7036FC689D49A@VI0PR02MB11774.eurprd02.prod.outlook.com>
 <2880655.fDdHjke4Dd@tjmaciei-mobl5>
Message-ID: <5a1ad917-a563-469e-aa2e-930c22d41310@qt.io>

Hi,

On 25/03/2026 16:30, Thiago Macieira wrote:
> On Tuesday, 24 March 2026 22:48:27 Pacific Daylight Time Jani Heikkinen via
> Development wrote:
>> Has this already received a final decision? If not, I think we should
>> complete this as soon as possible. The same applies the 'Windows 10 EOL in
>> Qt  thread' here:
>> https://lists.qt-project.org/pipermail/development/2026-February/046970.htm
>> l
> 
> I'm going to ask for silent consensus on the proposal, which I reiterate:
> * 2026-2027: toolchains 14.44 (VS2022), 14.50, sliding 14.51-53
> * 2028-2029: toolchains 14.50, 14.54, sliding 14.55-57
> * 2029-2030: toolchains 14.54, 14.58, sliding 14.59-61
> 
> This would mean Qt 6.12 still supports VS2022, but Qt 6.16 (Oct 2028) does
> not.
> 
> 

Even though that might break the "silent" part of that suggestion: I 
agree with that proposal. Sounds fine for me.

Olli

From thiago.macieira at intel.com  Thu Mar 26 18:09:08 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 26 Mar 2026 10:09:08 -0700
Subject: [Development] Deciding on EOL for Visual Studio 2022
In-Reply-To: <5a1ad917-a563-469e-aa2e-930c22d41310@qt.io>
References: <2456515.cojqenx9y0@tjmaciei-mobl5>
 <2880655.fDdHjke4Dd@tjmaciei-mobl5>
 <5a1ad917-a563-469e-aa2e-930c22d41310@qt.io>
Message-ID: <7028809.MDQidcC6GM@tjmaciei-mobl5>

On Thursday, 26 March 2026 01:04:13 Pacific Daylight Time Oliver Wolff via 
Development wrote:
> > I'm going to ask for silent consensus on the proposal, which I reiterate:
> > * 2026-2027: toolchains 14.44 (VS2022), 14.50, sliding 14.51-53
> > * 2028-2029: toolchains 14.50, 14.54, sliding 14.55-57
> > * 2029-2030: toolchains 14.54, 14.58, sliding 14.59-61
> > 
> > This would mean Qt 6.12 still supports VS2022, but Qt 6.16 (Oct 2028) does
> > not.
> 
> Even though that might break the "silent" part of that suggestion: I
> agree with that proposal. Sounds fine for me.

"Silent consensus" when the absence of opposition can be interpreted as 
assent. So you have not broken the silence :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260326/853ec26d/attachment.bin>

From marc.mutz at qt.io  Thu Mar 26 19:41:38 2026
From: marc.mutz at qt.io (Marc Mutz)
Date: Thu, 26 Mar 2026 18:41:38 +0000
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
Message-ID: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>

Hi,

We Qt developers cannot figure out how to proceed from here, so let me give you a heads-up here, so you can take matters into your own hands.

TL;DR: never pass Connection objects originally declared const to QObject::disconnect(Connection).

The function const_cast<>s away the const of the argument to reset the d_ptr to nullptr. It doesn't matter why, suffice to say that it's not trivial to fix either way on the Qt side.

It _is_ trivial to fix on the user side: Just don't pass const objects.

If you don't pass const objects, you're on the safe side. Period. End of story.

If you pass const objects, but they're not _originally_ marked as const (e.g. you're using const_iterators over a QList<Connection>, then there's also nothing to do, but, depending on how the story unfolds, you may get deprecation warnings in the future.

If you pass const objects _originally marked as const_ (e.g. the key of a std::map, or an object you declared const yourself:

    const auto c = QObject::connect(~~~~);
    ~~~~
    QObject::disconnect(c); // UB!!

Then you need to take action: make the Connection object _not_ originally const. In the case above, do

    auto c = QObject::connect(~~~~); // NOT const!

if you don't control the declaration (e.g. its a key in a std::map), then DO NOT CALL disconnect() on it. Take a copy and call disconnect() on that:

   const c = QObject::connect(~~~~); // can't change this even if I tried
   ~~~~
   auto copy = c; // take a copy
   QObject::disconnect(copy); // and only disconnect() the copy

The connection will be disconnected either way, it suffices if any of the copies of the Connection gets passed to disconnect() (but memory is held longer, until `c` is actually destroyed, there is no way to prevent that - that's exactly the UB).

Patch your code, and pick to all your branches. You do _not_ need to update your production Qt. This fix even fixes it for Qt versions that are out of support!

In all of Qt, we have so found _one_ instance of the latter. And the fix was just to drop the const from the declaration. The vast majority is just precautionary

    - for (const auto &c : std::as_const(m_connections))
    + for (auto &c : m_connections)
          QObject::disconnect(c);

In anticipation of a deprecation of the const overload. If you would like compiler help in finding affected code, apply the patch from https://codereview.qt-project.org/c/qt/qtbase/+/724503/4/src/corelib/kernel/qobject.h to qobject.h (only the header, the .cpp file is just comments). You do not need to patch your production Qt. You only need to install this patch on a developer machine, or the CI, and fix the deprecated calls. The resulting executable will be forward and backward compatible with the unpatched Qt.

Sorry for the annoyance, and for failing to detect the issue sooner, but this is really only fixable at the user side.

Please help spread the word!

Thanks,
Marc


--
Marc Mutz <marc.mutz at qt.io><mailto:marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io<http://www.qt.io>

Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

Public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260326/8b60c50b/attachment.htm>

From thiago.macieira at intel.com  Thu Mar 26 21:39:09 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 26 Mar 2026 13:39:09 -0700
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
In-Reply-To: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
References: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
Message-ID: <2153614.b9uPGUboIS@tjmaciei-mobl5>

On Thursday, 26 March 2026 11:41:38 Pacific Daylight Time Marc Mutz via 
Development wrote:
> If you pass const objects _originally marked as const_ (e.g. the key of a
> std::map, or an object you declared const yourself:
> 
>     const auto c = QObject::connect(~~~~);
>     ~~~~
>     QObject::disconnect(c); // UB!!
> 
> Then you need to take action: make the Connection object _not_ originally
> const. 

By "need", understand "at your convenience". This is UB, but we have not found 
any compiler that uses this to optimise things nor do we expect that to happen 
soon. So if your code appears to works in spite of the UB, there's no reason 
to suspect it's actually broken.

If you are upgrading your compilers, I agree with Marc: apply the trivial fix.

> In the case above, do
> 
>     auto c = QObject::connect(~~~~); // NOT const!
> 
> if you don't control the declaration (e.g. its a key in a std::map), then DO
> NOT CALL disconnect() on it. Take a copy and call disconnect() on that:
> 
>    const c = QObject::connect(~~~~); // can't change this even if I tried
>    ~~~~
>    auto copy = c; // take a copy
>    QObject::disconnect(copy); // and only disconnect() the copy

Anyone reading this is going to ask why we can't apply this fix ourselves, by 
taking a copy.

The point is not whether we disconnect or not. As Marc said:

> The connection will be disconnected either way, it suffices if any of the
> copies of the Connection gets passed to disconnect()

The discussion is on how early we can free memory.

> Patch your code, and pick to all your branches.

At least to ones where you may compile with future compiler versions. If 
you're locked to a particular compiler, see above.

> Sorry for the annoyance, and for failing to detect the issue sooner, but
> this is really only fixable at the user side.

The code has been around since 2012. If in 14 years no one had noticed the 
problem, no compiler was taking advantage of the UB to optimise.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260326/a5583c6f/attachment-0001.bin>

From giuseppe.dangelo at kdab.com  Fri Mar 27 02:16:26 2026
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Fri, 27 Mar 2026 02:16:26 +0100
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
In-Reply-To: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
References: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
Message-ID: <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>

Hi,

Il 26/03/26 19:41, Marc Mutz via Development ha scritto:
> Hi,
> 
> We Qt developers cannot figure out how to proceed from here, so let me 
> give you a heads-up here, so you can take matters into your own hands.
> 
> TL;DR: never pass Connection objects originally declared const to 
> QObject::disconnect(Connection).
> 
> The function const_cast<>s away the const of the argument to reset the 
> d_ptr to nullptr. It doesn't matter why, suffice to say that it's not 
> trivial to fix either way on the Qt side.

To be honest, I don't understand the alarmism of this email. There's a 
bug in Qt; and we fix bugs all the time. The impact of this particular 
bug is between miniscule and non-existent.


And I disagree, the bug *is* completely trivial to fix: we can make the 
affected member as `mutable`. The only reason the patch wasn't +2 
already on Gerrit was for the commit message that talked about impending 
deprecations (when there's strong disagreement around it).


If we follow what I consider an extremely speculative line of reasoning, 
and conclude that the bug might be manifesting itself in inline code, 
then there's no solution: people have to update Qt _and_ recompile, 
which is always the case when there's a bug in inline code.

If we reject that line of reasoning (and I do, see below), then it's 
sufficient that people update Qt (UB happens in out-of-line code) and 
they'll get the fix.

In any case the "avoid passing const objects to disconnect()" is there 
as a workaround for those who can recompile their code, but can't 
upgrade Qt. Maybe it can become a gated Clazy check.
But I doubt anyone will listen; their code works completely fine today 
as their compiler doesn't do anything wrong, and they'll never upgrade 
their toolchain without also upgrading Qt.


I don't get why we disagree on such a simple fix that works, can be 100% 
safely cherrypicked in all the open branches, and completely preserves 
behavior (incl. no soft-leaks); and instead we are now researching 
extremely more invasive solutions, including possible deprecations of a 
15-20 years old API for a purely theoretical problem, deprecation which 
requires fixes in all our repositories and will just annoy the heck out 
of our users.


--


Now, the gritty details:

The bug is: there's UB happening in an out of line function. We 
const_cast away an object and mutate it; if the object was originally 
marked as const, that's formally UB.

As many people associate "UB" with "segfault", I need to clarify: NO, 
the program does not crash; it does not write into arbitrary memory / 
readonly memory; it does not trigger sanitizers or anything of the sorts.

In fact, programs work just fine, as demonstrated by the fact that this 
issue is some ~14 years old and we noticed only now (and not because we 
got bug reports: we detected the issue by reading the sources).


I'll state it again:

* the UB happens in out of line code (inside QObject::disconnect(const 
QMetaObject::Connection &)).

* the declaration of a QMetaObject::Connection object as `const` happens 
in client code;

* therefore, compilers do NOT normally see both the const_cast mutating 
the object and original object declared as const, detect UB, and do evil 
things based on the presence of UB. LTO or similar technology would be 
necessary for the compiler to even be able to do this kind of reasoning. 
This firewalling alone reduces the possibility of things going horribly 
wrong to infinitesimally small quantities.

* but even without firewalling, no optimizing compiler we support today 
detects or exploits UBs in const_cast; even when they're "blatant". If 
the Big Three don't optimize on this I reject the notion that "some 
other compiler out there might do it". "Some other compiler we don't 
know about (and therefore DO NOT support)" isn't a starting point.

* I also reject the notion of "what about compilers of tomorrow". People 
who upgrade compilers also upgrade Qt.

* Finally, what *might* be happening (which makes this an issue in 
"inline code", see the discussion above) is that a compiler doesn't 
reload QMetaObject::Connection's data members because the object was 
originally declared `const`.

A sequence like:

   const QMetaObject::Connection c = QObject::connect(~~~);
   assert(c);     // #1
   disconnect(c); // const_cast in here
   assert(c);     // #2

in #1 and #2 touches an inline code path (operator bool()) which loads 
c.d_ptr. An optimizing compiler might read c.d_ptr on #1, and not 
re-read it on #2 (that is, re-use the value read on #1), despite the 
fact that disconnect() call in principle has changed it.

And again major compiler actually does this today:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318
https://github.com/llvm/llvm-project/issues/160441



So, all in all: this a problem that has zero impact, and we're creating 
a  meteor-size blast radius (deprecation, users annoyed, code to be 
ported, documentation, best practices) ... for what gain exactly?


> In anticipation of a deprecation of the const overload. 

I still reject this idea. It *works* but it's just not worth the hassle.


My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/022c3a01/attachment.bin>

From marc.mutz at qt.io  Fri Mar 27 08:40:43 2026
From: marc.mutz at qt.io (Marc Mutz)
Date: Fri, 27 Mar 2026 07:40:43 +0000
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
In-Reply-To: <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>
References: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
 <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>
Message-ID: <104f6002-753d-4c3c-b0f1-07544f2f2c61@qt.io>

Hi again,

So you see how  we can't agree... ;)

Absence of proof is not proof of absence.

We don't know what users do out there in the field. All we know is a) the behaviour of the function as of now and b) that if you pass objects originally marked as const, that's UB, according to the standard.

We specifically do not know, whether passing const objects actually does "something", we also do not know whether users can upgrade their Qt to receive any of the two other proposed fixes (mutable or not nulling d_ptr). Finally, we do not know whether re-adding the "soft-leak" that nulling the d_ptr plugs is going to hurt anyone out there. We can speculate, e.g., that, since disconnect() already cleaned up, users may just free() a buffer of Connection objects instead of running their destructors, turning a "soft" into a "hard" leak.

But all that are speculations. Users to this, compilers don't do that. After 14 years in the wild, at the intersection of Hyrum's and Murphy's Laws, everything we can think of happening probably does happen out there. I also wouldn't've imagined to see a QHash<const char*> ever in my life. I found several just the other week. We also thought file-static functions do not have an effect outside their TU. And then came Unity Builds (and it's not that we couldn't know - KDE has had that feature since automake times, IIRC).

     "S?! la speranza che delude sempre!" ? Turandot

That is why I prefer to stick with what we know: That not passing const objects is always fine, always was, always will be. It's guaranteed by the standard. If you follow that, you fall into the Pit Of Success. It's a trivial change, and you fix it for all the past and all the future.

As such, that patch in itself is not the fix. It's a tool for users to fix their code.

I am not saying we shouldn't add the mutable. In fact, I have a patch up, and think it's a viable mitigation strategy. But it's just another assumption: that users can upgrade their Qt. I would say that the only safe assumption to make is that _if_ users can update _anything_ in their product, that their own code is always one of these things.

Though, come to think of it, even users that cannot update anything, can at least apply the mutable patch, recompile, and see whether their product is byte-for-byte identical. If it is, then there's nothing to do, either. If there are differences, return to the start. Assumes reproducible builds, of course.

Thanks,
Marc

On 27.03.26 02:16, Giuseppe D'Angelo via Development wrote:
Hi,

Il 26/03/26 19:41, Marc Mutz via Development ha scritto:
Hi,

We Qt developers cannot figure out how to proceed from here, so let me give you a heads-up here, so you can take matters into your own hands.

TL;DR: never pass Connection objects originally declared const to QObject::disconnect(Connection).

The function const_cast<>s away the const of the argument to reset the d_ptr to nullptr. It doesn't matter why, suffice to say that it's not trivial to fix either way on the Qt side.

To be honest, I don't understand the alarmism of this email. There's a bug in Qt; and we fix bugs all the time. The impact of this particular bug is between miniscule and non-existent.


And I disagree, the bug *is* completely trivial to fix: we can make the affected member as `mutable`. The only reason the patch wasn't +2 already on Gerrit was for the commit message that talked about impending deprecations (when there's strong disagreement around it).


If we follow what I consider an extremely speculative line of reasoning, and conclude that the bug might be manifesting itself in inline code, then there's no solution: people have to update Qt _and_ recompile, which is always the case when there's a bug in inline code.

If we reject that line of reasoning (and I do, see below), then it's sufficient that people update Qt (UB happens in out-of-line code) and they'll get the fix.

In any case the "avoid passing const objects to disconnect()" is there as a workaround for those who can recompile their code, but can't upgrade Qt. Maybe it can become a gated Clazy check.
But I doubt anyone will listen; their code works completely fine today as their compiler doesn't do anything wrong, and they'll never upgrade their toolchain without also upgrading Qt.


I don't get why we disagree on such a simple fix that works, can be 100% safely cherrypicked in all the open branches, and completely preserves behavior (incl. no soft-leaks); and instead we are now researching extremely more invasive solutions, including possible deprecations of a 15-20 years old API for a purely theoretical problem, deprecation which requires fixes in all our repositories and will just annoy the heck out of our users.


--


Now, the gritty details:

The bug is: there's UB happening in an out of line function. We const_cast away an object and mutate it; if the object was originally marked as const, that's formally UB.

As many people associate "UB" with "segfault", I need to clarify: NO, the program does not crash; it does not write into arbitrary memory / readonly memory; it does not trigger sanitizers or anything of the sorts.

In fact, programs work just fine, as demonstrated by the fact that this issue is some ~14 years old and we noticed only now (and not because we got bug reports: we detected the issue by reading the sources).


I'll state it again:

* the UB happens in out of line code (inside QObject::disconnect(const QMetaObject::Connection &)).

* the declaration of a QMetaObject::Connection object as `const` happens in client code;

* therefore, compilers do NOT normally see both the const_cast mutating the object and original object declared as const, detect UB, and do evil things based on the presence of UB. LTO or similar technology would be necessary for the compiler to even be able to do this kind of reasoning. This firewalling alone reduces the possibility of things going horribly wrong to infinitesimally small quantities.

* but even without firewalling, no optimizing compiler we support today detects or exploits UBs in const_cast; even when they're "blatant". If the Big Three don't optimize on this I reject the notion that "some other compiler out there might do it". "Some other compiler we don't know about (and therefore DO NOT support)" isn't a starting point.

* I also reject the notion of "what about compilers of tomorrow". People who upgrade compilers also upgrade Qt.

* Finally, what *might* be happening (which makes this an issue in "inline code", see the discussion above) is that a compiler doesn't reload QMetaObject::Connection's data members because the object was originally declared `const`.

A sequence like:

  const QMetaObject::Connection c = QObject::connect(~~~);
  assert(c);     // #1
  disconnect(c); // const_cast in here
  assert(c);     // #2

in #1 and #2 touches an inline code path (operator bool()) which loads c.d_ptr. An optimizing compiler might read c.d_ptr on #1, and not re-read it on #2 (that is, re-use the value read on #1), despite the fact that disconnect() call in principle has changed it.

And again major compiler actually does this today:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318
https://github.com/llvm/llvm-project/issues/160441



So, all in all: this a problem that has zero impact, and we're creating a  meteor-size blast radius (deprecation, users annoyed, code to be ported, documentation, best practices) ... for what gain exactly?


In anticipation of a deprecation of the const overload.

I still reject this idea. It *works* but it's just not worth the hassle.


My 2 c,



--
Marc Mutz <marc.mutz at qt.io><mailto:marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io<http://www.qt.io>

Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

Public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/d5fc410b/attachment-0001.htm>

From announce at qt-project.org  Fri Mar 27 12:18:31 2026
From: announce at qt-project.org (List for announcements regarding Qt releases and development via Announce)
Date: Fri, 27 Mar 2026 11:18:31 +0000
Subject: [Development] [Announce] Qt Online Installer & Installer Framework
 4.11.0 released
Message-ID: <mailman.6487.1774610320.837.announce@qt-project.org>

Hi all,

we have released Qt Online Installer & Installer Framework 4.11.0! Thank you to the development team & everyone involved ?.
The blog post provides more information about the release: https://www.qt.io/blog/qt-online-installer-and-qt-installer-framework-4.11.0-released

Best regards,
Tarja Sundqvist
Release manager


Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/4f3413c1/attachment.htm>
-------------- next part --------------
_______________________________________________
Announce mailing list
Announce at qt-project.org
https://lists.qt-project.org/listinfo/announce

From announce at qt-project.org  Fri Mar 27 14:06:14 2026
From: announce at qt-project.org (List for announcements regarding Qt releases and development via Announce)
Date: Fri, 27 Mar 2026 13:06:14 +0000
Subject: [Development] [Announce] Qt 6.8.7 LTS Commercial released
Message-ID: <mailman.6489.1774616789.837.announce@qt-project.org>

Hi all,

we have released Qt 6.8.7 LTS Commercial today. Please see the blog post: https://www.qt.io/blog/commercial-lts-qt-6.8.7-released

You?ll find the list of fixes and the overview of all important changes in Qt 6.8.7 in the release note.
It is available via Qt Customer Portal (https://login.qt.io/login): in Downloads, select Product: Qt and Version: 6.8.7.
Also, the Qt for Python content is available via Qt Installer and Qt Customer Portal.

Big thanks to everyone involved!

Best regards,
Tarja Sundqvist
Release Manager



Confidential
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/dad1b85c/attachment.htm>
-------------- next part --------------
_______________________________________________
Announce mailing list
Announce at qt-project.org
https://lists.qt-project.org/listinfo/announce

From thiago.macieira at intel.com  Fri Mar 27 14:08:29 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 27 Mar 2026 09:08:29 -0400
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
In-Reply-To: <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>
References: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
 <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>
Message-ID: <5564447.OV4Wx5bFTl@tjmaciei-mobl5>

On Thursday, 26 March 2026 21:16:26 Eastern Daylight Time Giuseppe D'Angelo 
via Development wrote:
> * therefore, compilers do NOT normally see both the const_cast mutating
> the object and original object declared as const, detect UB, and do evil
> things based on the presence of UB. LTO or similar technology would be
> necessary for the compiler to even be able to do this kind of reasoning.
> This firewalling alone reduces the possibility of things going horribly
> wrong to infinitesimally small quantities.

While I agree with everything else you wrote, there is a possibility for UB in 
inline code: the move constructor, move-assignment operator, and swap()

    Connection(Connection &&other) noexcept : d_ptr(std::exchange(other.d_ptr, 
nullptr)) {}
    QT_MOVE_ASSIGNMENT_OPERATOR_IMPL_VIA_PURE_SWAP(Connection)
    void swap(Connection &other) noexcept { qt_ptr_swap(d_ptr, other.d_ptr); }

The compiler is *allowed* to assume that d_ptr did not change after the call 
to disconnect() and thus cache it outside of the object itself. So if you did 
disconnect() and then swap or move, the compiler could re-materialise the 
pointer which is now dangling. When the destructor is then called, this could 
crash.

In practice, like you said, this does not happen. Compilers do not appear to 
optimise based on the constness of the object. I've shown so experimentally 
and you've found bug reports asking that this optimisation be added.

> * but even without firewalling, no optimizing compiler we support today
> detects or exploits UBs in const_cast; even when they're "blatant". If
> the Big Three don't optimize on this I reject the notion that "some
> other compiler out there might do it". "Some other compiler we don't
> know about (and therefore DO NOT support)" isn't a starting point.

If they did exist, we'd probably be aware of this bug through bug reports. And 
the worst case scenario would be no different than any other bug: upgrade Qt to 
get a fixed version.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/a4a833ef/attachment-0001.bin>

From thiago.macieira at intel.com  Fri Mar 27 14:19:00 2026
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 27 Mar 2026 09:19:00 -0400
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
In-Reply-To: <104f6002-753d-4c3c-b0f1-07544f2f2c61@qt.io>
References: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
 <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>
 <104f6002-753d-4c3c-b0f1-07544f2f2c61@qt.io>
Message-ID: <7780540.9J7NaK4W3v@tjmaciei-mobl5>

On Friday, 27 March 2026 03:40:43 Eastern Daylight Time Marc Mutz via 
Development wrote:
> We don't know what users do out there in the field. All we know is a) the
> behaviour of the function as of now and b) that if you pass objects
> originally marked as const, that's UB, according to the standard.

No, we know more. We have 14 years of evidence of what compilers *actually* 
generate for this code. We have constraint boundaries based on what the 
compiler can see from the code. Yes it's UB, but the compiler is not 
clairvoyant and omniscient: it's a deterministic machine that produces outputs 
based on observable inputs.

See my email reply to Peppe on what I think is the only possible outcome of 
the UB. Anything else would require LTO, which then only affects QtCore (I 
don't care about static builds).

> We specifically do not know, whether passing const objects actually does
> "something", we also do not know whether users can upgrade their Qt to
> receive any of the two other proposed fixes (mutable or not nulling d_ptr).

We do know: they can at least patch. This is no different than any bug they may 
be affected by and wish to see solved. It's unreasonable to expect bugs to 
disappear when no changes are applied anywhere.

> Finally, we do not know whether re-adding the "soft-leak" that nulling the
> d_ptr plugs is going to hurt anyone out there. We can speculate, e.g.,
> that, since disconnect() already cleaned up, users may just free() a buffer
> of Connection objects instead of running their destructors, turning a
> "soft" into a "hard" leak.

That's their own bug. Buggy code is buggy and we need not consider whether we 
end up making it worse by fixing our own.

> But all that are speculations. Users to this, compilers don't do that. After
> 14 years in the wild, at the intersection of Hyrum's and Murphy's Laws,
> everything we can think of happening probably does happen out there. I also
> wouldn't've imagined to see a QHash<const char*> ever in my life. I found
> several just the other week. We also thought file-static functions do not
> have an effect outside their TU. And then came Unity Builds (and it's not
> that we couldn't know - KDE has had that feature since automake times,
> IIRC).

Unity builds should not be considered for the purposes of performance or 
quality. They are a hack and I ignore they exist. If I break them, it's SEP.

ONLY LTO matters: that's the state of the art.

> I am not saying we shouldn't add the mutable. In fact, I have a patch up,
> and think it's a viable mitigation strategy. But it's just another
> assumption: that users can upgrade their Qt. I would say that the only safe
> assumption to make is that _if_ users can update _anything_ in their
> product, that their own code is always one of these things.

I say we fix this, but we treat it as a regular ol' bug.

We have UB all the time: any null or dangling pointer dereference is UB. Those 
*have* been observed in the wild. And yet we don't create such a fuss about 
them.

> Though, come to think of it, even users that cannot update anything, can at
> least apply the mutable patch, recompile, and see whether their product is
> byte-for-byte identical. If it is, then there's nothing to do, either. If
> there are differences, return to the start. Assumes reproducible builds, of
> course.

That is the least invasive patch, indeed. But I don't know we need to go to 
those extreme efforts for "regular ol' bug".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/8c4bdd60/attachment.bin>

From giuseppe.dangelo at kdab.com  Fri Mar 27 21:16:01 2026
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Fri, 27 Mar 2026 21:16:01 +0100
Subject: [Development] HEADS UP: do not pass const objects to
 QObject::disconnect(const QMetaObject::Connection&)!
In-Reply-To: <104f6002-753d-4c3c-b0f1-07544f2f2c61@qt.io>
References: <6d151602-de71-4262-956c-71afa68f4af4@qt.io>
 <66363751-ccce-479b-b2f2-f868f16d0e6e@kdab.com>
 <104f6002-753d-4c3c-b0f1-07544f2f2c61@qt.io>
Message-ID: <aa942b13-a521-4b75-aba8-7d28f8a37c1b@kdab.com>

Il 27/03/26 08:40, Marc Mutz via Development ha scritto:
> Hi again,
> 
> So you see how? we can't agree... ;)
> 
> Absence of proof is not proof of absence.

But a great number of data points makes for an educated estimate.


> We don't know what users do out there in the field. 

What is this referring to?

If it's referring to the countless ways through which people are storing 
their Connection objects, passing them around, using them etc., then 
it's all an argument for not touching these APIs at all, nor to tell 
users to touch them. The deprecation (or, even worse, moving to a 
move-only handle) will require annoying changes, all over the place. All 
of this because we don't want to put `mutable`, and because of a bug 
with zero impact?

Or if it's referring to the fact that users might be doing sanitized / 
LTO / who knows what kind of builds and possibly trampling into a 
manifestation of this UB? Because this claim isn't backed up by data. We 
know compilers aren't exploiting this UB.

And this doesn't mean we should clearly fix any gratuitous UB we find in 
Qt. We should and must. And in this case the complete fix is to add 
`mutable`. Emphasis on "gratuitous", because Qt is actually full of UB 
that we chose to actively exploit.


> All we know is a) 
> the behaviour of the function as of now and b) that if you pass objects 
> originally marked as const, that's UB, according to the standard.
> 
> We specifically do not know, whether passing const objects actually does 
> "something", we also do not know whether users can upgrade their Qt to 
> receive any of the two other proposed fixes (mutable or not nulling 
> d_ptr). 

Sorry, but I reject this argument. *IF* we have a bug in inline code 
(and I disagree we have one), we fix the bug and tell users to upgrade, 
and that unfortunately they have to recompile to get the fix. This has 
nothing to do with the quality of this specific bug: any bug in inline 
code requires a recompilation.

Any other bug, requires an upgrade but not a recompilation.

But it's not realistic to expect a bug to be fixed without doing 
anything at all.


Also we don't send out emails unless the bug has a provable impact. All 
indications of this bug point to the fact that there's NO impact. Why 
are we being alarmist for this one specifically?


Finally, for those who can't upgrade and recompile, we might offer 
mitigation measures, but
1) we're in no way obligated to do so, and
2) could be as hacky as we like, including an unsupported patch that we 
don't intend to apply to trunk, ever.

If users can't upgrade their libraries, they'll have to live with bugs 
in those libraries, and it's not arrogant to state so.


> Finally, we do not know whether re-adding the "soft-leak" that 
> nulling the d_ptr plugs is going to hurt anyone out there.

There's no need to go there, `mutable` is the complete fix.

> 
> But all that are speculations. Users to this, compilers don't do that. 

It's not a speculation when it's backed by evidence: people have asked 
compilers to do the optimization we're afraid might be happening in 
inline code. Compiler authors acknowledged that it's a legit request, 
and that they're not doing this optimization right now.


> As such, that patch in itself is not the fix. It's a tool for users to 
> fix their code.

But then there's no need to be alarmist. We make the `mutable` fix and 
just publish a tiny PSA -- if you can't upgrade Qt, here's a workaround 
for you. And we don't require any other change by anyone else going 
forward, especially we don't deprecate such an API without good 
motivation for it?


My 2 c,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/336e51e4/attachment.bin>

