[Development] Preparing for Qt 6.8 feature freeze: whatsnew68, QT_TECH_PREVIEW_API

[Volker Hilsheimer via Development]

Hi all,

It’s still a few weeks to go until we have Qt 6.8 feature freeze, and a quick 
grep for `\since 6.8` tells me that a bunch of goodness has already landed.

However, the whatsnew68.qdoc document is still a bit empty. I’ve now pushed a 
change that adds missing section etc to 
https://codereview.qt-project.org/c/qt/qtdoc/+/560438

As with the last releases, please edit that change, ideally directly in the 
gerrit UI rather than with a local fetch/edit/push roundtrip*, to add your 
things. This avoiding conflicts when many of us are adding content to the same 
file.


I expect that we will move several APIs out of technology preview that were 
introduced as technology previews in Qt 6.6 or 6.7. To make the header review 
for such changes clearer (i.e. make it visible to us that an API that was in 
tech preview is now stable, but also that a new API is under tech preview), it 
might help to now retroactively add the QT_TECH_PREVIEW_API attribute to APIs 
in Qt 6.7 that are moving out of tech preview. This way we see that change when 
comparing the 6.7 branch to 6.8.

The QT_TECH_PREVIEW_API attribute was added by Peppe in 
https://codereview.qt-project.org/c/qt/qtbase/+/541498 with explanation on how 
to use it.
In https://codereview.qt-project.org/c/qt/qtbase/+/559747 I‘ve retrofitted the 
attribute to a few JNI APIs that were added for Qt 6.7 to public headers, but 
are not documented yet. Once I’m done with adding the documentation, the 
attribute can be removed and the API moves out of tech preview, which then the 
diff between 6.7 and 6.8 should show, helping header reviewers.

And if you want to start with reviewing changes to our public API: 
https://codereview.qt-project.org/q/hashtag:%22needs+api-review_6.8%22+status:merged
 is a list of changes that our new machine overlords have analysed (sometimes 
wrongly) to have API impact.

Volker

* unless you use gpush from qtrepotools, which avoids that you overwrite 
someone else’s patch set

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer via Development]

On 8 May 2024, at 13:14, Juha Vuolle  wrote:

Hi, sorry for just kind of resetting the thread, but we had a quick
discussion with Marc and Tor Arne.

There's an additional constraint that, at least on iOS/macOS, that the
OS/platform callback mechanisms depend on UI libraries (AppKit and
UIKit).
While making that work in QtCore could *maybe* technically be
possible, it'd just add to the effort and risk we'd be talking about
here.

Hence a concrete suggestion with a few specific questions.

Thing 1) In Qt 6.8 we'll add a QtGui dependency to QtNetworkAuth
module. With this the new Qt 6.8 features will work.
Thing 2) This QtGui dependency will be behind a Qt feature flag.
Thing 3) Later in Qt 6.9+, if the three QDS functionalities become
available via QtCore, then QtNetworkAuth drops the QtGui dependency.
IIUC dropping a private linkage shouldn't cause "transitive" problems.
The main questions:
Question 1) Do we foresee problems on introducing a Gui dependency to
QtNetworkAuth?
Question 2) Do we foresee problems in possibly later dropping the Gui
dependency?


Given all the information, that approach sounds sensible.

Adding Qt Gui as a dependency to QtNetworkAuth shouldn’t be a problem, 
especially if it’s possible to opt out, and as long as it’s documented in the 
ChangeLog that application using QtNetworkAuth now need to deploy Qt Gui as 
well. We added that kind of dependency when we linked Qt TextToSpeech against 
Qt Multimedia (see discussion at 
https://lists.qt-project.org/pipermail/development/2023-January/043562.html).

And I can’t foresee a problem with later on dropping that dependency.

One thing to consider is whether you need a QGuiApplication instance for things 
to work. If things can’t work across platforms if the application only gives 
you a QCoreApplication instance, then it might be possible to add some virtual 
function(s) to QCoreApplicationPrivate that you can call from QtNetworkAuth to 
enable the implicit OAuth flow handling only if GUI is alive. Then things will 
degrade gracefully if QtGui is not initialized. We have some similar approaches 
to trigger Qt Widgets specific behaviors from Qt Gui classes 
(QGuiApplicationPrivate::closeAllPopups, for instance, or even 
createActionPrivate/createShortcutPrivate).

Volker



ke 8. toukok. 2024 klo 12.51 Volker Hilsheimer via Development
(development@qt-project.org) kirjoitti:



On 8 May 2024, at 07:32, Marc Mutz via Development  
wrote:

On 07.05.24 18:46, Volker Hilsheimer wrote:

In the long run, a mechanism in Qt Core makes sense, IMHO. That “it’s a 
browser” is not true for every possible call of the QDesktopServices API.


We need something _now_ for QtNetworkAuth, though. What do these options mean 
for OAuth support in QtNetworkAuth (my attempt at an analysis below).



I question that. QtNetworkAuth’s 
QOAuth2AuthorizationCodeFlow::authorizeWithBrowser signal is perfectly usable 
by users, as long as they are either willing to use Qt GUI, or to write their 
own handler code (possibly inspired but what we have in Qt Gui).


However, whether a new QCoreDesktopServices namespace becomes public QtCore API 
or not in Qt 6.8 is somewhat irrelevant as long as it doesn’t do anything on 
any platform. The QPA infrastructure in general, and the implementations of 
QPlatformServices in particular is -as of now - not loaded by an application 
that doesn’t use QtGui. And we haven’t even started discussing if and how we’d 
like to make that happen. I do not anticipate that we will get that 
infrastructure into Qt Core in time for the Qt 6.8 feature freeze in three 
weeks; while it’s probably not rocket science to write the code, there are 
evidently too many disagreements on (and probably several devils in) the 
details.


We have a template for this: the permission API. It's a) in QtCore and also 
highly platform-dependent. I also, honestly, don't see the extraction of the 
non-Gui code from the QPAs into some QtCore files or plugin as something 
subject to feature freeze. It's kinda cleanup under the hood. Certainly we 
can't argue that moving the implementation as private API is ok post-FF, but 
moving the interface as public API now and moving the implementation as private 
implementation detail post-FF is not, can we?


The point of feature freeze is that we start stabilizing the release.

Moving large chunks of code around, while not forbidden explicitly, doesn’t 
move us to that end.


I can see two options:

1) we leave it entirely to the application to implement a Core-only equivalent 
of QDesktopServices

Not fun, but not impossible either, esp given that whoever needs this can take 
our existing code. We could even have that code in an example, at least for 
some platforms. This doesn’t invalidate the improved OAuth support in 6.8, esp 
if we assume that the vast majority of users today will use Qt Gui anyway, and 
that Qt Core only use cases are rare enough to deal with the alternative.


AFAICT, this means one of the

Re: [Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer via Development]

On 8 May 2024, at 07:32, Marc Mutz via Development  
wrote:

On 07.05.24 18:46, Volker Hilsheimer wrote:
In the long run, a mechanism in Qt Core makes sense, IMHO. That “it’s a 
browser” is not true for every possible call of the QDesktopServices API.

We need something _now_ for QtNetworkAuth, though. What do these options mean 
for OAuth support in QtNetworkAuth (my attempt at an analysis below).


I question that. QtNetworkAuth’s 
QOAuth2AuthorizationCodeFlow::authorizeWithBrowser signal is perfectly usable 
by users, as long as they are either willing to use Qt GUI, or to write their 
own handler code (possibly inspired but what we have in Qt Gui).


However, whether a new QCoreDesktopServices namespace becomes public QtCore API 
or not in Qt 6.8 is somewhat irrelevant as long as it doesn’t do anything on 
any platform. The QPA infrastructure in general, and the implementations of 
QPlatformServices in particular is -as of now - not loaded by an application 
that doesn’t use QtGui. And we haven’t even started discussing if and how we’d 
like to make that happen. I do not anticipate that we will get that 
infrastructure into Qt Core in time for the Qt 6.8 feature freeze in three 
weeks; while it’s probably not rocket science to write the code, there are 
evidently too many disagreements on (and probably several devils in) the 
details.

We have a template for this: the permission API. It's a) in QtCore and also 
highly platform-dependent. I also, honestly, don't see the extraction of the 
non-Gui code from the QPAs into some QtCore files or plugin as something 
subject to feature freeze. It's kinda cleanup under the hood. Certainly we 
can't argue that moving the implementation as private API is ok post-FF, but 
moving the interface as public API now and moving the implementation as private 
implementation detail post-FF is not, can we?

The point of feature freeze is that we start stabilizing the release.

Moving large chunks of code around, while not forbidden explicitly, doesn’t 
move us to that end.


I can see two options:

1) we leave it entirely to the application to implement a Core-only equivalent 
of QDesktopServices

Not fun, but not impossible either, esp given that whoever needs this can take 
our existing code. We could even have that code in an example, at least for 
some platforms. This doesn’t invalidate the improved OAuth support in 6.8, esp 
if we assume that the vast majority of users today will use Qt Gui anyway, and 
that Qt Core only use cases are rare enough to deal with the alternative.

AFAICT, this means one of the following:

a) that we have to postpone QtNetworkAuth until new QtCore API is added,
provided that any future intents/activities API actually pertains to and
supports implementation of what OAuth needs. Danger of "the perfect is
the enemy of the good" here.


Depending on Qt Gui might not be perfect, but it’s good enough for the vast 
majority of users.


b) that QtNetworkAuth gets the undesired QtGui dependency, which becomes
stale once new Core API is merged, but then has to be carried along for
BC reasons.

QtNetworkAuth doesn’t have to link against Qt Gui. The application does. Qt 
NetworkAuth emits a signal, the application handles that.

Or do I misinterpret what 
https://code.qt.io/cgit/qt/qtnetworkauth.git/tree/examples/oauth/redditclient/redditwrapper.cpp#n28
  (which is the example you referred to a few days ago) is doing and how that 
relates to how things should be done in the future with new and improved Qt 
NetworkAuth?

Maybe it’s time to point at what new and improved Qt NetworkAuth we are talking 
about… maybe it’s https://codereview.qt-project.org/c/qt/qtnetworkauth/+/556023?


c) that the user has to connect the pieces of the flow together
manually. The whole point of the code there is to _implement_ the flow,
though.


Thanks for finally sharing that bit of information :)

Up to now and based on the discussion here, my assumption was not that we 
replace the responsibility of the application developer (as exemplified by the 
quoted redditclient example) with a baked-in workflow implementation that 
handles redirects etc.


2) we put a copy of our implementations into Qt Network, without any public API

It could (but doesn’t have to) be a Qt Network specific plugin, and if that 
plugin exists then we use the implementation in it automatically whenever we’d 
emit QOAuth2AuthorizationCodeFlow::authorizeWithBrowser. We could add a 
property of QOAuth2AuthorizationCodeFlow to “useDefaultBrowser” to enable that 
(and one future day, setting that property will automatically make it go 
through our new public API instead).

Option 2 is not a lot of work, with no impact on public API at this point, 
while enabling a good out-of-the-box usability of the new OAuth support. The 
drawback is that we have a duplicate a bunch of code (or find a way to build 
the relevant sources twice), the most of which seems to be in the Xcb QPA 
plugin (and not all of 

Re: [Development] Stepping down as a maintainer of Qt OPC UA

[Volker Hilsheimer via Development]

I’ve now updated the list of maintainers [1] with this change.

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


Thanks again Frank for your contributions to Qt OPC UA, for thank Jannis for 
taking over!

Cheers,
Volker



> On 23 Apr 2024, at 13:16, Frank Meerkötter  
> wrote:
>
> Hi qt-devel,
>
> I am going to step down as the maintainer of Qt OPC UA. I have not been very 
> active recently.
>
> I would like to nominate Jannis Völker  as the 
> new maintainer.
>
> https://codereview.qt-project.org/q/owner:jannis.voel...@basyskom.com
>
> Jannis is the most active contributor to the module. He also has been the 
> de-facto maintainer of Qt OPC UA for a while now. He is an active contributor 
> to the open62541-stack (which is used internally in Qt OPC UA).
>
> Regards,
> Frank
>
> --
> Frank Meerkötter
> Development Lead
>
> basysKom GmbH
> Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
> Tel: +49 6151 870 589 - 161 | Fax: -199
> frank.meerkoet...@basyskom.com | http://www.basyskom.com/
>
> Handelsregister: Darmstadt HRB 9352
> Geschaeftsfuehrende Partner: Heike Ziegler, Alexander Sorg
>
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer via Development]

> On 7 May 2024, at 17:51, Marc Mutz via Development 
>  wrote:
>> 
>> It doesn't change the technical roadblock: you *cannot* *move*
>> QDesktopServices. The best you can do for API is add a new one.
> 
> I'm pretty sure REMOVED_SINCE + an inline namespace around the Core 
> version would enable actual moving, but since I had read and understood 
> this argument before, I've implemented it under a different name now:
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/559958
> 
>> So I'd like an argument why it needs to be separate from QDesktopServices 
>> when
>> we already have that and cannot remove it until Qt 7.
> 
> It's technically separate, for BC reasons, but I wouldn't want to think 
> of it as new API. It's the old API, moved to QtCore. If you insist, I 
> can make it SC (REMOVED_SINCE + inline namespace).
> 
>> And I'd like an argument
>> why the API should be in QtCore, as opposed to QtNetwork (it's a browser 
>> after
>> all).
> 
> QtGui would gain a dependency on QtNetwork, or we'd need to duplicate 
> the implementation. QtCore is the common ancestor of both QtNetworkAuth 
> and QtGui. That's the technical argument.
> 
> The logical argument is that a) QUrl itself and b) QMimeTypeDatabase, 
> which co-determines which program to run on openUrl(), are both in 
> QtCore, so it makes sense that openUrl() would be, too.
> 
> Thanks,
> Marc


In the long run, a mechanism in Qt Core makes sense, IMHO. That “it’s a 
browser” is not true for every possible call of the QDesktopServices API.

However, whether a new QCoreDesktopServices namespace becomes public QtCore API 
or not in Qt 6.8 is somewhat irrelevant as long as it doesn’t do anything on 
any platform. The QPA infrastructure in general, and the implementations of 
QPlatformServices in particular is -as of now - not loaded by an application 
that doesn’t use QtGui. And we haven’t even started discussing if and how we’d 
like to make that happen. I do not anticipate that we will get that 
infrastructure into Qt Core in time for the Qt 6.8 feature freeze in three 
weeks; while it’s probably not rocket science to write the code, there are 
evidently too many disagreements on (and probably several devils in) the 
details.

I can see two options:

1) we leave it entirely to the application to implement a Core-only equivalent 
of QDesktopServices

Not fun, but not impossible either, esp given that whoever needs this can take 
our existing code. We could even have that code in an example, at least for 
some platforms. This doesn’t invalidate the improved OAuth support in 6.8, esp 
if we assume that the vast majority of users today will use Qt Gui anyway, and 
that Qt Core only use cases are rare enough to deal with the alternative.

2) we put a copy of our implementations into Qt Network, without any public API

It could (but doesn’t have to) be a Qt Network specific plugin, and if that 
plugin exists then we use the implementation in it automatically whenever we’d 
emit QOAuth2AuthorizationCodeFlow::authorizeWithBrowser. We could add a 
property of QOAuth2AuthorizationCodeFlow to “useDefaultBrowser” to enable that 
(and one future day, setting that property will automatically make it go 
through our new public API instead).


Option 2 is not a lot of work, with no impact on public API at this point, 
while enabling a good out-of-the-box usability of the new OAuth support. The 
drawback is that we have a duplicate a bunch of code (or find a way to build 
the relevant sources twice), the most of which seems to be in the Xcb QPA 
plugin (and not all of that might be relevant if we want to support a 
QtCore-only-app-on-GUI-less-system scenario).


If I was paying y’all’s salary, then I’d strongly suggest to go with option 1, 
and maybe follow up with Option 2 for 6.9, while we take the time it takes to 
figure out how to properly wrap intents etc into a cross-platform abstraction.


Volker

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

Re: [Development] Stepping down as a maintainer of Qt OPC UA

[Volker Hilsheimer via Development]

> On 23 Apr 2024, at 14:06, Marc Mutz via Development 
>  wrote:
>
> Hi Frank,
>
> On 23.04.24 13:16, Frank Meerkötter wrote:
>> I am going to step down as the maintainer of Qt OPC UA. I have not been
>> very active recently.
>
> Thanks for your work on QtOpcUa over the years!
>
>> I would like to nominate Jannis Völker  as
>> the new maintainer.
>>
>> https://codereview.qt-project.org/q/owner:jannis.voel...@basyskom.com
>>
>> Jannis is the most active contributor to the module. He also has been
>> the de-facto maintainer of Qt OPC UA for a while now. He is an active
>> contributor to the open62541-stack (which is used internally in Qt OPC UA).
>
> +1
>
> Jannis seems to be on top of the module, AFAICT.


+1, and thanks to both Frank and Jannis!


> BUT: I've never met Jannis in person, so maybe Eva or other C-suite people 
> from basyskom can confirm that this isn't going to be an xzlib-like 
> situation? E.g. there's no Jannis on https://www.basyskom.de/ueber-uns/ :)
>
> Thanks, and sorry for caution,
> Marc


Jannis is already approver, so he already has all the privileges as far as 
source code access is concerned. If we want to start doing background checks 
(and that’s a worthwhile discussion to have), we’d have to do so when 
nominating approvers, wouldn’t we?

Volker


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

Re: [Development] RFC: New keyword for Fixes bot "Reopens" and revert detection

[Volker Hilsheimer via Development]

On 15 Apr 2024, at 12:36, Tor Arne Vestbø via Development 
 wrote:



On 15 Apr 2024, at 12:07, Daniel Smith via Development 
 wrote:

I'd like to open up a thread for discussion on the addition of a new commit 
message footer, "Reopens", related to Fixes/Task-Number.

The proposed behaviour is:

  *
Use of "Reopens: QTBUG1234" would trigger automatic reopening of the specified 
jira issue upon uploading a new change to codereview.
  *
Jira issues specifying Reopens would be tagged with the merged sha of the 
change.
  *
Issues specifying Reopens can be automatically closed by also specifying 
"Fixes" as usual.
 *
The Jira Closer Bot has traditionally refused to close issues which is has 
previously closed. Including Reopens would bypass this check and allow the 
issue to be closed with the presence of Fixes.

Is this really such an often occurrence that we need a keyword for it? If you 
know that it invalidates a fix for an existing QTBUG, re-opening manually seems 
like a pretty small task.

For reverts of commits with “Fixes” in them it should be fine to re-open the 
bug. And to close it again once a new commit lands with Fixes.  The bot should 
be able to tell by the “author” of the status change in JIRA if it’s okey to 
re-close it, no?

Is the motivation here primarily to allow the bot to re-close the issue later 
on, even for non-reverts changes? How about we just trust the “Fixes” in the 
change, and close the issue, even if it was previously re-opened?

Cheers,
Tor Arne


The difference between a new “Reopens:” footer and a manual reopening is that 
code review can catch and look out for the former, but not the latter. So 
that’s good: if we know that a reverting patch brings back the bug, then we 
want to make sure that the ticket gets reopened again. And if we don’t know, 
then the committer explicitly pointing out that by reverting this change we 
might bring back what might be a nasty bug might be useful information.

This could even be caught by a sanity bot - not as a -1, but as a note pointing 
out that the commit reverts a change that previously closed a ticket, hinting 
that perhaps the ticket should be reopened.

So I think this addition would be a useful workflow improvement.

Volker


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

Re: [Development] Nominating Hatem ElKharashy for maintainership of Qt Svg

[Volker Hilsheimer via Development]

> On 13 Mar 2024, at 09:15, Eskil Abrahamsen Blomfeldt via Development 
>  wrote:
> 
> Hi,
> 
> I would like to nominate Hatem ElKharashy for maintainership of the Qt Svg 
> module. This module currently does not have any active maintainer, but it has 
> been part of my team's responsibility and backlog within The Qt Company.
> 
> Hatem has recently been working on adding support for new SVG features in Qt 
> Svg, as well as fixing bugs and greatly improving the test coverage in the 
> module. I think he is a great candidate to take on the maintainership of this 
> module.
> 
> Authored changes:
> https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io
> 
> Reviewed hanges:
> https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io
> 
> --
> Eskil Abrahamsen Blomfeldt


Hatem is now listed as maintainer for Qt SVG on 

https://wiki.qt.io/Maintainers

Congratulations Hatem, and thanks for stepping up!

Volker

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

Re: [Development] Playground Request: ClapInterface

[Volker Hilsheimer via Development]

Looks good, go ahead with creating the JIRA ticket in QTQAINFRA as per 
https://wiki.qt.io/Requesting_New_Repositories

Cheers,
Volker


> On 22 Mar 2024, at 11:10, Dennis Oberst via Development 
>  wrote:
> 
> Hello,
> 
> After some further thought and discussion, I have arrived at the following:
> 
> Project name: qtcleveraudioplugin
> Description: "Qt Integration with the CLever Audio Plugin standard"
> Namespace: QtClap
> Responsible persons: Dennis Oberst
> 
> I will not import existing history.
> 
> If there are any opinions or questions, please speak up.
> 
> best,
> 
> Dennis
> 
> 
> Dennis Oberst
> Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> 12489 Berlin, Germany
> dennis.obe...@qt.io
> https://www.qt.io
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> 
> From: Development  on behalf of Dennis 
> Oberst via Development 
> Sent: Tuesday, March 19, 2024 12:12 PM
> To: Jean-Michaël Celerier ; Volker Hilsheimer 
> 
> Cc: development@qt-project.org 
> Subject: Re: [Development] Playground Request: ClapInterface
>  Hey,
> 
> Indeed, there is some ambiguity involved with "CLAP". There is also the Rust 
> crate "clap", which is a CLI parsing tool (https://github.com/clap-rs/clap). 
> However, I would expect that any interested soul would read the README or 
> docs where we would resolve the whole ambiguity. Also the word wouldn't be 
> there on it's own as it would be a part of the namespace that we apply to the 
> contained classes, e.g.: QClapNote, QClapParameter.
> 
> I agree with you, Volker, that 'Interface' is not accurate. What would be 
> more fitting is the name 'Client,' since it's the client-side implementation 
> of the gRPC API provided by clap-rci. Note that 'rci' stands for 'Remote 
> Control Interface'. I'm not a fan of spelling it out since it will become too 
> lengthy in code: QCleverAudioPluginClient or QCleverAudioPluginInterface. 
> What about:
> 
> Project name: qtclapclient
> Description: "Qt Integration with the CLever Audio Plugin standard"
> Namespace: QClap
> 
> In its current (naive) form, it consists of:
> 
> - ClapControls: specialized and new controls (Dials, NoteKeys) that are 
> typically required for building audio plugins.
> - ClapInterface: communication with the server-side through QtGrpc.
> 
> So we would have the QClapControls (or perhaps later QClapQuick) and 
> QClapClient.
> 
> As pointed out by Jean-Michaël:
> 
> > (It's) a recurrent topic in audio conferences and circles.
> 
> It's establishing itself in the audio-industry and is currently a hot topic 
> running under the name 'clap'. Any deviation would generate confusion. We 
> could think about a more general name like "qtaudioplugin", since CLAP also 
> provides wrappers to many other audio plugin formats (VST3, AU ...) but I'm 
> not sure I like that. Given that it's part of a prefix here it appears to be 
> fine for me.
> 
> Best,
> 
> Dennis
> 
> 
> Dennis Oberst
> Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> 12489 Berlin, Germany
> dennis.obe...@qt.io
> https://www.qt.io
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> 
> From: Jean-Michaël Celerier 
> Sent: Monday, March 18, 2024 9:44 PM
> To: Volker Hilsheimer 
> Cc: Dennis Oberst ; development@qt-project.org 
> 
> Subject: Re: [Development] Playground Request: ClapInterface
>  You don't often get email from jeanmichael.celer...@gmail.com. Learn why 
> this is important
> As someone involved in the audio ecosystem, the Clap plug-in API is quickly 
> becoming an industry standard, 
> is now supported by multiple digital audio workstation software (Reaper, 
> Bitwig, qtractor) and a recurrent topic in audio conferences and circles.
> It has its own wikipedia page: 
> https://en.wikipedia.org/wiki/CLever_Audio_Plug-in
> 
> - 12 pages of products using CLAP on KVR: 
> https://www.kvraudio.com/plugins/the-newest-plugins/clap-plugins - 
> https://github.com/free-audio/clap
> - https://u-he.com/community/clap/
> - https://lwn.net/Articles/893048/
> - https://www.sweetwater.com/insync/clap-the-new-clever-audio-plug-in-format/
> - https://www.martinic.com/en/blog/clap-audio-plugin-format
> - https://bedroomproducersblog.com/2022/08/29/clap-plugin-format/
> 
> 
> Never heard of the other one.
&g

Re: [Development] Playground Request: ClapInterface

[Volker Hilsheimer via Development]

> On 18 Mar 2024, at 12:27, Dennis Oberst via Development 
>  wrote:
> 
> Hello all,
> 
> I'd like to request a new playground repository to continue the development 
> of the "Clap Interface," a client-side library that uses QtGrpc to provide 
> integration with the CLAP audio plugin standard, ultimately allowing to build 
> audio plugins with Qt user interfaces.
> 
> Description: Qt interface for the CLAP audio-plugin standard
> Project name: qtclapinterface
> 
> The Clap Interface emerged from the research concluded in my thesis, which 
> you can find and read here. As its counterpart, there is the 'clap-rci' 
> library, which provides the server-side integration. I won't go into too much 
> detail, but it works through headless audio processing and remote GUIs to 
> achieve integration with Qt. You can find it here.
> 
> Given the time constraint of 6 months for writing 2 libraries and a thesis, 
> they have some rough edges. Nevertheless, they proved my point: Qt 
> integration with audio plugins is possible! I'm currently in the process of 
> rewriting those libraries in my free time, but I would still like to have 
> this version openly available.
> 
> Suggestions/Opinions/Ideas, I take them all.
> 
> best,
> 
> Dennis

Hey Dennis,

Nice, seems like a cool use case of gRPC for building out-of-process plugins!

My knee-jerk reaction is that it might be a good idea to spell this out as 
QCleverAudioInterface, because 

https://github.com/LAION-AI/CLAP

which, while also “something audio”, is completely not related, so perhaps 
better to be verbose.

And I’m not entirely sure that “Interface” is the right word... since it seems 
to be more an integration or bridge, perhaps?

Volker

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

Re: [Development] On Removing Public Undocumented/\internal APIs

[Volker Hilsheimer via Development]

> On 13 Mar 2024, at 08:30, Marc Mutz via Development 
>  wrote:
> 
> TL;DR: Make qdoc openly document \internal members of documented 
> classes/namespaces or defined in public headers as "Internal. Subject to 
> change without notice. If you feel this function should be public, file 
> a bug report with your use-case."?


Sounds like a good idea for public and protected member functions of otherwise 
documented classes, at least to help us understand the scope of the problem, 
and perhaps trigger a CI-blocking qdoc warning to raise awareness of the 
possible breakage.

It doesn’t help with types like QObjectData and QArrayData, which are not 
documented as \internal.


> On 07.03.24 10:09, Volker Hilsheimer wrote:
>>> On 4 Mar 2024, at 10:57, Marc Mutz via Development 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> TL;DR:
>>> - Treat all APIs not clearly marked as private (private access, *Private
>>>   namespace or "We mean it!" comment) as public, in particular keep SC/BC
>>>   and deprecate before remove.
>>> - Avoid adding APIs that aren't clearly private or public in the future.
>> 
>> […]
>> 
>>> I would suggest that we treat any entity defined in a header file that
>>> is not in a *Private namespace or under the umbrella of an "We mean it!"
>>> commant, in short: anything that isn't _visible_ as non-public API _from
>>> the header file_, as semi-public, and apply the same rules as for public
>>> API: keep BC/SC, deprecate first, remove second, and adjust QUIP-6
>>> accordingly.
>> 
>> I think we have to acknowledge that Qt is 30 years old this year, and over 
>> the decades the capabilities of tools, the features of the languages, and 
>> the best practices, skills, and awareness of the people working on Qt have 
>> changed a lot. What usually hasn’t changed is the *intent* of the class 
>> author - even though it might be buried deep in the historical repositories. 
>> Stating now that everything that has the technical appearance of a public 
>> API cannot be changed, and ignoring the author’s intent, does not seem 
>> constructive.
> 
> Two users have come out and said that they think public undocumented API 
> is fair game. If there's a difference between the expectations of users 
> and expectations of API authors, do you _really- propose to pick the 
> author's?


This is not about picking sides. We have enough 
undocumented/not-designed-for-public-consumption API in public headers (but 
also not in QtPrivate or otherwise marked as internal) to establish that the 
status quo is: use undocumented API at your own risk; they might go away or 
change in arbitrary ways.

I agree that this is not as good as it could be, by today’s standards, so I’m 
happy that we are trying to find practical ways to improve.


>>> ¹ Off the top of my head: QString::isSimpleText(), QPen::data_ptr(),
>>> QDeferredDeleteEvent
>> 
>> Undocumented APIs in any SDK are, IMHO, “use at your own risk”. I (or my 
>> IDE) might find something promising in some public header, but if I have no 
>> information about what the author of that thing is promising me, should I 
>> use it in my code? Sometimes it’s more obvious than other times, but what on 
>> earth is the semantics of "QString::isSimpleText”? What is that “DataPtr” 
>> reference returned by "QPen::data_ptr”? Can anyone use 
>> QDeferredDeleteEvent::loopLevel() in a meaningful way without studying the 
>> event delivery code?
> 
> It's not for me to prove that these functions are useful or not. It's 
> for the changers and removers of these functions to prove that no-one 
> uses them.
> 
> But ok, let's see:
> 
> - the data_ptr() could be used as a null-check (there's no QPen::isNull())

There’s also no way to create a null-pen, from what I can see. Both QPen() and 
QPen(Qt::NoPen) create a pen with a valid data_ptr(). A moved-from QPen will 
have a null-data_ptr(), but calling data_ptr() on a moved-from object would 
already be UB.

> - QDeferredDeleteEvent could have been posted to an object in another 
> thread, because there was doubt as to whether deleteLater() was actually 
> thread-safe, but posting events is known to be (_I_ had to look that up 
> myself just now).


Which makes my point: to use those APIs you have to read the code. And then 
you’ll see that they are either undocumented, or documented as \internal.

You can still use them, but you know that they might change.


> I have no use-case for isSimpleText(), but what, exactly, did the Qt 
> project gain by removing it instead of deprecating it as "We have found 
> no use for this function. If you use it, please report a bug."?
> 
> The question that remains unanswered is this: Given that _we_ know how 
> to deal with change and _we_ control the changelog, why should our 
> _users_ be subjected to unannounced breaks of in-good-faith code?
> 
> There's a time for such changes: a major release. A minor release is - 
> IMHO - not a time for such changes.
> 
> We have all the tools we need to not step on our users' 

Re: [Development] Should QObject::event() be protected or public?

[Volker Hilsheimer via Development]

On 18 Mar 2024, at 14:00, Giuseppe D'Angelo via Development 
 wrote:

On 18/03/2024 13:34, André Somers wrote:
While I know it's easy to work around, I sometimes find myself doing it
anyway. To me, it signals what API is intended to be used in what way.
That a class overrides `event`  (or any other public virtual method)
does not mean that that method is then intended to be called by a user
of the class as the type you defined. That you overwrote it may just be
an implementation detail. I think the methods you expose as "public" on
an API are quite important*. They signal how the user is supposed to use
an instance of your class. If you have methods in there that are just
implementation details, then those don't fit. These methods are meant to
be called by parts of the system that don't see your type as the actual
type, but as something more basic: a QObject in this case.

But I agree 100% here; this is typically realized in C++ by having the entry 
point public and non-virtual, and have that dispatch to a protected virtual.

QObject::event() has been public since Qt 2.3 at least: 
https://doc.qt.io/archives/2.3/qobject.html

And subclasses, by and large, always had those overrides as protected, e.g. 
https://doc.qt.io/archives/2.3/qwidget.html#6ff658

Was it because the old Trolls didn’t know better, or thought it would be a 
clever way to allow some specific use cases while preventing silly mistakes? 
The non-virtual interface pattern might have been around then already, and we 
do have a public entry point to QObject::event: 
QCoreApplication::send/postEvent, both of them linked to from the documentation.

The function is also today still documented saying that it “receives events to 
an object"; the documentation doesn’t say “call this function if you want 
something to happen to the object”. Ironically, the QObject subclass in the 
snippet used also overrides event() as a public function (while the next 
snippet overrides eventFilter as a protected function).

 The whole problem we're discussing is that `event()` has been made public in 
the base class and that means it's now public API of any QObject subclass, 
whether they like it or not. :-(

People can call QObject::event, as long as they cast to, or store their pointer 
as, a QObject, and as long as they know how to construct and correctly manage 
the life time of the respective QEvent subclass instance (unless they merely 
forward an existing one). I think that’s fine. Folks have evidently managed to 
do so for the last two decades, and the amount of foot-shooting seems to have 
been manageable. Perhaps it’s ok to expect that people that jump through those 
kinds of hoops read https://doc.qt.io/qt-6/eventsandfilters.html and know what 
they are doing.

As I see it, nothing we can do to change this (make QObject::event protected, 
add a public NVI function) would improve Qt in a way that would justify the 
work. I’ll happily review a change to the documentation that fixes the snippet, 
and adds a sentence about using QCoreApplication::send- or postEvent instead, 
perhaps linking explicitly to https://doc.qt.io/qt-6/eventsandfilters.html.

Maybe at some point the C++ committee will decide that compilers should warn if 
an override is not at least as strict as the virtual declaration. I’ll stand 
corrected then.

Volker

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

Re: [Development] Should QObject::event() be protected or public?

[Volker Hilsheimer via Development]

> On 15 Mar 2024, at 12:30, Marc Mutz via Development 
>  wrote:
> On 15.03.24 09:11, apoenitz wrote:
>> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
> [...]
>>> Please note that this means that any override (and all new QObject
>>> classes should contain one, since, in case we ever need it, it might not
>>> be possible to add it after the fact) should also be public.
>> 
>> Neither is a necessary consequence, and I don't think this new rule
>> would be helpful.
> 
> I have explained this here and over in TTLOFIR. If people choose to not 
> read, or, if read, choose not to understand, or, if understood, choose 
> to not accept, there's nothing more that I can do.

I have read, but not understood, what or where “TTLOFIR” is.

>> What kind of setups do you expect where an event() override in the
>> middle of the inheritance chain needs to be called from outside to
>> warrant this rule requiring class-implementor to regularly write code
>> that's unlikely (and I claim: Never) needed?
> 
> It's not my job to argue why we should keep breaking a very general C++ 
> rule, one most C++ developers probably don't know _can_ be broken, but 
> I'll throw you a bone: qcompleter.cpp

That there exists code that calls QObject::event directly, whether because it 
can (and the author didn’t know about QCoreApplication::sendEvent), or because 
it has to (to avoid recursion when using sendEvent), doesn’t make it any less 
of a smell.

And we evidently need to have a public QObject::event so that code that must 
call it (for whatever reason) has a way to do so. Some smells have valid 
reasons to exist, and making them visible in code by requiring 

(static_cast(d->widget))->event(ke);

(unnecessary parenthesis presumably not required for it to raise eyebrows in 
code review) is a good thing.

But I still don’t see a reason why we now need to start arguing about a pattern 
that has been used in Qt quite consistently for 30 years, i.e. making overrides 
of event handlers, including QObject::event and QObject::eventFilter, protected.

Volker

PS: and indeed, just that something has been done for 30 years is not an 
argument in itself; that it’s a pattern that has worked, has been accepted, and 
has prevented mistakes however is.

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

Re: [Development] On Removing Public Undocumented/\internal APIs

[Volker Hilsheimer via Development]

> On 4 Mar 2024, at 10:57, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> TL;DR:
> - Treat all APIs not clearly marked as private (private access, *Private
>   namespace or "We mean it!" comment) as public, in particular keep SC/BC
>   and deprecate before remove.
> - Avoid adding APIs that aren't clearly private or public in the future.

[…]

> I would suggest that we treat any entity defined in a header file that 
> is not in a *Private namespace or under the umbrella of an "We mean it!" 
> commant, in short: anything that isn't _visible_ as non-public API _from 
> the header file_, as semi-public, and apply the same rules as for public 
> API: keep BC/SC, deprecate first, remove second, and adjust QUIP-6 
> accordingly.

I think we have to acknowledge that Qt is 30 years old this year, and over the 
decades the capabilities of tools, the features of the languages, and the best 
practices, skills, and awareness of the people working on Qt have changed a 
lot. What usually hasn’t changed is the *intent* of the class author - even 
though it might be buried deep in the historical repositories. Stating now that 
everything that has the technical appearance of a public API cannot be changed, 
and ignoring the author’s intent, does not seem constructive.


> ¹ Off the top of my head: QString::isSimpleText(), QPen::data_ptr(), 
> QDeferredDeleteEvent

Undocumented APIs in any SDK are, IMHO, “use at your own risk”. I (or my IDE) 
might find something promising in some public header, but if I have no 
information about what the author of that thing is promising me, should I use 
it in my code? Sometimes it’s more obvious than other times, but what on earth 
is the semantics of "QString::isSimpleText”? What is that “DataPtr” reference 
returned by "QPen::data_ptr”? Can anyone use QDeferredDeleteEvent::loopLevel() 
in a meaningful way without studying the event delivery code?

> At the same time, we should make sure that we don't accept such 
> semi-public APIs going forward anymore.

I do agree that we shouldn’t add more such stuff, at least not without making 
it visible in the header, ideally in a way that makes it visible to code 
completion (if that’s possible at all).

For stuff that is there today (e.g. various container types’ “isSharedWith” 
public member function, usually documented explicitly as \internal, and often 
used in other modules or in tests so not really practical to do it any other 
way), should we add a "// internal” comment in the header file?

Cheers,
Volker


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

Re: [Development] Nominating Dr. Máté Barany as an approver for the Qt project

[Volker Hilsheimer via Development]

On 6 Mar 2024, at 23:09, Axel Spoerl via Development 
 wrote:

Dear Colleagues,

I hereby nominate Dr. Máté Barany as an approver for the Qt project.
Máté has been a valuable contributor and reviewer, providing sound code, 
guidance and input.
As a reference, see his dashboard 
here:https://codereview.qt-project.org/dashboard/1010490

I fully trust his advice, expertise and judgement. I am certain that he will 
exercise approver rights to the benefit of the Qt project.

I am neither working in Máté's team, nor sharing an office with him.
Máté and I do know each other personally.

Kind regards
Axel


+1

FWIW, The relevant links to gerrit when nominating someone are no the current 
dashboard but:

Authored changes: 
https://codereview.qt-project.org/q/author:mate.barany%2540qt.io
Changes not authored, but reviewed: 
https://codereview.qt-project.org/q/commentby:mate.barany%2540qt.io+-author:mate.barany%2540qt.io

Volker

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

Re: [Development] Using '#pragma once' instead of include guards?

[Volker Hilsheimer via Development]

On 4 Mar 2024, at 15:56, Kai Köhne via Development  
wrote:

Hi Marc,

I've nothing against using '#pragma once' for private/internal headers.

But you said you mainly want to have this to differentiate between different 
types of headers. If this is the motivation, I think we can make this 
differentiation even more explicit. For instance, public headers could get a

  // This header is part of the public Qt API.

comment. Much like the 'We mean it', or 'pragma once', syncqt could enforce 
this for public headers, and error out if it's used for non-public ones.

Kai


I think the challenge then is again how syncqt can know what a public header 
is. How does syncqt know that src/plugins/**/*.h headers are not public 
headers? They look like public headers, except for the “plugins” in the path. 
How do we, on a build system level, distinguish between “private installed” and 
“private non-installed” headers?

In the end, syncqt can ideally rely on an explicit decision that has become 
manifest through an easily recognizable pattern in each header file. Whether we 
replace include guards with #pragma in all non-public headers, or tag all 
public headers with a comment doesn’t really matter all that much, does it?

But given that we have the “We mean it” comment already for _p.h headers, would 
it not be more consistent if we simply add that comment to all non-public 
headers (no matter their file path, and no matter whether the header is 
installed or not)? That comment makes the usability of the declarations in the 
header obvious to the reader, without having to know the rules.

We have agreed that for some headers we allow use of #pragma, but taking myself 
as a reference, I doubt that it’s obvious to everyone which headers are 
installed, and when it’s allowed to use #pragma, and when it’s mandatory to use 
#pragma. Perhaps adding the “We mean it” comment to all headers not declaring 
public API is less obscure? The question is if and how we can use syncqt to 
enforce this reliably.


Volker




From: Development  on behalf of Marc Mutz 
via Development 
Sent: Thursday, February 29, 2024 11:02
To: development@qt-project.org 
Subject: Re: [Development] Using '#pragma once' instead of include guards?

Hi,

DL;DR: Use #pragma once in all non-installed headers

The question recently came up "what is a private header". And the answer
isn't just "_p.h, of course". We have tons of headers that are "private"
without being marked as such with _p.h and "We mean it." comment.

The first realization is that there are degrees of privateness: We have
the installed private headers, and then we have non-installed/able
headers, e.g. in plugins, or tools.

So we have
- public installed headers (subject to SC and BC, syncqt and
headerscheck runs on them)
- semi-public installed headers (like above, but not subject to SC (but
BC) (_impl.h, stuff in QtPrivate namespaces, qNN, ...)
- private installed headers (not subject to SC/BC/headersclean, but
syncqt runs on them, must have "We mean it." comment)
- private non-installed headers (not subject to any constraint, not even
syncqt runs on them)

We can now look at what signs we currently have available that guide a
reader to learn which kind of header he's looking at.

For the first, we have only location in $SRCDIR.

For the second, we have _impl.h and/or "We mean it." comment.

For the third, which is easiest to distinguish, we have _p.h and "We
mean it." comment. This is enforced by syncqt, which is why we can rely
on it 100%.

For the last one, we again have just the location in $SRCDIR.

The problem is, obviously, that the first and last cases are nearly
indistinguishable and require non-local reasoning to answer.

I think we have improve on this.

With Volker's email we gave ourselves permission to use #pragma once for
"non-SDK" (= non-installed) headers, and banned it for installed
headers. So if we could make syncqt complain if a processed (=
installable) header contains #praga once, we could then flip the coin
and use an actual #pragma once as a static assertion that the header is
not installed/able.

If we do this going forward, we can then easily distinguish the four
header kinds:

- public installed headers have a traditional header guard
- semi-public installed headers ditto, except that have _impl.h suffix
or "We mean it" comment
- private installed headers ditto, _p.h suffix and "We mean it" comment
- non-installed/able headers have #pragma once

I've implemented the check in syncqt.cpp and ported xcb over, see
https://codereview.qt-project.org/q/topic:pragma-once

I'm not suggesting to do such a port for all plugins. XCB is just a test
balloon, but we might want to apply the #pragma once trick for new code
going forward.

Thanks,
Marc

On 12.10.22 12:35, Volker Hilsheimer via Development wrote:
>
>> On 11 Oct 2022, at 22:

Re: [Development] Extending qt_attribution.json files to mark provisioned components

[Volker Hilsheimer via Development]

On 4 Mar 2024, at 14:42, Kai Köhne via Development  
wrote:

Hi,

I suggest extending our qt_attribution.json format to explicitly mark 
third-party components not part of the Qt sources, like 
https://doc.qt.io/qt-6/qtmultimedia-attribution-ffmpeg.html.

QUIP-7 change:  
https://codereview.qt-project.org/c/meta/quips/+/545126?usp=search
qtattributionsscanner change: 
https://codereview.qt-project.org/c/qt/qttools/+/545098


Let me know what you think.

Regards

Kai


Commented on the review, but also here, slightly more prosaic:

Being able to document 3rd party components that are included in Qt because we 
provision and package them as part of the pipeline is a good idea. Both from an 
SBOM perspective, and because there are advantages in having a standardized, 
descriptive, machine-readable documentation of all dependencies that any Qt 
module has. The question is whether the goal is for us to mark *all* 3rd party 
components that way.

E.g. we provision, compile and link against, and then package the runtime 
libraries for FFmpeg or SQL client libraries. The provenance of those should 
clearly be documented in something less obscure than a (power)shell-script in 
qt5.git/coin/provisioning.

But what about system libraries and SDKs where we don’t ship the runtime 
(either because we expect those to be available on the target, because of 
licensing, or because we can dynamically detect the presence of the runtime and 
fail gracefully). Those SDKs might have inline functions in their headers, 
generating executable code in a Qt artefact that we do deploy. Or the tools 
that come with those SDKs might generate code that ends up compiled into Qt. So 
strictly speaking, we should list those as well, even though our Qt package 
doesn’t include any artefacts from those?


Volker

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

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

[Volker Hilsheimer via Development]

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

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

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

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

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


Volker


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

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

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

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

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

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

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

--
Vladimir

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

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

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

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

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

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

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

Re: [Development] Nominating Piotr Wierciński for approval status

[Volker Hilsheimer via Development]

+1!

Volker


On 8 Feb 2024, at 09:48, Eskil Abrahamsen Blomfeldt via Development 
 wrote:

+1 

Although I think 2013 should be 2023.

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

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

From: Development  on behalf of Morten 
Sørvig via Development 
Sent: Thursday, February 8, 2024 9:39 AM
To: development@qt-project.org 
Subject: [Development] Nominating Piotr Wierciński for approval status

I would like to nominate Piotr Wierciński for approver rights in the Qt project.

Piotr joined the Qt company early 2013 and has since then contributed to Qt for 
WebAssembly. This includes many bugfixes and also larger efforts such as 
getting tests running in the CI system.

Piotr is a pleasure to work with and I trust that he will make a good approver 
for the Qt project.

Changes:  https://codereview.qt-project.org/q/owner:piotr.wiercinski
Reviews:  https://codereview.qt-project.org/q/commentby:piotr.wiercinski 


Best regards,
Morten
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

Re: [Development] About the timeline and phases to support C++20 with and in Qt

[Volker Hilsheimer via Development]

From what I see, the open questions from the thread in May are still:

- (paraphrasing Ville) which C++ 20 features are worth breaking (primarily 
embedded) users who want new Qt version but don’t yet have the compilers that 
can give them these facilities?

https://lists.qt-project.org/pipermail/development/2023-May/043887.html

And the perspective here needs to be the users of Qt. In Qt, we can often work 
around missing facilities, if there is a real benefit in doing so. But as long 
as users can use a more recent C++ language standard for their code without 
being hobbled by Qt, the list of C++20 features that really would make a 
difference for Qt users seems to negligible. From what I see, we are years away 
from doing anything useful with modules and co-routines, as the two biggest 
items that users of Qt would be interested in and ask about. Have we done any 
work on any of those, beyond Ville’s work on senders & receivers?

Concepts would be very useful, also for Qt users, because a library of concepts 
could be useful for users when they create their own APIs; and because it would 
allow us to comprehensibly document the requirements for our own templates 
(today we often hide the std::enable_if’ery from documentation, and don’t 
always provide equivalent information about the requirements to the types used 
in our templates).
We can perhaps start with that as a documentation feature (qdoc can use 
libclang with whatever C++ standard it wants).


- which C++ standard do the oldest versions of gcc and clang we support default 
to (the gcc devs at least strongly advising against explicitly raising the 
language version from the default)

https://lists.qt-project.org/pipermail/development/2023-May/043915.html

https://gcc.gnu.org/projects/cxx-status.html still documents C++20 as 
experimental, and C++17 as the default.


Volker


On 5 Feb 2024, at 10:57, Alex Blasche via Development 
 wrote:

Hi,

For Qt 6.8 we continue to work on Phase 1 item 
https://bugreports.qt.io/browse/QTBUG-109360. In other words we will not  
mandate C++20 compilers in Qt 6.8 yet. An LTS release is not the right for such 
a breaking change anyway. The possible releases for such a drastic change are 
6.9 or 6.12 (releases immediately following an LTS release). Note that I am not 
cofirming those releases but merely point out which type of releases could be 
potential options.

Considering the track record we have when getting Phase 1 items into the 
release and considering existing customer concerns I have a hard time believing 
that 6.9 is a serious option. This is my personal opinion.

--
Alex



From: Development  on behalf of Thiago 
Macieira 
Sent: Saturday, 3 February 2024 18:13
To: development@qt-project.org
Subject: Re: [Development] About the timeline and phases to support C++20 with 
and in Qt

On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development
wrote:
We got four user stories on Qt Bug Reports:

1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
2. C++20 is required for the development of Qt itself -
https://bugreports.qt.io/browse/QTBUG-109361
3. C++20 is mandatory for users of Qt -
https://bugreports.qt.io/browse/QTBUG-109362

Those tasks haven't got any updates recently. What's the status?

I'd like to ask that we go to #3 for 6.8 or 6.9.


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

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

Re: [Development] Nominating David Redondo for approval status

[Volker Hilsheimer via Development]

+1

Volker


> On 1 Feb 2024, at 15:10, David Edmundson  wrote:
> 
> I would like to nominate David Redondo for approver rights in the Qt project.
> 
> David's first contributions to Qt started in November 2020, but has
> ramped up this last year working on the Qt Wayland platform. Not only
> has he fixed a lot of issues within Qt Wayland, but he has also
> managed to push changes into upstream wayland and un-break a lot of
> important Qt functionality.
> David and I work together at Blue Systems for the last 4 years. I have
> full confidence in his ability to review code correctly and also to
> use any new privileges appropriately.
> 
> Changes where he is the author:
> https://codereview.qt-project.org/q/author:qt%2540david-redondo.de
> Changes where he commented/voted on:
> https://codereview.qt-project.org/q/reviewer:qt%2540david-redondo.de
> 
> David
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Marking the Tech Preview APIs as such

[Volker Hilsheimer via Development]

> On 22 Jan 2024, at 22:15, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 22/01/24 19:03, Shawn Rutledge via Development ha scritto:
>> I guess your goal is to be able to see it in the header rather than having 
>> to look up the docs in the cpp file or online?  (Alternatively we could 
>> write all docs in headers, but then the headers get to be large, take 
>> storage space alongside every installation of Qt binaries, and slow down 
>> everyone’s compilations, so I guess that’s why we don’t do it that way?  Or 
>> we could somehow include doc diffs in API review patches for whatever API 
>> the script has already decided is “interesting".)
> 
> As I said, it's not just in order to see the tag in the header when the code 
> is introduced, but also to see that a TP class is getting out of TP status 
> because the tags are being removed (= the header is being touched, and will 
> appear in the header review). If \preliminary is removed from the docs, it 
> won't be obvious at API review time.
> 
> My 2 c,
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer


I like this proposal; having it visible in the header that an API is either new 
as, or still in, or moving out of tech preview is very useful information for 
the header review process.

A QT_TECH_PREVIEW_API macro that expands to “whatever works” works for me. It 
can expand to nothing for the purpose of header review, but if we can make it 
an attribute that qdoc can use to implicitly add the relevant boilerplate to 
the respective reference documentation, then it removes the need to keep 
\preliminary documentation tagging in sync.

I also like the general idea of supporting the header review process with more 
information, such as links to the relevant documentation, or even a 
documentation diff, or even change on gerrit that introduced the change; but 
that’s probably orders of magnitude harder and complex to implement, so let’s 
not wait for that.

Moving documentation into the headers is a no-go for me, not only because of 
the overwhelming amount of status quo. Documentation needs to inform the user 
about what the API does (or, well, is supposed to do), and might need to change 
when the implementation does. This is less likely to happen when it lives next 
to the declaration.

Volker

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

Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions

[Volker Hilsheimer via Development]

On 5 Dec 2023, at 13:13, Volker Hilsheimer via Development 
 wrote:

On 3 Dec 2023, at 12:08, apoenitz  wrote:

On Sat, Dec 02, 2023 at 11:25:16AM +0100, Giuseppe D'Angelo via Development 
wrote:
On 30/11/2023 19:39, apoenitz wrote:
I propose to make this setup an official Module of Qt Creator, and herewith
also nominate Jarek as Maintainer. Jarek has been pushing the idea and is the
author of the biggest existing Qt Creator Solution: TaskTree[2], so for me this
is the obvious choice.

Comments/questions/opinions?

Just wondering if we could extend the scope:
do these solutions depend on  QtCreator parts somehow?

No, and not really planned now, but there are a few potential candidates that
depend on each other (remote file and remote process access for instance). For
now the idea is to have only "pure" Qt users there, but if the idea in general
flies then at some time it's imaginable that "solutions" could depend on each
other.

If not (I've understood that TaskTree specifically
doesn't), why not "just" going for a playground module?

It's not feature-complete yet, and as long as there are still additions expected
there are benefits to have that in-tree (e.g. atomic commit instead of 
submodules)
that we currently believe to outweigh the benefits of a "physical" separation.
But this also may change at some time.

Andre’

Makes sense to start by moving code into a module under Qt Creator, and 
evaluate at a later point whether selected solutions could be relevant for Qt 
or generally be spun out into a separate repository.

And +1 for Jarek as maintainer.

Volker


New module added now to https://wiki.qt.io/Maintainers#Qt_Creator_Maintainers, 
with Jarek as maintainer.


Cheers,
Volker


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

Re: [Development] QML Rectangle corner radius API for Qt 6.7

[Volker Hilsheimer via Development]

> On 22 Dec 2023, at 13:59, Lars Knoll via Development 
>  wrote:
> 
>> 
>> On 22 Dec 2023, at 13:54, Tor Arne Vestbø via Development 
>>  wrote:
>> 
>>> On 22 Dec 2023, at 13:20, Giuseppe D'Angelo via Development 
>>>  wrote:
>>> 
>>> Il 22/12/23 11:15, André Somers ha scritto:
 I can see two options. The simplest option is to have a `radii`
 property, which is a grouped property containing the `topLeft`,
 `topRight`, `bottomLeft` and `bottomRight` properties as a floating
 point value as we have now. I think that would be cleaner than the
 current state of things.
>>> 
>>> While at it, it should be aptly named `cornersRadii` or similar.
>>> 
>>> `radius` has always violated Qt API guidelines. A rectangle doesn't have a 
>>> radius. We shouldn't be doing the same mistake again.
>> 
>> Radius is a well established term for this in Qt, and other UI frameworks. A 
>> key principle in Qt’s API design is familiarity and consistency.
> 
> I’m not 100% sure about this. “Radius" without any pre/postfix is IMO 
> somewhat confusing on a rectangle. HTML uses “borderRadius”, which I actually 
> like quite a bit. And as it’s a new property, it would also not cause 
> conflicts with the old name.
> 
> Cheers,
> Lars



CSS has https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

plus the per-corner values, e.g. 
https://developer.mozilla.org/en-US/docs/Web/CSS/border-top-left-radius

That is not specific to a rectangle though, and “border” is a well-defined CSS 
concept, so I’m not quite convinced that a rectangle’s “borderTopLeftRadius” 
makes sense. What happens to the fill?


We have “Rectangle.radius" today already, and we cannot/should not overload 
properties (radius as either holding a real, or a gadget type).

QPainter::drawRoundedRect [1] has parameters xRadius, yRadius, so evidently 
there are use cases for customizing the rounding of corners beyond a single 
value.

[1] https://doc.qt.io/qt-6/qpainter.html#drawRoundedRect

Making the whole thing into a grouped property would be nice indeed, but if we 
want to make it extensible, then “cornerProperties” is perhaps an option. That 
allows us to have all sorts of values for each corner, and the question becomes 
at some point whether we are over-engineering the simple concept of a rectangle.

Volker

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

Re: [Development] 6.7 FF vs. C++20 comparisons

[Volker Hilsheimer via Development]

> On 17 Dec 2023, at 14:16, Marc Mutz via Development 
>  wrote:
> 
> On 16.12.23 10:20, apoenitz wrote:
>> Recently there were two serious regression on the Qt side due to "just using
>> string views" (which would also be formally permitted), and I've seen now a
>> patch that changes a map to a hash to avoid part of the porting "work" to the
>> new comparison scheme that makes that change not quite "mechanical".
> 
> Sorry, I am not aware of either, and the lack of specificity in the 
> above makes it impossible to respond in a meaningful way, so I won't try to.
> 
> Thanks,
> Marc

Without any more details, let’s continue with the work as scoped for Qt 6.7, 
e.g. continue rollout to string and smart pointer types, as well as to 
QModelIndex/QPeristentModelIndex.

We need confidence that the framework supports plausible scenarios and learn 
how to deal with the corner cases, which is better done sooner rather than 
later.

Volker



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

Re: [Development] Request for early MOC support for C++20 Modules

[Volker Hilsheimer via Development]

> On 15 Dec 2023, at 16:19, Sune Vuorela  wrote:
>
> On 2023-12-15, Elias Steurer via Development  
> wrote:
>> No, I still need all the get/set/notify functions to change/get the
>> variables from the outside. There is currently no way to do that, or am
>> I missing something? Something like this
>> https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52
>> but as a standardized Qt macro.
>
> My experience, after having written a few macros like that out of
> projects, is that it is a bad idea, unless it is really thought thru.
>
> What I have seen is that it encourages all properties to be
> read/write/notify where at least many of them was only supposed to be
> read/notify or read/constant.
>
> /Sune


Would it help/be a bad idea if moc would identify member functions that match 
the Qt naming convention so that you can reduce the boiler plate, e.g.


class Thing
{
Q_PROPERTY(QString text)

public:
void setText(const QString ); // obviously the setter
QString text() const; // evidently the getter

signals:
   textChanged(const QString ); // there’s a notification signal
};


Doesn’t help you if you use snake case, but *could* perhaps be configurable 
with a command line option.

Volker

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

[Development] Qt 6.7 API review: QJniObject, QJniEnvironment, and QtJniTypes type system

[Volker Hilsheimer via Development]

Hi,

For Qt 6.7 we have made a bunch of changes to the QJniObject class and the 
so-far-undocumented macros from QtJniTypes. Also, the code structure has 
changed quite a bit. This change is the diff of the qjni* headers from 6.6 to 
6.7:

https://codereview.qt-project.org/c/qt/qtbase/+/524298

If the JNI helpers for Android development are of any interest to you, please 
join us this Wednesday (Dec 13th) at 13:30 Oslo time for a review of the 
changes. Here’s the link to the Teams meeting:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTc0NjU2ZjctN2M1ZC00ODE3LTk2NzctMDVlZTM5ZmZmNWRk%40thread.v2/0?context=%7b%22Tid%22%3a%2220d0b167-794d-448a-9d01-aaeccc1124ac%22%2c%22Oid%22%3a%22de5b241e-f1fd-4127-965f-ca90b3f70722%22%7d

Most of the changes are a continuation of the work started for Qt 6.4 and 
described in

https://www.qt.io/blog/unstringifying-android-development-with-qt-6.4

For a bit of JNI code that uses the new Qt 6.7 functionality, check the 
“fetchFont” helper in

https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/android/qandroidplatformiconengine.cpp

As of now, the QtJniTypes stuff is still undocumented APIs, so one of the 
questions is whether we are ready to document some of this, and whether we 
should do that for 6.7 or 6.8.

Cheers,
Volker

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

Re: [Development] HEADS-UP: Qt 6.7 Feature Freeze

[Volker Hilsheimer via Development]

> On 8 Dec 2023, at 15:06, Jani Heikkinen via Development 
>  wrote:
> 
> Hi!
>  Qt 6.7 Feature Freeze will be in effect today. If your changes are ready and 
> approved by the end of today, you can still continue staging those in 'dev' 
> over the weekend. The plan is to branch from "6.7" to "dev" on Monday morning 
> next week.

Perhaps we should wait with branching off until we have a successful dependency 
round completed in dev. Otherwise the CI system will do twice the work to test 
the same set of changes in different branches.

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

If your feature is ready and merged, please remember to update the 
whatsnew67.qdoc file in the qtdoc repository as well.

To limit conflicts, use gerrit’s inline editing feature to add your bits to 
this change:

https://codereview.qt-project.org/c/qt/qtdoc/+/524057


Volker

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

Re: [Development] Buddy group to help new contributors

[Volker Hilsheimer via Development]

vestment of time and money to 
actually make that move. There exists a significant amount of tooling, process 
automation, authentication structure etc that is based on the setup that we 
have. From a variety of bots to CI integration and other test automation, to 
releasing and packaging. That’s a ton of work to replace.

We can start the discussion and identify some specific improvements that move 
us forward, and maybe even end up agreeing what the perfect workflow would look 
like; but waiting for the grand simplification to arrive before we do anything 
is IMHO not the answer.


> It might be worth considering a migration to GitLab, which has been a 
> successful move for other open-source projects like KDE and Arch. Given that 
> Qt already uses an internal GitLab instance, this could be a good platform 
> for future collaboration. Alternatively, adopting Gitea, as used by the 
> Blender Foundation, could also be a viable option if Gitlab licensing is a 
> no-go. 
> I strongly believe the focus should be on overhauling the workflow first. 
> Everything else, including smoother onboarding of new contributors, will 
> naturally follow.


See above. Even if I would believe that there's a magical greener pasture for 
*everyone* (not just for new contributors; we can’t optimise the process for 
that group of people if it makes the process harder for people doing the vast 
majority of the work, esp for the maintainers and reviewers), getting there 
will take more time than we should wait.

> There was also an discussion about this recently on Reddit.


Reading through that, it's a mix of

* I’m not willing to sign the CLA (can’t help you buddy)
* I couldn’t find a reviewer (that’s exactly what the buddy group is going to 
help with)
* “I’m not going to learn a workflow that is not github” - sorry, but “shrug”; 
I have no reason to believe that you will be willing to learn what it takes to 
make your patch work on a platform you are not familiar with
* and yes, a few statements that the process is hard - with some encouraging 
statement from Psychological_Ad1417 that by getting help, it isn't so difficult 
(and 

So, of the four main sentiments that I can identify in that discussion, two can 
be addressed to some degree by a buddy group that proactively reaches out to 
lower the learning curve.


Volker


> On 12/5/2023 9:57 AM, Volker Hilsheimer via Development wrote:
>> At the Qt Contributors Summit in Berlin last week, we discussed various 
>> ideas around improving the contribution experience, esp for new people.
>> 
>> One action that came out of that was setting up a gerrit group of people 
>> that are able and willing to hand-hold new contributors through the process. 
>> This includes setting up your local development environment, gerrit 
>> configuration and workflow, and finding out what to work on from e.g. Jira. 
>> The basic idea is that we establish a (gerrit, probably) group with buddies; 
>> we can already identify “first gerrit reviews" for a new user, and then we 
>> can proactively reach out with a welcome message, and add the group of 
>> buddies as a reviewer.
>> 
>> A few people raised their hand at the event, but I don’t think anyone took 
>> down the names, and I was busy juggling microphones. And either way, this is 
>> of course open to anyone! So please reply to this, either to all or 
>> privately to me, if you want to be part of that group.
>> 
>> Cheers,
>> Volker
>> 
>> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

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

[Volker Hilsheimer via Development]

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

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

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


Volker


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

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

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

BR,
Maurice


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

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

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

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

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

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


So is this the Qt Middleware module?


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

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


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

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

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

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

Cheers,
Tor Arne


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

Hi,

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

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

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

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

Yours,

Tuukka

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

Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions

[Volker Hilsheimer via Development]

> On 3 Dec 2023, at 12:08, apoenitz  wrote:
> 
> On Sat, Dec 02, 2023 at 11:25:16AM +0100, Giuseppe D'Angelo via Development 
> wrote:
>> On 30/11/2023 19:39, apoenitz wrote:
>>> I propose to make this setup an official Module of Qt Creator, and herewith
>>> also nominate Jarek as Maintainer. Jarek has been pushing the idea and is 
>>> the
>>> author of the biggest existing Qt Creator Solution: TaskTree[2], so for me 
>>> this
>>> is the obvious choice.
>>> 
>>> Comments/questions/opinions?
>> 
>> Just wondering if we could extend the scope:
>> do these solutions depend on  QtCreator parts somehow?
> 
> No, and not really planned now, but there are a few potential candidates that
> depend on each other (remote file and remote process access for instance). For
> now the idea is to have only "pure" Qt users there, but if the idea in general
> flies then at some time it's imaginable that "solutions" could depend on each
> other.
> 
>> If not (I've understood that TaskTree specifically
>> doesn't), why not "just" going for a playground module?
> 
> It's not feature-complete yet, and as long as there are still additions 
> expected
> there are benefits to have that in-tree (e.g. atomic commit instead of 
> submodules)
> that we currently believe to outweigh the benefits of a "physical" separation.
> But this also may change at some time.
> 
> Andre’

Makes sense to start by moving code into a module under Qt Creator, and 
evaluate at a later point whether selected solutions could be relevant for Qt 
or generally be spun out into a separate repository.

And +1 for Jarek as maintainer.

Volker



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

[Development] Buddy group to help new contributors

[Volker Hilsheimer via Development]

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

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

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

Cheers,
Volker

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

Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers

[Volker Hilsheimer via Development]

> On 6 Nov 2023, at 15:55, Alex Blasche via Development 
>  wrote:
> 
> Hi,
> 
> Qt GRPC and Qt Protobuf were added to Qt a while ago. However until now they 
> have been in Tech Preview mode. As we investigate the remaining issues which 
> might prevent us from leaving TP, we need to address the open issue of 
> maintainer-ship.
> 
> I'd like to nominate Tatiana Borisova as maintainer for Qt Protobuf and 
> Alexey Edelev as maintainer for Qt GRPC. In fact, both have been working on 
> this code base even before they officially became part of Qt. I am glad they 
> agreed to continue this work going forward in the context of Qt Development.
> 
> —
> Alex


https://wiki.qt.io/Maintainers#Qt_Maintainers updated accordingly.

Congratulations Tatiana and Alexey, and thanks for stepping up as maintainers 
of these two modules!


Cheers,
Volker

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Volker Hilsheimer via Development]

On 14 Nov 2023, at 10:00, Volker Hilsheimer via Development 
 wrote:
On 14 Nov 2023, at 09:40, Marc Mutz via Development 
 wrote:

On 14.11.23 09:31, Marc Mutz via Development wrote:
[...]
And then naming them Qt::partial_ordering is just consequent, because
users can reach ultimate SC by doing something like

#ifdef __cpp_lib_three_way_comparison
using std::partial_ordering;

#else
using Qt::partial_ordering;
#endif

~~~ use unqualified partial_ordering ~~~

This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by
simply saying

  namespace Qt {
  using partial_ordering = std::partial_ordering;
  using weak_ordering = std::weak_ordering;
  using strong_ordering = std::strong_ordering;
  }

Done.


I agree with Marc here.

It’s tempting to add some Qt::Ordering::Partial, but it only makes things 
harder in the not-so-long run. From C++ 23 on, we can expect 
std::partial/weak/strong_ordering to become as ubiquitous as “true” and 
“false”. We should not invent our own.

Adding Qt::snake_case interims that are BC with std, with conversion from/to 
QPartialOrdering, is the right thing to do.

On 14 Nov 2023, at 11:54, Edward Welbourne  wrote:
Adding Qt::snake_case interims that are BC with std, with conversion
from/to QPartialOrdering, is the right thing to do.

Perhaps namespace q20 would be a better place for them, given both the
naming (snake-case, to match stl) and the plan ?

and

On 14 Nov 2023, at 12:01, Tor Arne Vestbø  wrote:

The naming makes sense, given their purpose. But can we put them in a dedicated 
Qt::std_compat namespace? Or is that too late? That would make it clear these 
are not Qt proper types (living in the Qt namespace), but dedicated compat 
types/BC/SC vehicles


We have so far not used any q20/23/xp APIs in public Qt API, and those 
namespaces are not documented. The intention was for them to be used 
internally, and the qNN headers contain the “not part of the Qt API” warning. 
This doesn’t have to be set in stone, of course. Perhaps this is the exception 
that confirms the rule.

OTOH, if the only reason for not using Qt::snake_case is because of the 
snake_case, then it seems overly complicated to make that exception, or to 
introduce a new namespace. It’s going to be part of practically every 
value-type we have in Qt, which makes it a very very ubiquitous “exception”. We 
have QList::push_back and QList::const_iterator for compatibility with the 
standard. I don’t quite see why it would not be ok for Qt::*_ordering to exist 
as a proper Qt names. The only difference here is that we don’t want to 
introduce a Qt::CameCase equivalent, for the reasons given by Marc.

That they are short-lived as “independently defined entities” is an 
implementation detail. Qt::*_ordering will work throughout the Qt 6 life-time, 
also once they are just aliases to std::*_ordering; there won’t even be a real 
reason to remove them for Qt 7.


On 14 Nov 2023, at 11:54, Edward Welbourne  also wrote:
Speaking of q20, I notice its files live in corelib/global/; it occurs
to me that perhaps corelib/compat/ might be more natural (mainly because
it's the first place I looked for them).  They are, after all, a piece
of compatibility machinery, albeit between Qt and C++ rather than
between Qt versions (as such - of course, the Qt versions' change of C++
standard does make them indirectly also between Qt versions).

Eddy.

module/compat is about backward compatibility with older Qt versions, and in 
practice only includes the respective removed_api.cpp implementation file.

We include those qNN headers in public headers, and including something from 
“compat” in public headers seems wrong.

Volker


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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Volker Hilsheimer via Development]

> On 14 Nov 2023, at 09:40, Marc Mutz via Development 
>  wrote:
> 
> On 14.11.23 09:31, Marc Mutz via Development wrote:
> [...]
>> And then naming them Qt::partial_ordering is just consequent, because
>> users can reach ultimate SC by doing something like
>> 
>>  #ifdef __cpp_lib_three_way_comparison
>>  using std::partial_ordering;
>>  
>>  #else
>>  using Qt::partial_ordering;
>>  #endif
>> 
>>  ~~~ use unqualified partial_ordering ~~~
> 
> This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by 
> simply saying
> 
>namespace Qt {
>using partial_ordering = std::partial_ordering;
>using weak_ordering = std::weak_ordering;
>using strong_ordering = std::strong_ordering;
>}
> 
> Done.


I agree with Marc here.

It’s tempting to add some Qt::Ordering::Partial, but it only makes things 
harder in the not-so-long run. From C++ 23 on, we can expect 
std::partial/weak/strong_ordering to become as ubiquitous as “true” and 
“false”. We should not invent our own.

Adding Qt::snake_case interims that are BC with std, with conversion from/to 
QPartialOrdering, is the right thing to do.

Volker

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

Re: [Development] Lots of qdoc-related warning messages when building 'docs' target in Qt-6.6.0?

[Volker Hilsheimer via Development]

On 21 Oct 2023, at 10:02, Haowei Hsu  wrote:

Hello, Qt Development Team.

Recently, I successfully built docs of Qt-6.6.0 in MSYS/MINGW64 shell with the 
following commands:

  1.  cd /c/Test/qt-everywhere-src-6.6.0
  2.  mkdir build && cd build
  3.  mkdir mingw-release && cd mingw-release
  4.  ../../configure -release -nomake examples -nomake tests -- 
-DFEATURE_system_zlib=OFF -DFEATURE_zstd=OFF
  5.  cmake --build . --target docs --parallel 4

Although the HTML documentation is generated, (the following is the screenshot)



I noticed that there are lots of 'qdoc-related warning' messages when building 
'docs' target in Qt-6.6.0.

How to resolve all of these qdoc-related warning messages? What did I miss?


Warnings from qdoc are not unusual; our CI system blocks changes that increase 
the number of warnings, but the base line is not 0 for all repositories.

To resolve those, make patches to gerrit that fix them :)

Volker

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

Re: [Development] Removal of Non-deprecated API Elements in v6.6.0

[Volker Hilsheimer via Development]

> On 19 Oct 2023, at 15:55, Phil Thompson via Development 
>  wrote:
> 
> On 19/10/2023 12:07, Giuseppe D'Angelo via Development wrote:
>> On 19/10/2023 12:07, Phil Thompson via Development wrote:
>>> Up until v6.6 upgrading to a new version was relatively low risk but this 
>>> will just encourage people to stay on older versions. Is this a mistake or 
>>> a change in policy?
>> There is actually a policy document that says that certain source
>> breaks are acceptable, especially the ones that prevent mistakes from
>> users:
>> https://contribute.qt-project.org/quips/6
>> I'm not really sure about the real-world impact of the change in
>> question, but there's an argument that this fits the QUIP-6 bill:
>> * if you have a non-const QSqlRecord object, you can keep calling
>> boundValues(). You would still get a mutable reference to the bound
>> arguments -- that is, that is 100% API compatible.
>> * If you have a const QSqlRecord, and you're trying to mutate the
>> bound values, then your code rightfully stops compiling, as you're not
>> supposed to do that. You can fix this in a way that works with Qt
>> before and after 6.6. So, you should do that.
>> Granted, each source-incompatible change disrupts _someone_ _somehow_.
>> I'm not sure where to draw the line: "this has to wait 10 years for Qt
>> 7" vs. "we should be changing this now, as we're making users a
>> disservice with a suboptimal/dangerous/misleading API" are both valid
>> arguments, but it's not a binary choice, it's much more of a gradient.
>> For this specific change, it's also interesting that it landed after
>> 6.5, giving people plenty of time to adapt.
>> My 2 c,
> 
> As I said I completely understand the reason for the change. QUIP-6 dates 
> back to 2017 and the function itself dates back to 2005, so why now? Why not 
> deprecate now and remove in v6.7?

I happened to look at the API because Christian applied some much needed TLC to 
Qt Sql, and we got a new Qt Sql driver contribution as well.

Deprecating it wouldn’t have been possible because we couldn’t have added a 
replacement API that would have been unambiguous, without coming up with a new 
function name. So you would have gotten the deprecation warning without a 
sensible way to fix your code.

> Also, can anybody point me to the ChangeLog for v6.6? (I want to find the 
> entry with the [Potentially Source-Incompatible Changes] tag.)


The release notes with changes are here:

https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.6.0/release-note.md

But, looking at the commit message of 3f72b0d5fc70d3cf7daa4badccd5a40fc8b0726a, 
I fear that you are catching me red-handed :(

Volker

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

Re: [Development] Removal of Non-deprecated API Elements in v6.6.0

[Volker Hilsheimer via Development]

> On 19 Oct 2023, at 13:07, Giuseppe D'Angelo via Development 
>  wrote:
> 
> On 19/10/2023 12:07, Phil Thompson via Development wrote:
>> Up until v6.6 upgrading to a new version was relatively low risk but this 
>> will just encourage people to stay on older versions. Is this a mistake or a 
>> change in policy?
> 
> There is actually a policy document that says that certain source breaks are 
> acceptable, especially the ones that prevent mistakes from users:
> 
> https://contribute.qt-project.org/quips/6
> 
> I'm not really sure about the real-world impact of the change in question, 
> but there's an argument that this fits the QUIP-6 bill:
> 
> * if you have a non-const QSqlRecord object, you can keep calling 
> boundValues(). You would still get a mutable reference to the bound arguments 
> -- that is, that is 100% API compatible.
> 
> * If you have a const QSqlRecord, and you're trying to mutate the bound 
> values, then your code rightfully stops compiling, as you're not supposed to 
> do that. You can fix this in a way that works with Qt before and after 6.6. 
> So, you should do that.
> 
> Granted, each source-incompatible change disrupts _someone_ _somehow_. I'm 
> not sure where to draw the line: "this has to wait 10 years for Qt 7" vs. "we 
> should be changing this now, as we're making users a disservice with a 
> suboptimal/dangerous/misleading API" are both valid arguments, but it's not a 
> binary choice, it's much more of a gradient. For this specific change, it's 
> also interesting that it landed after 6.5, giving people plenty of time to 
> adapt.


Removing APIs (via the REMOVED_SINCE mechanism, which leaves the symbol in the 
ABI by still compiling it when building Qt, but removes it from the API from 
the specified version on) is usually only done when there is a source 
compatible replacement. The removal might then be done to enable the 
replacement without introducing ambiguities.

E.g. we removed

QReadWriteLock::tryLockForRead()

because we wanted to add

bool tryLockForRead(QDeadlineTimer timeout = {})

This is source compatible, but we don’t need both. And various 
QXmlStreamAttributes::value overloads were removed and replaced by a single 
version using QAnyStringView, which should also be source compatible; but 
without removing the old, the new API would have resulted in ambiguities.

In the specific case of the QSqlRecord APIs, we decided to remove them; as 
Peppe points out, it’s source compatible, unless you were doing something that 
is potentially dangerous and possibly resulting in a corrupted internal state. 
And it then breaks the build rather than silently breaks your application. 
Looking through the REMOVE_SINCE(6, 6) usage in my source tree, there shouldn’t 
be any other API removals that result in source incompatibility, but we might 
have made a mistake somewhere.


The technical process by which we deprecate APIs is generally documented here:

https://wiki.qt.io/Deprecation

That page doesn’t give any guidance on how deprecations should be phased: how 
many releases after a replacement API was added should a warning be generated 
from the old API? Some people use “the release after an LTS”, which was a 
conclusion from Qt CS 2014 [1] when the concept of LTS was established.

[1] https://wiki.qt.io/Qt-contributors-summit-2014-Long_term_releases

Qt 6.6 is such a release.

But removing an API after deprecating would suggest that the removal would not 
be source compatible anyway (otherwise, why deprecate?), and there wouldn’t be 
any replacement API to port to and silence the warnings either.


Volker

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

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Volker Hilsheimer via Development]

On 13 Sep 2023, at 16:25, Volker Hilsheimer via Development 
 wrote:

On 13 Sep 2023, at 13:23, Ahmad Samir  wrote:

On 13/9/23 11:06, Ivan Solovev via Development wrote:
I would therefore propose to remove the file from qt5.git:
+1 from my side.
I believe I simply do not have the clang-format tool installed on my system,
because it usually breaks the formatting of the patches, not improves them.
One way to address these problems, especially for new devs or drive-by
contributions, is stating clearly in the wiki page:
"use clang-format, it should get you at least half way there, but you still
should/must also override it to match the style of surrounding code, as much as
possible, in the file(s) you're editing, that's kinder to reviewers".
The problem is that we have a pre-commit (I believe) git-hook, which checks the
formatting and nags if it does not match to what we have in the _clang-format 
file.
This basically forces​ the new or drive-by contributors to submit the patch 
with an
incorrect formatting, which then leads to a bunch of review comments about 
code-style.
I think that it's better to give no hints, rather than misleading hints.

[...]

I think the best way to find out is indeed removing the file, then one of two 
things will happen:
- we'll get less formatting issues in reviews (especially from new contributors)
- or we'll still get formatting issues, just different ones than what 
clang-format currently does

So 6-12 months, and we'll have a definite answer. :)

Regards,
Ahmad Samir

I find the input from clang-format’s sometimes helpful, sometimes annoying. And 
the source of the annoyance is not that clang-format points out things that I 
could have formatted differently, but that our pre-commit hook returns with a 
non-zero exit code if clang-format produces a diff, thus blocking the commit.

Based on that, I’d propose to change the pre-commit hook: 
https://codereview.qt-project.org/c/qt/qtrepotools/+/503746

and leave the _clang_format file in place as a tool, not as a straight-jacket.

Volker

I’ve now submitted the change, thanks for the reviews.


Volker

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Volker Hilsheimer via Development]

On 19 Sep 2023, at 15:49, Marc Mutz via Development 
 wrote:
So I ask: Please let us roll out the framework with one of
equal/eq/order/ordering/cmp (your choice, but quickly!), to set a status
quo against which to benchmark any potentially-superior solutions, and
then the ML can finish bikesheddding and if the discussion yields
something better, I think I speak for Ivan, too, when I say that we're
committed to porting to that.

Thanks,
Marc


Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3 
right now (needs rebase, doesn’t build with either C++17 or C++20 for me on 
macOS with apple’s clang), my suggestion would be to go “very explicit" with 
the names for O and E, at least for the time being.

O = compareThreeWay, following std::compare_three_way 
(https://en.cppreference.com/w/cpp/utility/compare/compare_three_way)
E = comparesEqual


The vast majority of code will use operators to compare two objects. Code that 
somehow needs the concept spelled out can type it out as well. In contrast to 
`swap` we don’t need to be short here, given that the operator-shorthand exists.

Once the chain of commits is up-to-date it will be easier to play around with 
alternatives, to see if we can come up with a technical solution that allows us 
to use `equals` and `compare` as names for E and O, as those are established 
APIs in Qt.


You lost me here, but I assume that you're talking about what I call
(4). There must be _one_ global template. It calls (2) or (3) via (1).
Everything else is a novel idea that must argue against 30 years of C++
and 30 years of Qt experience. qFoo would be that (4). A class-static
cannot be that (4).

Yes, I’m not questioning that we need Qt::equals. But do we need (4)? you 
marked it as optional yourself.

If we can have (1), i.e.

using Qt::equals;
equals(a, b);

why do we need qEquals?

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Volker Hilsheimer via Development]

> On 18 Sep 2023, at 14:46, Marc Mutz via Development 
>  wrote:
> 
> TL;DR: "a" must not be a name of an existing function in Qt.
> 
> On 18.09.23 10:15, Ivan Solovev via Development wrote:
>> Hi,
>> 
>>> 1. an ADL-able calling convention:   `using std::swap; swap(lhs, rhs);`
>>> 2. an implementation for built-in types: `std::swap`
>>> 3. an implementation for user-defined types: ADL `swap`
>>> 4. (optionally) a convenience wrapper: `std::ranges::swap()`, `qSwap`
>> 
>> One more question here - do we want our users to be able to do (1), or
>> is it enough to expose only (4) to them?
>> The reason for my question is (again) naming, see below.

[…]

>> Anyway, it would be great to come to some kind of consensus about the
>> naming of the APIs, and move on to the actual implementation.
> 
> +1


My take from this is that it’s next to impossible to reconcile the technical 
arguments for an unused (even if ugly) function name with having a good public 
API for our types. Not adding named public functions that are equivalent to 
C++20’s spaceship operator makes the problem less complex, but also reduces the 
value of doing the work to the point where it’s not worth it until we require 
C++20.

What Thiago wrote makes sense to me:

> On 31 Jul 2023, at 17:23, Thiago Macieira  wrote:

> I'm not saying we have to. I'm saying that we should provide as API for our 
> comparable types:
> * compare()
> * equals()
> * operators
> 
> Whether the implementation of the latter uses the former two directly is to 
> be 
> seen.


Separating the implementation from the public API seems to me the only way to 
end up with a clean public API, while at the same time have a macro-friendly 
convention. The implementation can live in a private function with a name not 
suitable for a public API, e.g. “qt_equals/qt_compare”; those can be used by 
the macro declaring the operators.

Types for which we then want public APIs as well (and I agree that it’s 
strongly preferable to have this for all relevant types in the long run) can 
declare public equals()/compare() functions that ideally use the private 
functions.

I do not see the need for adding more qOperator type global functions.


Volker

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

Re: [Development] Copying a struct the easy (perhaps too easy) way

[Volker Hilsheimer via Development]

> On 16 Sep 2023, at 02:05, Henry Skoglund  wrote:
> 
> On 2023-09-16 01:55, Giuseppe D'Angelo via Development wrote:
>> Wrong mailing list?
>> 
>> Il 16/09/23 01:41, Henry Skoglund ha scritto:
>>> S a;
>>> S b = a.clone();
>>> 
>>> it seems to work like a charm (6.5.2 on Linux and the Mac. 5.15.2 on
>>> Windows) but my question is if it's kosher?
>> 
>> You class has value semantics, so:
>> 
>> S b = a;
>> 
>> 
>>> I have bad memories from my MFC days in the previous century doing this
>>> simple cloning but maybe it's considered good code now...
>> 
>> Many types in MFC has value semantics as well (CString, COleDateTime, etc.).
>> 
> 
> Thanks Guiseppe and sorry if this was a kind of noob question 

Nothing wrong with asking noob questions, and designing types in C++ has not 
become less complex since MFC was made. You might want to read up about the 
rule of three/five/zero:

https://en.cppreference.com/w/cpp/language/rule_of_three

Cheers,
Volker


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

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Volker Hilsheimer via Development]

On 13 Sep 2023, at 13:23, Ahmad Samir  wrote:

On 13/9/23 11:06, Ivan Solovev via Development wrote:
I would therefore propose to remove the file from qt5.git:
+1 from my side.
I believe I simply do not have the clang-format tool installed on my system,
because it usually breaks the formatting of the patches, not improves them.
One way to address these problems, especially for new devs or drive-by
contributions, is stating clearly in the wiki page:
"use clang-format, it should get you at least half way there, but you still
should/must also override it to match the style of surrounding code, as much as
possible, in the file(s) you're editing, that's kinder to reviewers".
The problem is that we have a pre-commit (I believe) git-hook, which checks the
formatting and nags if it does not match to what we have in the _clang-format 
file.
This basically forces​ the new or drive-by contributors to submit the patch 
with an
incorrect formatting, which then leads to a bunch of review comments about 
code-style.
I think that it's better to give no hints, rather than misleading hints.

[...]

I think the best way to find out is indeed removing the file, then one of two 
things will happen:
- we'll get less formatting issues in reviews (especially from new contributors)
- or we'll still get formatting issues, just different ones than what 
clang-format currently does

So 6-12 months, and we'll have a definite answer. :)

Regards,
Ahmad Samir

I find the input from clang-format’s sometimes helpful, sometimes annoying. And 
the source of the annoyance is not that clang-format points out things that I 
could have formatted differently, but that our pre-commit hook returns with a 
non-zero exit code if clang-format produces a diff, thus blocking the commit.

Based on that, I’d propose to change the pre-commit hook: 
https://codereview.qt-project.org/c/qt/qtrepotools/+/503746

and leave the _clang_format file in place as a tool, not as a straight-jacket.

Volker


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

[Development] Nominating Ahmad Samir for approver

[Volker Hilsheimer via Development]

Hello all,

I would like to nominate Ahmad Samir for approver rights in the Qt project.

For many months, Ahmad has produced a consistent flow of good contributions and 
reviews to Qt:

Changes owned:
* https://codereview.qt-project.org/q/owner:a.samirh78%2540gmail.com

Changes commented/voted on:
* 
https://codereview.qt-project.org/q/commentby:a.samirh78%2540gmail.com+-owner:a.samirh78%2540gmail.com


Cheers,
Volker

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

[Development] codereview now supports mentions in comments

[Volker Hilsheimer via Development]

During the recent maintenance window we have enabled the “mentions” feature of 
gerrit:

https://www.gerritcodereview.com/3.7.html#mention-user-support

It’s not the pinnacle of usability in that you need to know the exact 
username/email address of the user you want to mention (so you have to write 
`@volker.hilshei...@qt.io`, and gerrit will only complain about mistakes when 
you try to send your review), with no auto-completion support (as far as I can 
see). The emails generated are the same as for new comments, just that the 
mentioned user is added to the cc list.

But maybe this will get better in future releases, and even at the current 
state it will hopefully help with drawing the attention of people to specific 
comments during code review or header review.

Thanks to the gerrit admin team for following up on the respective discussion 
from May [1]

[1] https://lists.qt-project.org/pipermail/development/2023-May/043807.html

Cheers,
Volker

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

Re: [Development] BC/SC in patch releases

[Volker Hilsheimer via Development]

> On 31 Aug 2023, at 19:15, Thiago Macieira  wrote:
> 
> On Thursday, 31 August 2023 09:54:37 PDT Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>>> It seems very unlikely that one would end up building for Qt x.y.z and
>>> then have their users on Qt x.y.(w> 
>> With my Debian hat on: I really don't recall this happening ever. Having an
>> app compiled against an older Qt version is just normal, but the other way
>> around... definitely not.
> 
> Yeah, I think the major/only users of that were ourselves: going up and and 
> down a release series to test issues.

Topic added for Qt CS at

https://wiki.qt.io/Qt_Contributor_Summit_2023_-_Program

Based on this discussion, it seems that nobody would mind if we were to decide 
that we no longer promise forward BC in a patch cycle.

Volker


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

Re: [Development] QtFluentMQ

[Volker Hilsheimer via Development]

+1 in general.

However, gerrit users should be individual contributors rather than a team user 
that is shared by multiple people, and the responsible person needs to have a 
gerrit user account.

So, if nobody objects within a few days, please create a QTQAINFRA task in JIRA 
with the necessary details, including the gerrit user for George Ransdall. 
Other contributors from the QtFluentMQ team can already create Qt 
Accounts/gerrit users as well, of course.

Volker



> On 28 Aug 2023, at 08:57, Alex Blasche  wrote:
> 
> +1 from me as it is the Foundation area which will mostly support the 
> process/development.
> 
> --
> Alex
> 
> 
> 
> From: Development  on behalf of team 
> fluentmq 
> Sent: Sunday, August 27, 2023 03:55
> To: Volker Hilsheimer; development@qt-project.org
> Subject: Re: [Development] QtFluentMQ
> 
> Hello,
> 
> Thanks for welcoming the project everybody.
> 
>> AFAIR we haven't bike shedded over the commercial value of a new repository, 
>> the architecture of the code it shall hold, or its licensing before. I don't 
>> think we need to.
> To be fair, while we're Qtifying our API to give back to the community as Qt 
> has been good for us for a long time going, we're also looking forward to 
> acheive framework community grade robustness through a Qt integration as this 
> is the most sensitive part of our product designed for (extra) large scale 
> distributions. We did ask for an intent of integration had the project held 
> its ground in term of compatibility with the Qt project for us to allocate 
> the ressources for that which is why Volker mentioned the need for internal 
> discussions. Using the playground as an assessment buffer for the integration 
> sounds like a party !
> 
>> You should fill in at least the basic information, though: name and 
>> description, responsible person, and desired location.
> 
> name: QtFluentMQ
> description:
> 
> The "QtFluentMQ" project aims to create a user-friendly and versatile message 
> queue (MQ) client using the Qt 6 framework. This client seamlessly handles 
> communication with major MQ platforms. The first release would implement the 
> AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, Artemis, IBM MQ, 
> Amazon MQ and more. It will also migrate the existing Kafka implementation to 
> Qt to support the Kafka platform as well, the current MQ market leader.
> 
> At its core, the project involves a top-layer abstraction called QMQInstance. 
> This layer acts as a bridge between the application and various MQ platforms. 
> Within this layer, there are two main components: QConsumer and QProducer, 
> which can also be referred to as QQmlConsumer and QQmlProducer when working 
> with QML.
> 
> QMQInstance provides a unified QMessage Interface that simplifies the process 
> of sending and receiving data to and from different MQ brokers. This uniform 
> interface streamlines the interaction with multiple MQ platforms, making it 
> easier for developers to integrate messaging functionality into their 
> applications.
> 
> One of the standout features of this project is its dynamic configurability. 
> The client can be configured through a JSON input. This flexibility allows 
> developers to adapt the client's behavior to specific use cases and 
> requirements without significant code changes.
> 
> Additionally, the project supports queues context switching. This means that 
> the client can seamlessly switch between different queues or channels within 
> the MQ platforms. This feature is particularly useful for managing multiple 
> communication channels efficiently and ensuring the smooth flow of data.
> 
> Finally, the QtFluentMQ actively supports open-source initiatives like 
> Plumber, a versatile CLI tool for 
> seamless interaction with various messaging systems, including Kafka and 
> RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the 
> CI/CD process by offering an all-in-one tooling package that streamlines 
> operations and simplifies integration tasks."
> 
> In summary, QtFluentMQ project offers a comprehensive and easy-to-use 
> solution for interacting with various MQ platforms. Its abstraction layer, 
> dynamic configurability, and support for queues context switching contribute 
> to a seamless messaging experience for developers working with Qt 6 
> applications.
> 
> responsible person:  George Ransdall
> 
> desired location: Playground
> 
> Br
> QtFluentMQ Team
> 
> 
> 
> From: Volker Hilsheimer 
> Sent: Saturday, August 26, 2023 11:34 AM
> To: Ulf Hermann ; development@qt-project.org 
> 
> Subject: Re: [Development] QtFluentMQ
> 
>> On 26 Aug 2023, at 10:09, Ulf Hermann via Development 
>>  wrote:
>> 
>> Hi,
>> 
>> The usual way to request a repository, playground or not, is a mail like 
>> this:
>> 
>> 

Re: [Development] QtFluentMQ

[Volker Hilsheimer via Development]

> On 26 Aug 2023, at 10:09, Ulf Hermann via Development 
>  wrote:
> 
> Hi,
> 
> The usual way to request a repository, playground or not, is a mail like this:
> 
> https://lists.qt-project.org/pipermail/development/2022-August/042900.html
> 
> If the request is not totally outlandish it's usually granted, possibly after 
> some bike shedding over the name and location.
> 
> AFAIR we haven't bike shedded over the commercial value of a new repository, 
> the architecture of the code it shall hold, or its licensing before. I don't 
> think we need to.
> 
> You should fill in at least the basic information, though: name and 
> description, responsible person, and desired location.
> 
> At least sometimes, we have used the lazy consensus mechanism for repository 
> requests in the past. This seems a good idea to me. I will +1 this one if the 
> (still missing) basics are reasonable.
> 
> We can still discuss the way to integrate with the rest of Qt once we can see 
> some code.


It’s good to understand the ambitions and state of the project when deciding 
the location of the repo, hence my questions. From what I read about the state 
in particular, a repository in the playground/ namespace seems to make more 
sense than starting under qt/ and adding this to the qt5.git super repository 
immediately, as our wiki page suggests it should.

So if team QtFluentMQ can provide the missing bits of information, then we can 
just go ahead with this if no-one objects.


Cheers,
Volker


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

Re: [Development] On the use of the inline keyword

[Volker Hilsheimer via Development]

> On 25 Aug 2023, at 14:20, Ahmad Samir  wrote:
> 
> On 25/8/23 14:11, Cristian Adam via Development wrote:
>> The other way of fixing this is by using ... macros. The article at c++ - 
>> Importing inline functions in MinGW - Stack 
>> Overflow
>>   mentions using inline in the class declaration.
>> Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is 
>> also fine:
>> #ifdef _WIN32
>> #define Q_EXPORT_INLINE inline
>> #else
>> #define Q_EXPORT_INLINE
>> #endif
>> class __declspec(dllimport) MyClass {
>> public:
>> Q_EXPORT_INLINE int myFunc2();
>> Q_EXPORT_INLINE int myFunc1();
>> };
>> inline int MyClass::myFunc2(void) {
>> return myFunc1();
>> }
>> inline int MyClass::myFunc1(void) {
>> return 0;
>> }
> 
> [...]
> 
> The main deterrent to not fix it like the qstring.h patch[1] is the churn 
> caused by changing many lines, in many files, right?
> 
> But if affected code is going to be changed anyway to fix it with macros, it 
> makes more sense to fix it like [1]; if you're changing those lines, may as 
> well adhere to more standard guidelines: inline keyword is only used on 
> function declaration and _not_ the definition.
> 
> 
> My 2p's.
> 
> [1] https://codereview.qt-project.org/c/qt/qtbase/+/498739


Yes, if we have to change the code to fix the warnings, then the way Marc 
proposes, and how it has now been done for qstring.h, seems to be the way to go.

But yes, my concern is the work (I expect this can be easily automated with 
clazy, but still need to be reviewed), and the code churn that goes with it 
(the impact on `git blame`, and the inevitable conflicts when cherry-picking).

It seems to be a rare issue, triggered by specific circumstances. With the 
knowledge that we have now, we can fix issues when they arise, and don’t have 
to change all the problematic use right now.

That’s my understanding at least; I might be wrong, but we have been building 
Qt for a few decades on MinGW without this constantly blocking us.

Volker


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

Re: [Development] BC/SC in patch releases

[Volker Hilsheimer via Development]

> On 24 Aug 2023, at 14:43, Lars Knoll via Development 
>  wrote:
> 
> 
>> On 24 Aug 2023, at 14:30, Giuseppe D'Angelo via Development 
>>  wrote:
>> 
>> On 22/08/2023 23:27, Marc Mutz via Development wrote:
>>> We have
>>> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B 
>>>  for backwards binary compatibility issues and we have
>>> https://contribute.qt-project.org/quips/6  for acceptable and
>>> unacceptable backwards source compatibility.
>>> However, please keep in mind that the Qt project promises that we
>>> maintain_forward_  BC and SC within patch releases:
>>> https://wiki.qt.io/Qt-Version-Compatibility
>> 
>> I'm a bit of a broken record here, but does anyone know the reason for 
>> having two-way binary compatibility in patch releases?
> 
> There were mainly two reasons I remember why we have it:
> 
> 1. It does in theory allow users to create an application binary that can run 
> against different patch level revisions of Qt. I think the idea here was to 
> make deployment easier on platforms that have a pre-installed Qt. This is 
> mainly Linux distributions. 
> 
> 2. It forces us to limit the changes made in patch level releases.
> 
> Personally, I think both arguments have lost their value over time. 
> 
> If you really want to deploy against different versions of Qt, you should 
> simply compile your app against the oldest version you are planning to 
> support. That should cover case (1) in a better way and is much more in line 
> with industry practice. Argument (2) was good 15 years ago when we had rather 
> limited coverage by automated tests, but nowadays, this restriction might be 
> harming us more than it’s doing any good.
> 
> I personally think it’s worthwhile discussing this and maybe modifying/easing 
> our policies here to some degree.
> 
> Cheers,
> Lars


On platforms where Qt is a system library, being able to at least launch your 
application if the system has a lower patch level than what the binary was 
built against sounds nice. But in practice, it’s rolling dice - the application 
might work fine; or it might get fatally hit by one of the not-yet-fixed bugs.

And even if we definitely don’t want to add new API in a patch cycle (beyond 
what is being discussed here as exceptions), the commitment also stops us from 
overriding a virtual to fix a bug in a patch release. If there is no practical 
up-side to forward BC, then that is a significant limitation.

I might be missing something; perhaps someone involved in Linux distribution 
work knows of arguments in favour of keeping the two-way BC commitment. We do 
have time at the Qt Contributors Summit to discuss this, and hopefully also 
some people with different perspectives present. So please add discussion topic 
here:

https://wiki.qt.io/Qt_Contributor_Summit_2023_-_Program


Volker


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

Re: [Development] On the use of the inline keyword

[Volker Hilsheimer via Development]

Thanks for the background info, Cristian!


It’s fine to agree that, for new code, the inline goes only on the declaration, 
and must not be on the definition.

For existing code: throwing the somewhat but not totally (I think) naive regexp

^inline\s+([A-Za-z\*&<>,:\s]+\s+)?[A-Za-z\*&<>,\s:]+::.*\(.*\)[\s\na-z]*\{

at the headers in my local worktree (which doesn’t include qtwebengine) gives 
me > 1500 hits in >200 files.

Before we now go on a campaign to clean all this up (as is already being 
reviewed for qstring.h), I’d rather evaluate other options for the existing 
code base.

Can we disable this warning some in some other way on MinGW? Or, knowing the 
likely reason for it, live with it and fix things when and if we run into them 
(which seems to be reasonably rare)?


Volker


On 23 Aug 2023, at 17:30, Cristian Adam via Development 
 wrote:

Hi,

The issue here is that MinGW GCC is issuing a warning and that we compile with 
-Werror to treat warnings as errors.

c++ - Importing inline functions in MinGW - Stack 
Overflow
 has a similar case.

LLVM-MinGW using clang is also issuing warnings, but these warnings can be 
suppressed via -Wno-ignored-attributes.

No idea why GCC has the warning not part of the -Wignored-attributes like clang 
does.

Cheers,
Cristian

From: Development  on behalf of Marc Mutz 
via Development 
Sent: Wednesday, August 23, 2023 16:27
To: Qt development mailing list 
Subject: [Development] On the use of the inline keyword

Hi,

Every now and then we get a sporadic MinGW error because someone writes
the moral equivalent of the following:

class Q_FOO_EXPORT QMeep {

QBar bar() const;

};
inline QBar QMeep::bar() const;

Resulting in something like this:

 qmeep.h: error: 'QBar QMeep::bar() const' redeclared without
dllimport attribute after being referenced with dll linkage [-Werror]

The last time I remember this came up was in 5.8
(https://bugreports.qt.io/browse/QTBUG-56459). It's so sporadic that
Ivan didn't manage to repro when I pointed this out as a potential problem in
API review, until it suddenly hit today in code that was unchanged since Qt
5.0: https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1698267962

I don't claim to know what's the cause (it's probably use of the
function in inline implementation), but I do know the fix, and that's to
put `inline` on the _declaration_, but _not_ the definition. While it
doesn't hurt to put it on the definition, it's exactly this practice
that lets other platforms compile this code that MinGW then out of a
sudden starts to complain about. By _not_ putting `inline` on the
definition, only on the declaration, we cause all platforms to complain
if we get it wrong ("multiple definition errors at link time" or "inline
function not defined").

So, if we want this as a minimal-complexity rule:

- the `inline` keyword goes _only_ on declarations, never on definitions
- the `inline` keyword should be omitted on the following declarations:
   - of constexpr functions (they're implicitly inline)
   - of consteval functions (ditto)
   - of in-class-body member function definitions (they, too, are
implicitly inline)

Please add this to your things to look out for in reviews.

Thanks,
Marc

--
Marc Mutz 
Principal Software Engineer

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

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

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

Re: [Development] QtFluentMQ

[Volker Hilsheimer via Development]

Hello QtFluentMQ Team,

The project as you have described it sounds very cool and could be interesting 
for many Qt users building distributed systems. So thanks for the work so far 
and for reaching out!

As for providing a repository on our gerrit server for your project, and 
perhaps moving it under the governance of the Qt project: As per 
https://wiki.qt.io/Requesting_New_Repositories, the repository location depends 
on whether we agree that this project should become part of the Qt 
distribution, and how quickly this could possibly happen. This requires some 
discussion with a few people in the project, and in The Qt Company. E.g. we 
need to see how the licensing works out, and involve the team that would have 
to support commercial license holders when they start using the module and have 
questions, or want to report bugs. Also, the environment required to run the 
auto tests for this project might need to be discussed with our CI team. And by 
moving the project under Qt Project governance, you’d agree to develop this 
project in a way that it meets our compatibility commitments, platform and 
compiler support plans, release processes etc.

If that is the ambition in the longer term, but you’d nevertheless want to 
start developing the project as a Qt module, then a repository in the 
playground/ namespace on our gerrit server can be a good start. As pointed out 
on the wiki-page above, the qt-labs/ namespace is a bit special and reserved 
for employees of The Qt Company.

Does the project’s code live anywhere today where we can have a look? That 
would probably be a good start.

Cheers,
Volker


On 23 Aug 2023, at 14:41, team fluentmq  wrote:

Hello,

I forgot to mention that we're looking forward to a qtlab repository creation 
to migrate the Kafka soruces and developpe the AMQP support project as a Qt 
module.

The design proposal is built around the bridge pattern which is a PIMPL tree. 
We have people rooting for a plugin based arch similar to Qt's RHI design.

Both design provide seamless public API from the user point of view. The latter 
is less popular choice in the team due to type safety issues as the dynamic 
configuration capabilities of the module would require to ignore configurations 
and commands if the feature is not supported by a particular (version of a) MQ 
platform. The bridge design offers stronger type safety thanks to the 
abstraction & PIMPL tree pair.

Please feel free to ask if you need more info on the design details if 
necessary for the voting process.

Br
QtFluentMQ Team



From: team fluentmq
Sent: Thursday, August 17, 2023 4:36 PM
To: development@qt-project.org 
Subject: QtFluentMQ


The "QtFluentMQ" project aims to create a user-friendly and versatile message 
queue (MQ) client using the Qt 6 framework. This client seamlessly handles 
communication with major MQ platforms. The first release would implement the 
AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, IbmMQ, AmazonMQ and 
more. It will also migrate the existing Kafka implementation to Qt to support 
the Kafka platform as well, the current MQ market leader.

At its core, the project involves a top-layer abstraction called QMQInstance. 
This layer acts as a bridge between the application and various MQ platforms. 
Within this layer, there are two main components: QConsumer and QProducer, 
which can also be referred to as QQmlConsumer and QQmlProducer when working 
with QML.

QMQInstance provides a unified QMessage Interface that simplifies the process 
of sending and receiving data to and from different MQ brokers. This uniform 
interface streamlines the interaction with multiple MQ platforms, making it 
easier for developers to integrate messaging functionality into their 
applications.

One of the standout features of this project is its dynamic configurability. 
The client can be configured through a JSON input, which can either be provided 
in memory or via a stream. This flexibility allows developers to adapt the 
client's behavior to specific use cases and requirements without significant 
code changes.

Additionally, the project supports queues context switching. This means that 
the client can seamlessly switch between different queues or channels within 
the MQ platforms. This feature is particularly useful for managing multiple 
communication channels efficiently and ensuring the smooth flow of data.

Finally, the QtFluentMQ actively supports open-source initiatives like 
Plumber, a versatile CLI tool for 
seamless interaction with various messaging systems, including Kafka and 
RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the 
CI/CD process by offering an all-in-one tooling package that streamlines 
operations and simplifies integration tasks."

In summary, QtFluentMQ project offers a comprehensive and easy-to-use solution 
for interacting with various MQ platforms. Its abstraction 

Re: [Development] How to use `init-repository` properly to clean up the working tree after checking out?

[Volker Hilsheimer via Development]

On 23 Aug 2023, at 08:35, Haowei Hsu  wrote:

Hello, Thiago.

No, I mean, why do you want to get Qt 6.2.4 in the first place?

I didn't say that it had to be 6.2.4. In fact, I've also tried to build other 
Qt6 releases, such as: 6.1, 6.3, 6.5... etc.
However, I found during the process that when I initialize submodules in the 
dev branch and then checkout to the 6.2.4 branch, the issue arises:

The two redundant submodules, qtlocation and qtspeech, remain,
which causes problems when using configure.bat and building targets.

Therefore, I want to figure out why it happened and how to solve it.

The problem is that Qt Location and Qt Speech were brought back into Qt after 
6.2, so if the super-repository is checked out to e.g. the 6.2.4 tag after 
being checked out to a revision where they did exist (such as dev), then they 
become inactive in the .gitmodules files (as opposed to be removed entirely, 
like qtgrpc, which never existed before it was added), but they are still in 
your worktree.

However, any `git submodule` operations will not touch them. The top level 
build system however cares about code that’s actually there, not about git. It 
iterates over each subdirectory with a CMakeLists.txt file and adds that to the 
build. So it will try to build e.g. qtlocation. And since that remained checked 
out at a current revision, and depends on a corresponding qtbase version that 
is no longer checked out, it can’t be built.

You won’t have that kind of problem with projects that don’t use submodules, or 
where the list of submodules doesn’t change between interesting revisions. I 
don’t know in which category cmake falls.

I avoid changing my checkout of Qt repositories, and of qt5.git in particular, 
and instead use worktrees for the branches that I care about. Otherwise I’d 
have to rebuild the whole world every time I want to move between dev and a 
stable branch. And I use worktrees because then I can cherry-pick locally 
between branches.

You can use that as well:

To build a specific Qt version, add a worktree for your qt5.git clone:

```
$ cd ~/qt/qt5 # your clone of qt5.git
$ git worktree add ~/qt/6.2.4 6.2.4
$ cd ~/qt/6.2.4
$ ./init-repository -f
```

If you use `git submodule update —recursive` instead of init-repository, then 
you will still end up with qtlocation and qtspeech being cloned and checked out 
to an old, probably pre-port revision. But they won’t have a CMakeLists.txt 
file as they weren’t ported yet, so configure and the toplevel build system 
should ignore them.

(Note: this will not create worktrees for the submodules, but instead clone 
them; my local setup adds a worktree for each submodule explicitly, messing up 
the corresponding qt5.git status, but I don’t care because all I want from that 
is the toplevel build system).

Volker

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

Re: [Development] BC/SC in patch releases (particularly enum additions)

[Volker Hilsheimer via Development]

> On 23 Aug 2023, at 15:09, Edward Welbourne via Development 
>  wrote:
> 
> Lars Knoll (23 August 2023 13:32) wrote
>> We have been adding new enum values in certain cases. The operating
>> system versions needing to be amended to support a new version of
>> macOS is one example. That has happened a couple of times within LTS
>> releases as far as I remember.
>> 
>> We’ve also once or twice upgraded CLDR or Unicode versions within
>> patch level releases to fix serious bugs, and I believe have in that
>> process also added new enum values.
> 
> On 23 Aug 2023, at 11:48, Edward Welbourne wrote:
>>> I agree with Marc that we should, at the very least, be clearer about
>>> what exactly our policy is - and stick to it,
> 
>> I agree with that, but would propose to amend our policy and
>> explicitly allow adding enum values in those limited cases. Updates to
>> Unicode data, supporting new OS versions and maybe a few other limited
>> cases come to my mind here.
> 
> Sounds like an update to QUIP 6, or possibly a new QUIP superseding it.
> https://contribute.qt-project.org/quips/6


As QUIP 6 focuses specifically on SiC changes between minor releases, and since 
the technicalities that influence what we can do within a patch cycle (in 
particular our ambition to maintain forward binary compatibility) are somewhat 
different from that, a separate QUIP might be cleaner.


> So we have
> 
> * QOperatingSystemVersion
>  Not an enum; { OSType, int, int, int } tuple, with a mass of constants
>  of this type to behave a bit like an enum. Adds one such constant for
>  each newly supported OS version.
> 
> * QChar (UCD) enums:
>  - UnicodeVersion -- updates whenever we upgrade
>  - Script -- also tangles with HarfBuzz's enum hb_script_t
> 
>  Those both routinely update.  In principle, any of CombiningClass,
>  JoiningType, Decomposition, Direction, Category may get new members in
>  a new Unicode release, too.
> 
> * QLocale (CLDR) enums:
>  - Language, Script, Territory
> 
> (Peculiarly, QLocale::Script and QChar::Script never seem to cross paths.)
> 
> In searching for the HarfBuzz tie-in to QChar (which I remember from
> doing some UCD updates) I didn't find anything in QFont's public API
> that was obviously affected, but that may just reveal the depth of my
> ignorance of fonts.
> 
> I inevitably wonder whether anyone else involved in 3rdparty updates has
> other examples where an external update extends enums (or other families
> of names) in our public APIs.  Please speak up if you know of any.
> 
> 
> The other question that arises is: do we try to formulate some
> generalised characterisation of the circumstances under which this
> policy applies - public API exposing details of third-party reality - or
> do we simply document a list of cases where exceptions are permitted ?
> In the latter case, each extension would require a QUIP update; which
> conservatively may be considered good, but may be found tiresome in
> practice.  A general rule would allow Maintainers to exercise judgement,
> possibly in conference with their peers.

If we focus such a QUIP exclusively on where we allow what kind of additions 
within a patch cycle, then I think we should be explicit about each case, and 
have a good change process for each addition. I can, from the top of my head, 
not come up with more than what you listed above. Everything else is not 
allowed.


Volker

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

[Development] Nominating for approver: commentby vs reviewedby vs reviewer search operators

[Volker Hilsheimer via Development]

Hi,

Emails in which we nominate contributors for Approver status usually have two 
queries: the list of changes owned [1], and the list of changes that the 
nominee reviewed [2].

[1] https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io
[2] https://codereview.qt-project.org/q/reviewer:volker.hilsheimer%2540qt.io

The first query should be pretty clear: all changes I owned, which is usually 
all changes I authored.

However, the second query selects all changes on which I was added as a 
reviewer, no matter whether I actually provided any input. So the list produced 
by [2] includes

https://codereview.qt-project.org/c/qt/qtdeclarative/+/496546

even though I didn’t provide any input to this change.

Being added as a reviewer by other contributors is a sign of trust. However, 
for the sake of evaluating a nomination, perhaps we want to get an idea of how 
much someone actually participated in code reviews.

Gerrit provides two selectors to get a list of changes where someone actually 
participated: reviewedby [3] and commentby [4]:

[3] https://codereview.qt-project.org/q/reviewedby:volker.hilsheimer%2540qt.io
[4] https://codereview.qt-project.org/q/commentby:volker.hilsheimer%2540qt.io

The former lists all the changes for which I voted on any of the patch sets (it 
doesn’t have to be the patch set that ultimately got merged). The latter lists 
all changes where I made a comment. The list produced by [3] doesn’t include 
https://codereview.qt-project.org/c/qt/qtbase/+/489071 (even though I 
commented), while the list produced by [4] does.

Commenting is very valuable, even when not voting. And voting implies 
commenting, e.g. the list from [4] does include 
https://codereview.qt-project.org/c/qt/qtopcua/+/496329, where I only voted but 
didn’t leave a comment.

Hence, I’d like to propose that nomination emails include the two links as per 
[1] and [4], using `owner` and `commentby` search operators.


Volker

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

Re: [Development] Nominating Kwanghyo Park as approver

[Volker Hilsheimer via Development]

+1

Disclaimer: Kwanghyo reports (indirectly) to me.

Volker


On 14 Aug 2023, at 08:54, Tomi Korpipää via Development 
 wrote:

Hi,

I'd like to nominate Kwanghyo Park for approver status. He is the main 
developer for Surface3D graphs for the QtGraphs module, and has been 
contributing to QtDataVisualization, QtQuick3D, and QtLottie as well.

https://codereview.qt-project.org/q/owner:kwanghyo.park%2540qt.io
https://codereview.qt-project.org/q/reviewer:kwanghyo.park%2540qt.io

He has been and continues being a productive member of the Oulu Graphics team.

Tomi Korpipää
Senior Manager, R
The Qt Company Oy
Tutkijantie 4C
90590 Oulu
Finland
tomi.korpi...@qt.io
+358445312522
www.qt.io
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/Qt-Group-logo-black.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook-x2-right_2023-03-01-095511_zhlr.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter-x2.png] 
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin-x2.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube-x2.png] 


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

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

Re: [Development] std::optional for Q_PROPERTY

[Volker Hilsheimer via Development]

> On 20 Jul 2023, at 16:17, Fabian Kosmale via Development 
>  wrote:
>> Hi everyone,
>> 
>> something that came up during this year’s KDE Akademy was that we
>> believe Q_PROPERTY should be able to handle std::optional, such that you
>> get a null QVariant out of it if it has no value. The main use case
>> being interfacing “more modern C++” with QML in a type-safe way, rather
>> than using QJSValue::Undefined for invalid results.
>> 

[…]

>> Is that something that we would like to see? I was told that a QMetaType
>> is “full” and version bump needs to happen first before it can be
>> extended or something?
>> 
>> Cheers
>> Kai Uwe
> 
> Hi,
> 
> as far as QMetaType is concerned: We need a way to have some introspection on
> the "contained" type. That can't really be shoehorned into the current
> QMetaTypeInterface, because that one has neither enough space, nor a
> useable function pointer that could be hijacked.
> However, incrementing the QMetaTypeInterface revision and appending a new
> member is possible (QMTI has been written with extensibility in mind), and 
> then
> you can add another function pointer to e.g. retrieve QMetaType::fromType()
> if you have QMetaType::fromType>. Gettnig that in should be
> mostly straightforward.

[…]

> In general, I think having a way to expose optional value in a nice way is
> worthwhile, but I'm currently not sure what the best way forward would be.


Agree that supporting std::optional would be useful!

> At the QML layer, we would need to have some discussion on how to map the
> values. Should a std::optional be "undefined if it's nullopt, and behave
> like Q_PROPERTY of type T otherwise"?

With `maybeValue` being a `Q_PROPERTY(std::optional …)`,

object->property(“maybeValue”);

would return a null-QVariant if the property is nullopt, which maps to 
undefined in QML. But should it hold a std::optional or a T otherwise? QML 
needs a T; and on the C++ side we should probably keep the complete type 
information (and .value() will have to return the same thing either way).


How about conversion:

QVariant(std::optional>).value(); // return U{} if T cannot be 
converted; otherwise U(T);

QVariant().value>(); // nullopt, not a std::optional 
holding a T{}
QVariant(42).value>(); // std::optional holding 42
QVariant(QSize()).value>(); // probably nullopt?


> That would mostly work, unless you want
> a RESETable property, where RESET shouldn't lead to a nullopt value.



Reseting a property should reset to what it was when the object was newly 
constructed, which would probably have been nullopt. Why is it problematic it 
RESETing a std::optional produces something else than nullopt?


> Should nullopt be mapped to null instead (but then you can't distinguish
> nullopt and nullptr). Or should we have optional in QML in the same
> way we have list? That would require defining its interaction with
> JS code.



Setting such a property to undefined should produce a std::nullopt on the C++ 
side, I think. And symmetrically, the value of a nullopt property should be 
undefined on the QML/JS side.


>> The question is also, where do we draw the line: I could see a use for
>> having an std::variant property for when we have a known set of types we
>> accept (e.g. std::variant). Again something where we
>> currently would do a QVariant with manual conversions and missing
>> introspection.


Can you elaborate on that? What kind of introspection are you missing? Are you 
looking for a type-error on the caller (i.e. QML) side? E.g. if the property is 
of type std::variant, and QML tries to set it to something 
else? What if that “something else" can be converted to a QString?

Volker

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

Re: [Development] Behavior-changing bugfixes in patch-level releases

[Volker Hilsheimer via Development]

> On 12 Jul 2023, at 09:52, EXT Mitch Curtis via Development 
>  wrote:
> 
> Hi Arno,
>> 
>> Hey everyone,
>> 
>> what is the policy for adding behavior-changing bugfixes to patch-level
>> releases? Is this something to expect?
>> At the moment we operate under the assumption that bumping the patch-
>> level of Qt is pretty much a no-brainer and can be done without having to do
>> much in the way of validation.
>> 
>> If behavior changes in patch-level releases are to be expected, we'll have 
>> to be
>> more careful with bumping Qt.
>> 
> 
> I'm sorry to hear that.
> 
> As the developer who approved the change, I've left my thoughts here:
> 
> https://bugreports.qt.io/browse/QTBUG-114166?focusedId=734562=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-734562
> 
> In summary, I believe the official branch policy was followed here.

Without going into the details of this particular change:

The branch policy lives on 
http://quips-qt-io.herokuapp.com/quip-0016-branch-policy.html and deliberately 
leaves room for interpretation and case-by-case decision making. From a certain 
point of view, any bug fix can be seen as a behavior change, and side effects 
are not unusual, and not always expected or wanted. If a patch comes with a 
ChangeLog entry, then bringing it back into an “LTS Strict” (or even “Very 
Strict”) branch should not be done lightly. But in general, we do want to be 
able to make such fixes also in older branches.

We do generate release notes for patch release, i.e. 
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.5.1/release-note.md 
where this particular change is included in the “Important Changes” section: 
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.5.1/release-note.md#qtdeclarative

The intention of those notes is to make it easier for people upgrading to 
evaluate the impact, and to decide whether some extra testing needs to be done 
before rolling the new version out to everyone.

But maybe this is not the most effective way to communicate changes like this. 
Are these notes easy enough to find? Is a single “Important Changes” section 
sufficient, or do we need more differentiation? Some important changes are 
marked as such because they fix a bad bug, others might be marked as important 
because they might require adaptation in existing code that relies on previous 
behavior. They are all marked as "Important Behavior Change” in the commit log, 
and usually with a module or even type name (in this case, 
"[ChangeLog][QtQuick][ListView][Important Behavior Change]”). Our commit 
template suggests “[ChangeLog][module][class/topic]”.

Perhaps the release-notes generation script could group things a bit better, at 
least by module rather than by repository, and also including the class/topic.

Ideas on how we can make this better are very welcome.

Volker


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

Re: [Development] Module maintainers: QT_NO_CONTEXTLESS_CONNECT in your modules

[Volker Hilsheimer via Development]

> Am 10.07.2023 um 18:02 schrieb Giuseppe D'Angelo via Development:
>> Hi,
>> 
>> https://codereview.qt-project.org/c/qt/qtbase/+/487560 introduces 
>> QT_NO_CONTEXTLESS_CONNECT , a macro that disables the 3-arguments connect -- 
>> in other words, it disables the
>> 
>>>   QObject::connect(sender, signal, functor)
>> 
>> overload, leaving only 4/5 argument(s) overloads
>> 
>>> QObject::connect(sender, signal, receiver/context, functor/slot, (type))
>> 
>> 
>> as well as the string-based connect().
>> 
>> 
>> The reason for NOT using the 3-args overload is that it is error prone.
>> 
>> For starters, it makes it hard to reason about the lifetime of such a 
>> connection. It makes it very easy to connect to lambdas that capture some 
>> local state in the receiver, but when the receiver is destroyed, the 
>> connection isn't automatically disconnected (therefore, if the signal is 
>> emitted, the program will crash). Fixing this may or may not be 
>> straightforward, depending on how much state is captured.
>> 
>> Second, it's also easy to forget that since there's no receiver/context, the 
>> connection is always forced to be *direct*, which complicates things if 
>> multiple threads are involved.
>> 
>> -- 
>> 
>> I'm about to enable the macro for (most) of QtBase:
>> 
>> https://codereview.qt-project.org/c/qt/qtbase/+/489232
>> 
>> I've also done the exercise of enabling it for qtdeclarative (patches 
>> pending) and qttools (merged), but there's simply too much code out there 
>> that *still* uses it. As I said above, fixes are not always obvious 
>> (sometimes it's very unclear who the "receiver" is).
>> 
>> -- 
>> 
>> Since this is ultimately a code style issue, I'd like to leave the decision 
>> with the module maintainers regarding whether or not enable 
>> QT_NO_CONTEXTLESS_CONNECT for their own modules. Ideally, however, we should 
>> enable it in headersclean, so please make at least those not contain 3-args 
>> connect().
>> 

> On 11 Jul 2023, at 11:56, Hasselmann Mathias via Development 
>  wrote:
> 
> Hi Peppe,
> 
> thank you alot for this highly appreciated and super useful feature!
> Give up counting how often I forgot the context argument.
> 

Thanks Peppe for taking the initiative!

The change has now merged for qtbase, and given the war stories shared here it 
would indeed be great if we can all clean up the remaining modules so that we 
can enable this as widely as possible.

Volker

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

Re: [Development] Unity Build on CI for Qt Base for 3 Platforms

[Volker Hilsheimer via Development]

On 26 Jun 2023, at 09:39, EXT Amir Abdol via Development 
 wrote:


Hi,

Unity Build is now enabled on CI for Qt Base, on dev branch, for the following 
platforms: INTEGRITY, Windows 10 MinGW, Windows 11 MinGW, which are among the 
slowest platforms on our CI.

Here is a brief note about the unity build, and what you should expect:

  *   Unity build achieves a faster build by pooling several source files into 
one translation unit and compiling that instead of individually compiling every 
source file. This means the build is especially susceptible to duplicate symbol 
collision. If you notice such instances,
 *   Try resolving the issue, as it is often achievable in a reasonable 
timeframe. If not,
 *   You can exclude the file from the unity build, by adding it to 
NO_UNITY_BUILD_SOURCES, which is available in most of our qt_internal_* CMake 
APIs, e.g., qt_internal_add_tool. When doing so, please leave a brief comment 
and/or TODO on why/how to resolve the issue.
 *   If an entire target is troublesome, and resolving the issue needs 
major work, you can exclude it from the unity build by passing NO_UNITY_BUILDto 
the respective qt_internal_* call.
  *   You can enable the unity build locally by passing -unity-build and 
-unity-build-batch-size to configure, or use -DQT_UNITY_BUILDif you are using 
CMake. Default batch size is 32.
  *   We have tested the build with batch size of 32. Changing the batch size 
may result in undiscovered symbol collisions, or other issues.
  *   Tests and examples are not being built using unity build at the moment.

While at the moment, we are only partially enabling the unity build for Qt Base 
on CI, the build should be successful on other platforms as well. Other Qt 
modules can be built with unity build as well, with varying degrees of success. 
Please give it a try, and let us know if you ran into issues, either by opening 
a bug report, or submitting a patch!

P.S. Unity build for Qt was initially discussed here: 
https://lists.qt-project.org/pipermail/development/2023-January/043518.html.

Best,

Amir

Very nice, thanks a lot!

Cheers,
Volker


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

Re: [Development] Meeting minutes from Qt Release Team meeting 20.06.2023

[Volker Hilsheimer via Development]

On 20 Jun 2023, at 16:24, Arno Rehn  wrote:

On 20.06.2023 16:12, Jani Heikkinen via Development wrote:
Qt 6.5 status:
-  Branching from '6.5' to '6.5.2' done
- Qt 6.5.2 content is not frozen yet. The target is to freeze the Qt 6.5.2 
content later this week
- The target is to release Qt 6.5.2 Wed 28th June

Will we have to pick to 6.5.2 manually or will changes that are currently 
targeting 6.5 be picked automatically?

Regards,
Arno

For changes that aren’t merged yet, the 6.5.2 branch has to be in the list of 
pick-to targets (that has been necessary since we branched 6.5.2 off on June 
14th), and those cherry-picks have to then be accepted by the release team (as 
only they can stage changes to that branch).

Changes that have been merged after the branch-off date, but without 6.5.2 as a 
pick-to target, you can manually cherry-pick. Add Jani or Tarja as a reviewer, 
and if critical enough, give the respective JIRA ticket (or a new JIRA ticket 
if that’s what it takes) P0 priority with 6.5.2 as the fix-version.


Volker


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

Re: [Development] API style guide: scoped enum or not?

[Volker Hilsheimer via Development]

> On 14 Jun 2023, at 14:59, Marc Mutz via Development 
>  wrote:

[…]

> C) scoped enums SHOULD NOT repeat (part of) an enum's type name in the 
> enumerators²

[…]

> I have been told today that QML allows scoped C++ enums to be used 
> without the scope. If this is true, it should be fixed to always require 
> the scope, because otherwise the argument goes "but in QML, the scope 
> isn't visible, so a part of the enum type name must be included in the 
> enumerators”.

What’s the view from the QML maintainers on this particular point? 

That QML allows using an enum value without scope if the C++ enum is scoped 
seems like a bug to me, although I assume that changing this will come with 
some incompatibility fallout.

Volker

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

Re: [Development] Recommended way to take in strings

[Volker Hilsheimer via Development]

On 31 May 2023, at 16:05, Thiago Macieira  wrote:

On Wednesday, 31 May 2023 00:17:21 PDT Marc Mutz via Development wrote:
I doubt there's an accepted project-wide standard, yet, but as a rule of
thumb that everyone might be able to agree on: If the function doesn't
store the string as-is (=parses or pre-processes it), take by
QAnyStringView, otherwise continue to take by QString cref.

I want to be very clear on that: the function's *purpose* must be to parse the
string in question and act on it immediately. It shouldn't be about what the
implementation is currently, but about what the function is.


This is as clear a guideline as it gets, IMHO. Attempts to clarify this further 
by example or e.g. using the function's name as a guideline, are IMHO rather 
making it less clear. It’s either way a rule of thumb that will give the 
correct API in the vast majority of cases. For the corner cases, we have code, 
API, and header reviews (*).

Added the essence to https://wiki.qt.io/API_Design_Principles.

The comments about overloads, taking addresses of Qt entities, or explicitly 
specifying deducible template parameters are all valid, also outside the 
specific question.

Volker

(*) which would benefit from more eyeballs at 
https://codereview.qt-project.org/q/topic:api-change-review-6.6

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

Re: [Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

[Volker Hilsheimer via Development]

> On 16 Jun 2023, at 20:25, Thiago Macieira  wrote:
> 
> On Friday, 16 June 2023 11:05:30 PDT Giuseppe D'Angelo via Development wrote:
>> On 16/06/2023 18:00, Thiago Macieira wrote:
>>> On Friday, 16 June 2023 01:06:33 PDT Stephen Kelly wrote:
 Make sure you're not hitting
 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117
>>> 
>>> We are indeed hitting that. But there's nothing we can currently do about
>>> it.
>> Why can't we turn Q_DECL_EXPORT to [[gnu::visibility("default")]] to
>> work around the bug?
> 
> Marc to comment, but I don't think it solves the MSVC problem we're also 
> hitting, which means that adding no_discard to classes is still a problem. 
> Therefore, there's no point in changing our Q_DECL_EXPORT.
> 
> We'd also need to change *all* our __attributes__, not just the visibility 
> ones, and we still risk breaking users' code that have __attributes__ in 
> their 
> classes and especially functions but use Q_DECL_EXPORT.
> 
> Think of declarations like:
> 
> [[nodiscard]] Q_CORE_EXPORT Q_DECL_PURE_FUNCTION qsizetype qustrlen(const 
> char16_t *str) noexcept;

My take-away is: What we should care about is the small set of RAII classes 
where the side-effects of the constructor and destructor are the whole point. 
E.g. it would be good if we can reliably encourage a compiler warning for 
Listing 1:

QMutexLocker();

because that mistake is easily made and positively harmful.

From what I get out of this recap of the state of standard and compilers, it 
seems that we can't: class-level [[nodiscard]] doesn’t give us that warning 
(reliably, on all compilers), while it does give us warnings that we might not 
want (ie when not using the return value of a function). And it’s problematic 
to use with whole-sale exported classes; but since RAII types like QMutexLocker 
shouldn’t be exported whole-sale anyway, that’s perhaps not a problem in 
practice.

So, agree with Marc’s proposal to drop (or at least not add any new) usage of 
class-level [[nodiscard]], and to use constructor-level [[nodiscard]] instead 
via Q_NODISCARD_CTOR (*). This still makes it a good service to Qt users that 
are on C++ 20. For everyone else, things are as they were before.

For all other types, I think it’s quite alright that users writing code as per 
Marc's Listings 2-4:

   QSize(12, 32);

have to figure out the “hard" way why there is no variable to pass into the 
function that they were planning on calling.

Volker

(*)  That macro that does nothing until C++20 anyway, so I’d also add the 
support for the optional string-literal that C++20 also introduces..


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

Re: [Development] API style guide: scoped enum or not?

[Volker Hilsheimer via Development]

+1 to A and C.

> On 14 Jun 2023, at 21:49, Allan Sandfeld Jensen  wrote:
> 
> On Mittwoch, 14. Juni 2023 17:48:27 CEST Thiago Macieira wrote:
>> On Wednesday, 14 June 2023 08:35:16 PDT Marc Mutz via Development wrote:
>> B) new enums MUST be scoped, also when nested in classes¹²
> 
> -1 Disagree
 
 -1 Disagree
>>> 
>>> Ok. But _why_? (Q to both)
>> 
>> I'm inclined to agree with (B), so I'd like to understand the objections.
> 
> As discussed earlier. Better naming in many cases until we can depend on
> C++20 in API. I disagree with designing API for standards we are not yet 
> allowed to use. And there are a few rare cases with flags or other composite 
> value types, where the implicit casting is desirable. I wouldn't mind saying 
> scoped enums are the preferred default, and any unscoped enum needs to be 
> justified in the commit message, but I would hate to ban them out right. 
> 
> Best regards
> Allan


-1 to B from me as well.

We can allow unscoped enum as an acceptable (if explained) exception from the 
rule of using scoped enums. Otherwise we remove a tool from our toolbox, even 
if it has it’s uses in certain (increasingly rare, perhaps) situations.

More importantly, I don’t agree with the footnoted proposal of making all 
currently unscoped enums scoped in Qt 7. Such a change would cause a massive 
porting effort (tool or not), with zero value for users. There might be 
exceptions where we have genuine issues from certain enums being unscoped, we 
can fix those with appropriate porting aids and compatibility wrappers/aliases.

Volker

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

Re: [Development] Execute a function in the specified existing thread

[Volker Hilsheimer via Development]

On 9 Jun 2023, at 02:00, Thiago Macieira  wrote:

On Wednesday, 7 June 2023 19:18:02 PDT JiDe Zhang wrote:
please make sure your contribution uses QMetaCallEvent.

Why uses QMetaCallEvent? I don't know how to make the function arguments to
void** for QMetaCallEvent constructor. Maybe I can use
QAbstractMetaCallEvent.

My point is that a contribution to QtCore should use the most efficient method
of getting the job done without undue complexity. That means I can accept
inefficiencies provided they make the code more readable & maintainable than
otherwise would have been, but not if they aren't justified.

As of https://codereview.qt-project.org/c/qt/qtbase/+/469799, creating a 
QMetaCallEvent is pretty straight-forward.

And creating the QCallableObject needed for that is also easier by the 
makeSlotObject helper, see 
https://codereview.qt-project.org/c/qt/qtbase/+/475547.

It’s still requires working with private APIs, but there’s a reason those APIs 
exist, and that they are private - there are many cases you want to support 
(functors and lambdas, member-function-pointers, free functions, move-only 
functors etc).

Volker

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

Re: [Development] Execute a function in the specified existing thread

[Volker Hilsheimer via Development]

> On 7 Jun 2023, at 17:20, Thiago Macieira  wrote:
> 
> On Wednesday, 7 June 2023 01:53:47 PDT JiDe Zhang wrote:
>> I am writing a tool to allowed call a function in the specified existing
>> thread, I want to contribution it to Qt project, are you like?
> 
> We do this internally, but don't usually expose it. If you're going to 
> contribute it, please make sure your contribution uses QMetaCallEvent.
> 
> Anyway, the important question is whether you have the QThread for that 
> thread 
> or an object that lives in that thread. If you have the latter, it's already 
> easy to do so:
> 
>  QMetaObject::invokeMethod(obj, Qt::QueuedConnection, [] { doSomething(); });


Fabian had the idea of injecting an event into a thread’s event queue, without 
needing a receiver object to post the event to:

https://codereview.qt-project.org/c/qt/qtbase/+/470488

This came out of the recent improvements to e.g. QTimer::singleShot event and 
QCoreApplication::requestPermission, where we have to create a receiver object  
just so that we can post the QMetaCallEvent to the correct event queue. By 
allowing metacall events in the queue without receiver, we could remove that 
overhead.

With such a mechanism we could easily implement a “run callable in thread” (or 
"in thread of given object") API without creating the kind of “Caller” object 
your implementation has. To supporting the various callables we can use in 
connections or callback-APIs, the changes we recent made to qobjectdefs_impl.h, 
esp QtPrivate::QCallableObject and QtPrivate::makeCallableObject) should give 
us the higher-level building blocks.

Volker

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

Re: [Development] Continue staging restrictions in qt/qt5 dev branch?

[Volker Hilsheimer via Development]

On 5 Jun 2023, at 09:11, Jukka Jokiniva via Development 
 wrote:

Hi,

There are quite many changes trying make it to the qt/qt5 dev branch:
https://codereview.qt-project.org/q/project:qt/qt5+branch:dev+is:open

If everyone starts to stage these individually, I am afraid that nothing will 
get merged because of the flakiness and we just overload the CI.

Would it make sense to continue the staging restrictions in the qt/qt5 dev 
branch and assign a person from the release or ci team to (re-)stage the 
changes in a specific order?

--Jukka


Restricting staging to the qt5.git repo to members of the release team for a 
limited period is fine, esp now right after the 6.6 branching and until we have 
a snapshot out of that branch.

Perhaps that list of pending changes would benefit from some cleaning up. I 
assume stuff from 2021 and also 2022 can be abandoned.

Volker


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

Re: [Development] Requesting Feature Freeze Exception for C++20 comparison

[Volker Hilsheimer via Development]

> On 4 Jun 2023, at 23:26, Thiago Macieira  wrote:
> 
> On Sunday, 4 June 2023 11:51:54 PDT Marc Mutz via Development wrote:
>>> The other problem is I want to take a second, thorough look at your
>>> #ifdefs
>>> for C++20. I have a feeling some of the changing return types are a recipe
>>> for binary compatibility problems, if not in our own code, then in code
>>> that uses our code. I need to sit down and think about whether this is a
>>> valid scenario or not.
>> 
>> All functions that alternate between returning Q*Ordering and
>> std::*_ordering must be, and are, inline non-exported.
> 
> And that's exactly what I want to look at. It doesn't affect *our* binary 
> compatibility, but may affect downstream of us. Worse than a clear binary 
> compatibility problem would be a silent data incompatibility problem (in 
> particular, the value of the Unordered constant).
> 
> I don't want to rush this. If you want to preemptively remove the problem by 
> not changing the return type, then one area of my concerns goes away.

Lets continue with this for Qt 6.7.

Even if we agree on the naming and can exclude binary compatibility issues, 
rolling this out to all (or at least a substantial amount of) existing value 
types across submodules is still a larger effort that should then wait for 6.7 
anyway.

Volker


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

Re: [Development] Requesting feature freeze exception to container-assign epic

[Volker Hilsheimer via Development]

> On 3 Jun 2023, at 16:54, Thiago Macieira  wrote:
> 
> On Saturday, 3 June 2023 02:54:49 PDT Marc Mutz via Development wrote:
>> The container-assign epic is partially merged. What's left is
>> QString::assign(), and there only the assign(it, it) part. If we release
>> as-is (with step 1, cf. below), there's a gap in the QString::assign()
>> overload set vis-a-vis all other container classes (Qt or STL).
> 
> Given it's partially done, I would support completing the feature. I would 
> even go far enough to say that it's now not a *new* feature you're still be 
> merging, but completing what you've already got in.

Agree, let’s finish this, what seems to be missing are API overloads, 
documentation updates, and fixes rather than genuinely new functionality.

Volker

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

Re: [Development] Nominating Artem Dyomin as Approver

[Volker Hilsheimer via Development]

+1, he’s doing great.

Disclaimer: Artem sits across the hall from me in the office, works down the 
street from me in home office, and reports to me indirectly.

Volker


From: Development  on behalf of Lars Knoll 

Sent: Saturday, May 27, 2023 5:41:42 PM
To: Qt development mailing list 
Subject: [Development] Nominating Artem Dyomin as Approver

Hi all,

I’d like to nominate Artem Dyomin for approver rights in Qt.

Artem has been working with Qt Multimedia since last summer, doing a very good 
job implementing new features, fixing bugs and refactoring code in the module.

You can see his merged changes here: 
https://codereview.qt-project.org/q/owner:artem.dyomin%2540qt.io+is:merged

And his reviews here: 
https://codereview.qt-project.org/q/reviewer:artem.dyomin%2540qt.io

Cheers,
Lars

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

Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

[Volker Hilsheimer via Development]

> On 4 May 2023, at 12:10, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> I'd like to nominate Eddy as the maintainer for the QLocale and 
> src/corelib/time QtCore subsystems. Eddy is filling that role de-facto 
> already; making it de-jure sounds only logical.
> 
> I asked, and he'd be on board, if we'd have him.
> 
> Anyone else in favour? (I'm not sure I have a vote, actually...)
> 
> Thanks,
> Marc

Eddy is now listed as the maintainer for Locale,Date, and Time on

https://wiki.qt.io/Maintainers#Qt_Maintainers

Congratulations Eddy!

Cheers,
Volker

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

Re: [Development] Nominating Jere Tuliniemi for approver

[Volker Hilsheimer via Development]

> On 12 May 2023, at 09:12, Tomi Korpipää via Development 
>  wrote:
> 
> Hi,
> 
> I'd like to nominate Jere Tuliniemi for approver status. He has been working 
> with Qt for several years, contributing to Qt 3D Studio, ogl-runtime, 
> QtQuick3D, Qt 3D, and QtGraphs to name a few. You can see his commits here: 
> https://codereview.qt-project.org/q/owner:jere.tuliniemi%2540qt.io
> 
> Br,
> Tomi Korpipää


+1

Volker

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

Re: [Development] Qt TextToSpeech API review for Qt 6.6

[Volker Hilsheimer via Development]

I suppose it would have been useful to include date and time information as 
well: Monday, May 22nd, 16:00 CEST.

Volker


> On 13 May 2023, at 14:08, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> I’d be happy for comments and feedback to the C++ and QML APIs we added to 
> the Qt TextToSpeech module for Qt 6.6.
> 
> https://doc-snapshots.qt.io/qt6-dev/whatsnew66.html#qt-texttospeech-module
> https://doc-snapshots.qt.io/qt6-dev/newclasses66.html (new member function in 
> the QTextToSpeech class)
> 
> 
> Link to Microsoft Teams video meeting: 
> https://teams.microsoft.com/l/meetup-join/19%3ameeting_ODhiM2Q1ZGItODQ2Ny00ZjExLWI1YzMtOTM0MjEzNmNjNzdk%40thread.v2/0?context=%7b%22Tid%22%3a%2220d0b167-794d-448a-9d01-aaeccc1124ac%22%2c%22Oid%22%3a%22de5b241e-f1fd-4127-965f-ca90b3f70722%22%7d
> 
> If you have comments or improvement suggestions before, then you’re of course 
> welcome to share them here!
> 
> Cheers,
> Volker
> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

[Development] Qt TextToSpeech API review for Qt 6.6

[Volker Hilsheimer via Development]

Hi,


I’d be happy for comments and feedback to the C++ and QML APIs we added to the 
Qt TextToSpeech module for Qt 6.6.

https://doc-snapshots.qt.io/qt6-dev/whatsnew66.html#qt-texttospeech-module
https://doc-snapshots.qt.io/qt6-dev/newclasses66.html (new member function in 
the QTextToSpeech class)


Link to Microsoft Teams video meeting: 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ODhiM2Q1ZGItODQ2Ny00ZjExLWI1YzMtOTM0MjEzNmNjNzdk%40thread.v2/0?context=%7b%22Tid%22%3a%2220d0b167-794d-448a-9d01-aaeccc1124ac%22%2c%22Oid%22%3a%22de5b241e-f1fd-4127-965f-ca90b3f70722%22%7d

If you have comments or improvement suggestions before, then you’re of course 
welcome to share them here!

Cheers,
Volker

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

Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style

[Volker Hilsheimer via Development]

> On 10 May 2023, at 07:39, Marc Mutz via Development 
>  wrote:
>> 
>> 
>> That said. I find discussing style-guides in general a waste of time, and 
>> will
>> agree to anything that make us stop wasting time on this.
> 
> I tend to agree, but the choice is either to define it centrally, or you 
> repeat these discussions on Gerrit over and over again.


Thanks for the proposals Marc, the list looks good to me.

As for

>>> - space after template and before <:
>>> 
>>>// WRONG
>>>template
>>>// CORRECT:
>>>template 


I was wondering what cppreference suggests, and was delighted to find that the 
first few lines of

https://en.cppreference.com/w/cpp/memory/unique_ptr

manage to have both :) So accepting either, and in particular the no-space form 
that comes out of _clang-format, is fine.


Encoding this in the sanity bot and/or in _clang-format avoids that we waste 
time on this during code review.

Volker

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

Re: [Development] (To what extent) Should we start the API change review earlier ?

[Volker Hilsheimer via Development]

> On 2 May 2023, at 11:36, Edward Welbourne  wrote:
>> This email is the anchor for various topics. I’ll start with a few
>> threads with things that I remember and feel could be improved. If you
>> have something new, please start a new thread in reply to this email, ...
> 
> OK, then (see Subject):
> 
> We could simply start the review earlier.  The only real significance of
> the feature-freeze is that it's the cut-off for changes to API, aside
> from the changes to changed API that get prompted by the review.  So we
> could perfectly well start that earlier, and maybe get some of the fixed
> changes in before feature-freeze.  OTOH, that would be more work for the
> release team, having to update the reviews more times.
> 
> Another approach would be for Maintainers to run the scripts [0] on
> their modules locally and have a look for anything in the result that
> looks like it needs more eye-balls on it.  They can either dig up the
> original gerrit reviews of the changes and drag relevant eye-balls to
> take a look at that, or fake up a commit based on the one the
> api-review-gen script produced, that captures the particular piece(s)
> they want reviewed and push that to gerrit.
> 
> [0] they're in qtqa/scripts/api-review/, stick that in your PATH and run
>api-review-gen --help
>for details.  You'll need the dulwich python package installed.
> 
> Incidentally, if anyone does run these scripts for themselves and finds
> difficulties with that, I'd love to hear from you, via Jira if you think
> it's worth it.  The "break up git modules by Qt module" feature request
> already exists, QTQAINFRA-4763.
> 
> What (else) could we do to make the review run more smoothly and quickly ?


The primary purpose of the header review is to catch *technical* mistakes - BC 
or SC breakages - rather than to discuss API design, naming, or style.

So starting the header review process when we still expect changes might not be 
useful. I think starting it when we are in beta makes sense.

But the reality is that the header review got rather conflated with API review 
(and, as far as template code in headers is concerned, even implementation 
review) in the last iterations. And while that is sometimes ok, the header 
review isn’t the right process to discuss the design of more complex frameworks.

Instead of relying on the header review for that, it would be great if we could 
have more API reviews. For anything non-trivial it helps a lot to have the 
maintainer of the module and/or author of the new stuff walk through the 
changes. The diff that the tools for the header review generate might help 
facilitating that of course. IRC as the lowest common denominator is … not 
great for that; within TQtC we have MS Teams which the build system team used a 
while ago to discuss the new cmake APIs, also inviting contributors outside.

Was that acceptable and useful? Can we do that more? For people outside TQtC 
that have some new API to discuss, someone inside can always help with 
organising, so that we don’t get blocked by some paralysing discussion about 
what platform we should use for this.


Volker

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

Re: [Development] API style guide: scoped enum or not?

[Volker Hilsheimer via Development]

> On 4 May 2023, at 17:34, Marc Mutz via Development 
>  wrote:
> 
> On 04.05.23 15:38, Volker Hilsheimer via Development wrote:
>> Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or 
>> QSlider::Orientation::Horizontal?
> 
> Without looking at the docs, tell me what QSplitterHandle::orientation() 
> means :)

The same that it would mean if it would return Qt::Orientation::Horizontal or 
Qt::HorizontalOrientation :)

I’m guessing: whether the handle gets dragged horizontally or vertically, ie 
the opposite of what one would expect (whether the handle is v horizontal or 
vertical line). In which case the problem is the name of the property not of 
the enum type.

Volker

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

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

[Volker Hilsheimer via Development]

On 3 May 2023, at 19:32, A. Pönitz  wrote:

On Wed, May 03, 2023 at 03:21:40PM +0200, Giuseppe D'Angelo via Development 
wrote:
Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:

What started as an attempt to provide a few building blocks for making it 
easier to build asynchronous APIs taking any kind of callable (like 
QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a 
longer journey to the core.

[1]https://codereview.qt-project.org/c/qt/qtbase/+/470341
[2]https://codereview.qt-project.org/c/qt/qtbase/+/475168

A general problem here is whether we can provide this infrastructure as a
public API. If I have a class of mine and want to provide convenience for
connecting to slots/callables, how do I do it without using private APIs? In
Qt 4 days that was a simple:

 void foo(..., QObject *receiver, const char *slot);

But it's not so simple/possible any more with the PMF syntax.

Something like

   void foo(...,
QObject *guard,
const std::function )

does a sufficiently good job over here.


That helps with specific cases, but for the general-purpose library APIs that 
have the flexibility we are used to in and from Qt, you need to cover when

- continuation is a member function of guard (and then guard has to be the 
right type, which should be enforced at compile time)
- guard lives in a different thread
- guard is destroyed by the time you call continuation

And you have to make things work with move-only functors and mutable lambdas.

Getting all of that right was never particularly easy with a string-based 
syntax either though.

Volker



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

Re: [Development] About the timeline and phases to support C++20 with and in Qt

[Volker Hilsheimer via Development]

> On 3 May 2023, at 19:20, Thiago Macieira  wrote:
> On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote:
>> However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller
>> challenge for compiler vendors to support after C++20. If we stick to the
>> timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025,
>> then perhaps we should skip C++20 and immediately require C++23. People
>> that can move to a C++20 toolchain in 2025 can perhaps just as well move to
>> a C++23 toolchain at that point. That needs more investigation, of course.
>> But given the inevitable pain that comes with changing minimum
>> requirements, moving to a standard that is already 5 years old seems a bit
>> wasteful.
> 
> My opinion on C++23 reasonable features we'd like to use without workarounds:
> * if consteval - not supported by current MSVC
> * deducing this - not supported by any current compiler
> * [[assume]] - we could use this now, https://codereview.qt-project.org/462807
> *  - requires GCC 13 or LLVM libc++ 16
> 
> So my opinion is that aiming for C++23 is not possible for 6.9. For a release 
> in March 2025, the interesting features are too recently supported or can be 
> used without C++23 in the first place. The same goes for the next set of 
> features from C++20 I'd like us to explore ( with GCC 13; 
> std::source_location with libc++ 16, etc.). At best, we'd have the exact same 
> feature set I proposed for C++20, except we'd compile with -std=c++23.
> 
> So, no, I think we should aim for the feature set I posted yesterday from 
> C++20. The question is only when.



My thinking and assumption is: those users that don't upgrade their toolchain 
to something recent are also (typically) the users that stay on the latest LTS 
release. That will be Qt 6.8; what we do in 6.9 and 6.10 and until 6.11 LTS is 
of limited interest to those users. The C++ standard is just one aspect to this.

But those that can and do upgrade their toolchain regularly might just as well 
upgrade to something fairly recent whenever they do that. Between 6.8 branching 
(the last LTS only requiring C++17, as per current plan) and 6.11 (the next LTS 
after that, if we stick to the current cadence), we and compiler vendors have 
another 18 months to work on the C++23 feature set. Why would we not want to 
start using some C++23 features with 6.11 (in H1/26, presumably)? Even if it’s 
only a subset of the standard - what we document is the compiler versions we 
support, and we have to limit ourselves mostly to the common denominator anyway.

For non-LTS releases (or the first after the LTS, i.e. 6.9), we might want to 
bump the minimum compiler versions to something that's not older than 18 months 
(we can argue over that), and we stick to those versions until the following 
LTS release, one year later. And assuming that by H1/2025 there is a common 
subset of the C++23 standard that all compilers support, why would we not use 
those features?

Volker

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

Re: [Development] API style guide: scoped enum or not?

[Volker Hilsheimer via Development]

> On 3 May 2023, at 18:40, Giuseppe D'Angelo via Development 
>  wrote:
>> But sometimes it’s also creating too much verbosity to use a scoped enum 
>> (ie. Qt::Orientation::Horizontal would perhaps not be an improvement).
> 
> I wouldn't consider this tiny bit of extra verbosity a huge impediment. Note 
> that Qt::Horizontal is violating the API naming guidelines. It should've been 
> called Qt::HorizontalOrientation. How is that now better than 
> Qt::Orientation::Horizontal?
> 
> No, Qt::Horizontal isn't "unambiguous" so it can't be non-qualified. Does it 
> refer to what? Text alignment? Text direction? Layout direction? (Hint: none 
> of these.)


Some concepts are abstract enough to be ubiquitous. On/Off, true/false. 
Horizontal and Vertical are IMHO implicitly clear. What it refers to is not 
clear anyway unless you see the code that uses the enum. I can make a slider or 
a layout or a text horizontal or vertical, and it’s IMHO obvious what calls to

textLayout->setOrientation(Qt::Horizontal);
slider->setOrientation(Qt::Vertical);

are doing. The word “Orientation” in the enum itself adds no value.

Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or 
QSlider::Orientation::Horizontal?

I do think that these are the exceptions though.


Cheers,
Volker

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

Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

[Volker Hilsheimer via Development]

> On 4 May 2023, at 12:10, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> I'd like to nominate Eddy as the maintainer for the QLocale and 
> src/corelib/time QtCore subsystems. Eddy is filling that role de-facto 
> already; making it de-jure sounds only logical.
> 
> I asked, and he'd be on board, if we'd have him.
> 
> Anyone else in favour? (I'm not sure I have a vote, actually…)


Absolutely +1.

It’s not a separate item today, but it’s plenty of code, and it requires very 
deep understanding of the domain, and of the various system APIs and libraries. 
So it’s a good idea to break it out of the rest of Qt Core, and Eddy is already 
doing the work.

Volker




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

Re: [Development] About the timeline and phases to support C++20 with and in Qt

[Volker Hilsheimer via Development]

Bumping this thread up in your inboxes as it includes the links to the JIRA 
tickets where the journey towards C++20 has been planned and discussed so far. 
Let's try to build on what we already know.

The standing proposal is to move to C++20 with Qt 6.9, after the next LTS 
release. I see no pressing reasons to accelerate that. The value of the 
features Thiago listed - which excludes all the big stuff anyway - doesn’t seem 
so significant that it outweighs the impact on the community of users that are 
stuck on C++17, for a variety of reasons that we can’t just shrug off.

However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller 
challenge for compiler vendors to support after C++20. If we stick to the 
timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025, then 
perhaps we should skip C++20 and immediately require C++23. People that can 
move to a C++20 toolchain in 2025 can perhaps just as well move to a C++23 
toolchain at that point. That needs more investigation, of course. But given 
the inevitable pain that comes with changing minimum requirements, moving to a 
standard that is already 5 years old seems a bit wasteful.


Volker



> On 21 Dec 2022, at 18:51, Vladimir Minenko via Development 
>  wrote:
> 
> Hello all,
> 
> I want to share on this mailing list a proposal for the timeline and phases 
> to support C++20 with and in Qt. Writing this, I’m aware that there were 
> other discussions about the support of C++20 on this mailing list. This 
> message is a step to get a list of features that all Qt users can expect 
> along a certain timeline. We want to make the landing with the adoption of 
> new C++ standards “softer” than it used to happen in the past, yet prompt 
> enough to make sure that Qt keeps and enlarges its popularity among C++ 
> developers.
> 
> We got four user stories on Qt Bug Reports:
> 
> 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
> 2. C++20 is required for the development of Qt itself - 
> https://bugreports.qt.io/browse/QTBUG-109361
> 3. C++20 is mandatory for users of Qt - 
> https://bugreports.qt.io/browse/QTBUG-109362
> 4. Long term: C++23, Qt7, and unsorted  - 
> https://bugreports.qt.io/browse/QTBUG-109363
> 
> These user stories are linked to selected features from the list once created 
> by Marc in https://bugreports.qt.io/browse/QTBUG-99243
> 
> The above list is sorted in the order of time. Still, a particular "Fix 
> Version” is not set yet. We (all) have to set this, though. ASAP for #1, and 
> by the time we ship the version set in #1, we should set the version for #2, 
> etc. See the list of all releases at 
> https://wiki.qt.io/QtReleasing#Qt_releases
> 
> In addition, there is a task https://bugreports.qt.io/browse/QTBUG-109469 to 
> add a new page or extend an existing page (Supported Platforms?) with details 
> about the support of C++ standards. Plus, we need to get a simple way to test 
> the capabilities of a toolchain, see 
> https://bugreports.qt.io/browse/QTBUG-109470.
> 
> The latter should be a help mainly for Qt users on embedded platforms. Those 
> folks have serious problems again and again with "fast moves” towards new C++ 
> standards since they do not have the luxury of quick updates of compilers and 
> standard libraries as known on desktops.
> 
> Please have a look at the above issues, comment on Qt Bug Reports, and make 
> changes if applicable.
> 
> And now, the most important point ;-) - Merry Christmas and Happy New Year!
> 
> --
> Vladimir Minenko
> vladimir.mine...@qt.io
> +49 171 90 61 461
> 
> Senior Product Manager, Qt Foundation
> The Qt Company - https://qt.io
> 
> c/o Regus / Josephspitalstraße 15
> 80331 Munich, Germany
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

[Volker Hilsheimer via Development]

On 3 May 2023, at 15:21, Giuseppe D'Angelo via Development 
 wrote:

Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:
What started as an attempt to provide a few building blocks for making it 
easier to build asynchronous APIs taking any kind of callable (like 
QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a 
longer journey to the core.
[1]https://codereview.qt-project.org/c/qt/qtbase/+/470341
[2]https://codereview.qt-project.org/c/qt/qtbase/+/475168

A general problem here is whether we can provide this infrastructure as a 
public API. If I have a class of mine and want to provide convenience for 
connecting to slots/callables, how do I do it without using private APIs? In Qt 
4 days that was a simple:

 void foo(..., QObject *receiver, const char *slot);

But it's not so simple/possible any more with the PMF syntax.


Indeed, if we assume that functions-taking-callables are a part of the tools we 
want to use to make more Qt APIs asynchronous, then it’s important that we 
enable other Qt-based libraries to build such APIs as well. One aspect to think 
about is then to make sure that the respective APIs fail early and with good 
error messages when called with incompatible functors etc. For that, I’d rather 
add a library of concepts than making our current predicates and private 
helpers public.

So yes! Ultimately I’d like to provide the required building-blocks as public 
APIs. These changes are a step into that direction, I hope. The plumbing 
required to then correctly make the call to the callable in the right thread is 
still significant, but see also 
https://codereview.qt-project.org/c/qt/qtbase/+/469799 for another small step, 
and Fabian has some ideas about how we could inject a QMetaCallEvent into the 
event loop of the correct thread (without having to create a temporary receiver 
QObject).

Volker

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

[Development] Changes to QObject::connect and other functor-taking API implementations

[Volker Hilsheimer via Development]

Hi,


What started as an attempt to provide a few building blocks for making it 
easier to build asynchronous APIs taking any kind of callable (like 
QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a 
longer journey to the core.

[1] https://codereview.qt-project.org/c/qt/qtbase/+/470341
[2] https://codereview.qt-project.org/c/qt/qtbase/+/475168

Thanks to input and reviews from Thiago, Mårten, and others, the code of 
QObject::connect has now been simplified quite a bit as well.

[3] https://codereview.qt-project.org/c/qt/qtbase/+/475169/8
[4] https://codereview.qt-project.org/c/qt/qtbase/+/475174


Thanks to the very through coverage of those code-paths in qtbase code and 
tests I’m fairly confident that this should go fairly unnoticed for submodules 
and existing applications. Nevertheless, more testing and reviewing is always a 
good thing for changes to these APIs.

So, great if you want to start with an early header review for those APIs in 
particular, and if you run into any problems with your code after these 
changes, please file a P0 JIRA ticket for me.


Cheers,
Volker

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

[Development] Header review process: follow-up on comments

[Volker Hilsheimer via Development]

With Qt 6.5, it’s been a struggle to get people to respond and follow-up to 
comments made during the header review process.

Gerrit doesn’t really care about @user-style mentioning in comments, even 
though is seems that some people assume that it does. Creating JIRA tickets is 
the official way of doing it, but creating a ticket just to get someone’s 
attention to input (which might or might not require a change) seems 
heavy-handed. Ultimately, lots of people will be on cc or review of the 
respective header-review gerrit change, so everything becomes everyone’s 
problem.

Maintainers have a special responsibility during header review, but esp with 
qtbase that is also a lot of people.

What can we do to make this a better process that doesn’t end up with changes 
being made very late (with 6.5 we had some the day before the release 
candidate, IIRC)?

Volker

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

[Development] Template-meta-programming do's and don'ts

[Volker Hilsheimer via Development]

During header review we identified a few cases where e.g. using 
std::conjunction/disjunction wasn’t used, or not used optimally. Using 
suboptimal constructs can result in significant compile-time penalties.

We generally don’t have a lot of guidelines for template-meta-programming. 
Should we have some?


Volker

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

[Development] API style guide: scoped enum or not?

[Volker Hilsheimer via Development]

During the header review, but also in API discussions leading up to it, we had 
a few cases where it would have helped if we had clearer guidelines about when 
to use scoped enums, and when not.

Scoped enums have some clear technical advantages (such as better type safety, 
thanks to no implicit conversion to int). And they sometimes result in better 
APIs when enum values don’t have to repeat the enum’s name in order to be clear.

But sometimes it’s also creating too much verbosity to use a scoped enum (ie. 
Qt::Orientation::Horizontal would perhaps not be an improvement).


Volker

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

[Development] Thread anchor: Discussion of header review improvements

[Volker Hilsheimer via Development]

Hi,

With Qt 6.5 out for a while already, and roughly a month to go until Qt 6.6 
feature freeze and the start of the various activities that lead up to the 
release, it’s perhaps not too early to review some of the pain points we 
experienced with 6.5, and discuss how we can improve.

In particular, the header review was particularly laborious this time around, 
and I would like to see what we can do to make it less so next time around.

This email is the anchor for various topics. I’ll start with a few threads with 
things that I remember and feel could be improved. If you have something new, 
please start a new thread in reply to this email, and if you have anything to 
add to existing threads, please comment.


Cheers,
Volker

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

Re: [Development] Patch to fix qt-multimedia compilation with ALSA

[Volker Hilsheimer via Development]

Hi,

Thanks, but please push patches to our code review system for discussing and 
eventually merging changes:

* https://wiki.qt.io/Qt_Contribution_Guidelines
* https://wiki.qt.io/Setting_up_Gerrit

Regards,
Volker


> On 6 Apr 2023, at 14:16, shengfeng zhou  wrote:
> 
> /var/tmp/build/qt6-6.5.0/qtmultimedia/src/multimedia/alsa/qalsaaudiosink_p.h:98:22:
> error: expected ';' at end of member declaration
>   98 | snd_pcm_access_t access SND_PCM_ACCESS_RW_INTERLEAVED;
>  |  ^~
>  |;
> /var/tmp/build/qt6-6.5.0/qtmultimedia/src/multimedia/alsa/qalsaaudiosink_p.h:98:29:
> error: 'SND_PCM_ACCESS_RW_INTERLEAVED' does not name a type
> 
> --- qt6-6.5.0/qtmultimedia/src/multimedia/alsa/qalsaaudiosink_p.h.orig
>   2023-04-06 19:16:52.046179861 +0800
> +++ qt6-6.5.0/qtmultimedia/src/multimedia/alsa/qalsaaudiosink_p.h
> 2023-04-06 19:29:43.279593508 +0800
> @@ -95,8 +95,8 @@
> qint64 elapsedTimeOffset = 0;
> char* audioBuffer = nullptr;
> snd_pcm_t* handle = nullptr;
> -snd_pcm_access_t access SND_PCM_ACCESS_RW_INTERLEAVED;
> -snd_pcm_format_t pcmformat SND_PCM_FORMAT_S16;
> +snd_pcm_access_t access = SND_PCM_ACCESS_RW_INTERLEAVED;
> +snd_pcm_format_t pcmformat = SND_PCM_FORMAT_S16;
> snd_pcm_hw_params_t *hwparams = nullptr;
> qreal m_volume = 1.0f;
> };
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Volker Hilsheimer via Development]

> On 22 Mar 2023, at 18:58, Christian Ehrlicher  wrote:
> 
> Am 22.03.2023 um 17:35 schrieb Volker Hilsheimer via Development:
>>  But we use toLocal8Bit in plenty of cases as well. For instance in our Qt 
>> SQL APIs.
> 
> The only plugin which really uses toLocal8Bit() is the IBase - Plugin.
> Postgres is using it as fallback but according the docs the utf-8
> encoding is supported by at least PostgreSQL 7.3 so the non utf-8 part
> should be removed.
> 
> The other usages are for qWarning() output.
> 
> 
> Will take a look on the IBase stuff to see if we can replace it.

Indeed, the many hits in the sql code are mostly from warning output, thanks 
for checking.

But that Postgres supports UTF-8 doesn’t mean that an existing server is also 
configured to use it. If a server is configured to work with e.g. ISO_8859_5 
encoding, because all Qt clients (which are likely middleware servers, so fully 
controlled) run on Windows machines with a corresponding code page, then Qt 
deciding to encode in UTF-8 instead will break things, won’t it? And SQL is 
just one example.

Even if one Qt 5 application and one Qt 6 application exchange data over a 
local socket, unwisely using to/fromLocal8Bit for the purpose - if the Qt 5 
application continues to run with the system code page, then the Qt 6 
application starting to sending UTF-8 encoded data will break this.


Volker

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Volker Hilsheimer via Development]

> On 22 Mar 2023, at 12:07, Alvin Wong via Development 
>  wrote:
> On 22/3/2023 17:58, Lars Knoll wrote:
>> Hi,
>> 
>> 
>>> On 21 Mar 2023, at 17:46, Alvin Wong via Development 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Yes, embedding the manifest with activeCodePage set to UTF-8 is the only 
>>> thing need to enable UTF-8 as the ANSI code page (ACP) for the process.
>>> 
>>> Qt itself should work fine after the bug in QStringConverter had been fixed 
>>> [1] a while back. (You can also refer to the linked mail thread. [2]) 
>>> However, as this bug has shown, any code that uses`MultiByteToWideChar` 
>>> incorrectly or wrongly assumes that `CP_ACP` always refers to a charset in 
>>> which each characters are formed by no more than two bytes will break. 
>>> Therefore, before switching to UTF-8 as the ACP, application developers 
>>> have to check their code and other libraries to make sure everything will 
>>> still work properly after the switch.
>>> 
>>> [1]: https://codereview.qt-project.org/c/qt/qtbase/+/412208
>>> [2]: https://lists.qt-project.org/pipermail/interest/2022-May/038241.html
>>> 
>>> About the CRT, it is true that only UCRT fully supports UTF-8 locale. When 
>>> compiling with MSVC, you are almost always using UCRT so it should be fine.
>>> 
>>> MinGW-w64 is a bit more complicated -- when one gets a mingw-w64 toolchain, 
>>> the whole toolchain is already configured for a specific CRT. Usually it 
>>> will be the system MSVCRT. (If it's configured for UCRT, the toolchain 
>>> author will usually make it clear, because compiled programs will not run 
>>> out-of-the-box on Windows 8.1 or earlier.) I did not run tests myself, but 
>>> I would not trust MSVCRT to support UTF-8 ACP fully. mingw-builds [3] and 
>>> llvm-mingw [4] are some examples of mingw-w64 toolchains that ships UCRT 
>>> versions.
>>> 
>>> [3]: https://github.com/niXman/mingw-builds-binaries/releases
>>> [4]: https://github.com/mstorsjo/llvm-mingw
>>> 
>>> There are two more problems with enabling UTF-8 ACP using the manifest that 
>>> I have encountered so far. When a process is running with UTF-8 ACP, there 
>>> seems to be no API available to get the native system ACP. This can be an 
>>> issue if, for example some external tools write files using the system ACP 
>>> and your program wants to read those files. The other problem (a mild 
>>> annoyance) is that, some debuggers which isn't using updated APIs (gdb for 
>>> example) does not capture `OutputDebugString` messages in the correct 
>>> encoding, which affects QDebug output.
>>> 
>>> 
>> I’ve looked into that one when we did the work for Qt 6. The console has its 
>> own code page that can be set independently from the app, and I believe also 
>> independently from the system code page. qDebug() should be mostly fine, as 
>> we’re using OutputDebugStringW() internally and let Windows handle this mess.
>> 
>> What it does affect is writing to stdout/err and OutputDebugStringA(). 
>> 
> It is unfortunately a bit more messy. OutputDebugString communicates with the 
> debugger via a debug event which contains an address, then the debugger reads 
> the debug message from the memory space of the debuggee process.
> The documentation of OutputDebugStringW [1] states:
> "In the past, the operating system did not return Unicode strings through 
> OutputDebugStringW (ASCII strings were returned instead). To force 
> OutputDebugStringW to return Unicode strings, debuggers are required to call 
> the WaitForDebugEventEx function to opt into the new behavior. In this way, 
> the operating system knows that the debugger supports Unicode and is 
> specifically opting into receiving Unicode strings."
> "OutputDebugStringW converts the specified string based on the current system 
> locale information and passes it to OutputDebugStringA to be displayed. As a 
> result, some Unicode characters may not be displayed correctly."
> What happens with a debugger that does not call `WaitForDebugEventEx` (e.g. 
> gdb) is this: The debuggee calls OutputDebugStringW, which converts the debug 
> string to ACP (UTF-8 in this case) to be passed to OutputDebugStringA. Then 
> the debugger receives the event and tries to read the debug string from the 
> debuggee as ACP, but the debugger thinks ACP is the system ACP (Windows-1252, 
> CP950 or whatever) so it ends up displaying mojibake. The same also happens 
> with Sysinternals DebugView.
> In reality, most of the debug messages are ASCII, so this issue rarely 
> affects anything and I consider it just "a mild annoyance".
> [1]: 
> https://learn.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-outputdebugstringw
>> 
>>> (Console output encoding is separate from the ACP, so one might also need 
>>> to call `SetConsoleOutputCP(CP_UTF8)`, but the detail is a bit fuzzy to me.)
>>> 
>> Setting the code page for console output should help when writing to 
>> stdout/err. It’ll require a bit of testing again (it’s been a while since I 
>> looked into 

[Development] Examples to be removed for Qt 6.5? Now is not too early!

[Volker Hilsheimer via Development]

Hi,

As part of the ongoing example revamping activity [1], we are also merging or 
removing some examples. Qt 6.4 shipped with close to 650 examples. That’s a lot 
of examples for users to navigate and grep through, and a lot of code for us to 
maintain and keep relevant.


Some of those were then conceptually outdated, e.g. showing how to keep the UI 
alive during some heavy I/O by calling processEvents, rather than by moving the 
I/O load into a thread, is not a good way of teaching Qt. Others involved a lot 
of boiler-plate code just to show how to use a very specific API in a few lines 
that could just as well have been in the documentation instead.

So, we have converted many examples into documentation snippets, or moved them 
to live on (for now) as manual tests.

If you know of any examples that teach less-than-good ways of using Qt or are 
generally irrelevant, and that should be retired, or merged with other 
examples, please suggest a change, or add a sub-task ticket to 
https://bugreports.qt.io/browse/QTBUG-108751 - we still try to get as much as 
possible of that cleanup done for Qt 6.5.


Thanks,
Volker

[1] https://lists.qt-project.org/pipermail/development/2023-February/043602.html

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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Volker Hilsheimer via Development]

That’s an excellent idea indeed.

And the attribution file already able to point at the upstream (albeit 
optional; I guess we can’t make it mandatory), and a comment entry that could 
in turn include information about how to update things, makes that a pretty 
complete container of all relevant information.

Volker


On 22 Feb 2023, at 12:21, Kai Köhne  wrote:

Hi,

Does moving the information closer to the code make sense? Most of the 
information provided in the wiki is already part of the qt_attribution.json 
files that we use to generate the official documentation about third party 
modules. What’s missing is the ‘process untrusted content’ flag, which is easy 
to add:

https://codereview.qt-project.org/c/meta/quips/+/461983

Tell me what you think.

Regards

kai

From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Volker Hilsheimer via Development
Sent: Friday, January 20, 2023 9:58 AM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Security-relevant 3rd party components bundled with 
Qt

On 1 Nov 2022, at 09:55, Volker Hilsheimer via Development 
mailto:development@qt-project.org>> wrote:

On 20 Sep 2022, at 14:47, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:
[…]

Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).


Hi again,


Thanks for populating that page with information about 3rd party components 
processing untrusted content.

As a next step, could those of you who are upgrading such components as part of 
the release process, please provide links to the respective upstream, and 
instructions on what is involved in the upgrading of the bundled sources?

Hi,

That page still misses information for a lot of 3rd party modules about where 
to find the upstream and the update instructions. That makes it very difficult 
for our release team to follow up on the 3rd party update.

Third Party Code in Qt - Qt Wiki<https://wiki.qt.io/Third_Party_Code_in_Qt>
wiki.qt.io<https://wiki.qt.io/Third_Party_Code_in_Qt>
<https://wiki.qt.io/Third_Party_Code_in_Qt>

We need information about

QtNetwork:
- public suffix list

QtGui:
- harfbuzz-ng
- libpng, libjpeg
- sqlite

Qt Imageformats:
- libwebp

Qt Multimedia
- ffmpeg
- eigen
- pffft
- resonance audio

Qt Quick3D
- assimp
- tinyexr


Thanks,
Volker


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

Re: [Development] Requesting a repository for Qt Graphs

[Volker Hilsheimer via Development]

Hi,

the work has been happening in the wip/NG branch:

https://codereview.qt-project.org/gitweb?p=qt/qtdatavis3d.git;a=shortlog;h=refs/heads/wip/NG

Note that we want to (ultimately and over time) cover the functionality of Qt 
Charts in this new implementation as well.

Volker



> On 13 Feb 2023, at 17:17, Thiago Macieira  wrote:
> 
> On Sunday, 12 February 2023 22:15:26 PST Tomi Korpipää via Development wrote:
>> The plan is to have QtGraphs as a technology preview in Qt 6.6, maturing it
>> for Qt 6.7.
> 
> So you've got a lot of content already. Can you point to the Labs repository?
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Cloud Software Architect - Intel DCAI Cloud Engineering
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Proposal: let's change the release schedules a bit

[Volker Hilsheimer via Development]

Indeed, summer holidays are not the same for everyone, and it’s no the same 
every year. Berlin has school summer holidays mostly in August this year, after 
having them mostly in July last year, and even a bit in June already in 2021. 
From my personal perspective - in spite of living in Norway where the country 
shuts mostly down during July, I like to take my holidays in August as that’s 
when my family in southern Germany has their break - having time to finish 
features, or to work on small features, during the quiet time in July sounds 
lovely.

In theory it is possible for us to plan our feature development work in such a 
way that it’s done before we take a break, just as much as it’s evidently 
possible to get done before feature freeze. And while we probably have all 
experienced that our plans didn't survive first contact with real life, we 
always have options: perhaps someone else that was involved in the work is 
available to push it over the finishing line; and if not, then we can always 
postpone the feature, or ask for an exception. Perhaps the slow time during 
summer allows those parts of feature development work to happen that is now 
often done after feature freeze (such as documentation). Parkinson’s Law 
probably holds, no matter what defines the allotted time - someone's personal 
holidays, or project level feature freeze.

But for the release team, the busy time is shortly before, and significantly 
after the freeze. So from that perspective, having the feature freeze either 
significantly before the summer break, or afterwards, makes most sense. They 
are the ones most impacted.

So, if Jani and the team believe that their work will be made easier by moving 
the feature freeze to be after the holidays, then let’s do that. If we find out 
that it causes problems that outweigh the benefits, then we can adjust again 
based on that experience.

Volker



On 6 Feb 2023, at 12:15, Tuukka Turunen via Development 
 wrote:

Hi,

We have not yet concluded about Jani’s proposal for adjusting the feature 
freeze and release timing: 
https://lists.qt-project.org/pipermail/development/2022-December/043380.html

The original proposal was: ”… release minor releases in April and October, that 
would allow us to move FF also after the holidays: So FF for April release 
would be in January and FF for October release would be in August.”

We should make the decision soon to set the dates for Qt 6.6 release. Do we 
keep the current approach or go forward with extending the Qt 6.6. feature 
freeze to be in August instead of June?

Yours,

Tuukka


From: Tuukka Turunen 
Date: Wednesday, 14. December 2022 at 11.44
To: Volker Hilsheimer , Jani Heikkinen 

Cc: development@qt-project.org 
Subject: Re: [Development] Proposal: let's change the release schedules a bit
Hi,

One of the main problems we face every time with the feature freeze is a lot of 
changes coming in just before the deadline. While this is quite natural as 
such, it does also cause some amount of instability and problems in getting the 
full integration test round completed regularly. There are many ways to tackle 
this issue and a lot of things have already been done (such as introducing a 
new freeze point for platforms/configurations in CI before the FF). Having the 
FF date just before a major holiday period is one item that possibly increases 
the instability. Not everyone is on vacation at the same time and especially 
during the summer different countries tend to have a bit different general 
preferences for the primary holiday period. Having the FF in January instead of 
December and August instead of June would likely reduce the number of changes 
coming in just before the deadline. Spreading the changes more evenly in the 
feature development timeline makes it easier to keep integration test rounds 
passing regularly.

Yours,

Tuukka


From: Development  on behalf of Volker 
Hilsheimer via Development 
Date: Thursday, 8. December 2022 at 14.03
To: Jani Heikkinen 
Cc: development@qt-project.org 
Subject: Re: [Development] Proposal: let's change the release schedules a bit
For me, the argument that Eddy makes is very strong: a milestone or deadline 
right after holidays has the potential of ruining those holidays, without 
giving any meaningful extra time to get features done.

Releases of operating systems have some relevance: new macOS and Windows 
versions have in recent cycles happened around March/April and 
October/November. But even if we try to have the Qt release shortly after those 
to claim quick support, in reality it would probably be “technology preview” 
status anyway, knowing how much time it takes to make new CI configurations 
significant. And TP status can just as well be achieved based on beta and 
preview versions. Linux distro cycles are more relevant to align with as we are 
upstream, but in practice I’d expect more practical value in having the first 
or second

Re: [Development] Qt Multimedia: proposing behavior change to QAudioSink::resume

[Volker Hilsheimer via Development]

On 1 Feb 2023, at 14:01, Lars Knoll  wrote:
I agree. Let’s change behaviour and move it to active after a call to resume(). 
It also behaves the same in push and pull mode in that case.

Cheers,
Lars



Thanks, done now in 
https://codereview.qt-project.org/c/qt/qtmultimedia/+/458410 which is 
integrating, and will be cherry-picked to Qt 6.5 so that we don’t have to drag 
the broken behavior around with us for several years.


Cheers,
Volker


On 31 Jan 2023, at 13:11, Tor Arne Vestbø via Development 
 wrote:

Hi,

This does indeed look like an oversight, where the behavior was perhaps modeled 
under the assumption the buffers were empty at the time of suspend().

I would expect the state to return back to the same state the sink had when 
calling suspend().

Cheers,
Tor Arne

On 30 Jan 2023, at 16:38, Volker Hilsheimer via Development 
 wrote:

Hi,


TL;DR: I’d like to change QAudioSink::resume() to always change the sink to 
Active state, no matter how the sink was start()’ed.


QAudioSink provides low-level access to an audio device, allowing applications 
to provide PCM data.

The class operates in one of two modes: in pull mode, the application provides 
a QIODevice when calling QAudioSink::start(QIODevice *), and the sink will pull 
data from that devices as needed. In push mode, the QAudioSink creates and 
returns a QIODevice from the other QAudioSink::start() overload. Applications 
write PCM data into that device.

The problem is with QAudioSink::resume. The function is documented to behavior 
differently depending on how start() was called:

/*!
 Resumes processing audio data after a suspend().

 Sets error() to QAudio::NoError.
 Sets state() to QAudio::ActiveState if you previously called start(QIODevice*).
 Sets state() to QAudio::IdleState if you previously called start().
 emits stateChanged() signal.
*/

QAudioSink::suspend() behaves the same way in both modes: audio stops 
immediately, already buffered data is preserved.

This means that on a sink that has 10 seconds worth of data, calling suspend() 
after 1 second, and then resume()’ing changes the state of a push-mode audio 
sink to Idle, audio will play for 9 seconds while the sink reports to be idle, 
and the sink doesn’t change to “really idle” when all the audio data has been 
played.

This means also that applications have no way of knowing when it’s time to 
write more data, as an underflow error is never reported - the sink is already 
idle, there are no state changes. This is pretty broken IMHO making the 
push-style API practically useless if suspend/resume are used. However, the 
behavior is documented, and verified in tests.

A sane behavior would be to move the sink to Active after resume (and to handle 
buffer under-runs as usual, resulting in Idle state with error).

I’m not sure yet that we can implement the sane behavior on all platforms. 
Pull-mode evidently implements it, but I don’t know yet if we can inspect the 
amount of data buffered by the underlying audio system. Before we start 
investigating that - can anyone think of any particular reason why the existing 
behavior is a good idea?


Volker

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

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


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

[Development] Check your cherry-picks to 6.5 branches

[Volker Hilsheimer via Development]

Hi,

A few days ago we had a lot of cherry-picks into 6.5 branches that hadn't 
merged, for various reasons. Thanks to some copious stage-button-mashing during 
the last days, that list is now rather short. Nevertheless, please have a look 
at the unmerged cherry-picks anyway:

https://codereview.qt-project.org/q/branch:6.5+-status:merged+-status:abandoned+owner:cherrypick_bot%2540qt-project.org

What’s pending might need a rebase, or a conflict resolution. And since some of 
those changes might be triggered by findings during header-review, let’s try to 
get that list down to zero, and to keep it there (either by merging, or by 
abandoning changes that are not worth the backporting work). Any change that 
got successfully cherry-picked into 6.4 already must be cherry-picked into 6.5, 
lest we end up with a regression in the 6.5 branch compared to both 6.4 and dev 
(i.e 6.6).


Thanks!
Volker

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

Re: [Development] Qt TextToSpeech: Adding dependency to Qt Multimedia - ok?

[Volker Hilsheimer via Development]

> On 23 Jan 2023, at 16:07, Kai Köhne  wrote:
> 
> Hi,
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> [...]
>> This is a binary compatibility breakage of sorts. Applications that were 
>> linked
>> against Qt 6.4 or Qt 6.5, and want to run against Qt 6.6 won’t work unless Qt
>> Multimedia is present.
> 
> This doesn't violate the binary compatibility guarantee per se, IMO. The 
> guarantee is against the Qt framework itself, not against individual 
> libraries in it. We also don't allow upgrading individual Qt modules, for 
> instance.

To clarify, the problem is not upgrading an individual module here, but that an 
application running against Qt 6.6 will require Qt Multimedia, while an 
application running against Qt 6.4 or Qt 6.5 will not.

But, I agree that we can assume that on systems where binary compatibility 
matters, all Qt modules are installed (or get installed when upgrading).


> Anyhow, you could consider making the dependency optional at configure time. 
> Then users who don't need it could still configure without qtmultimedia - no 
> idea whether this is worth the hassle though.
> 
> Regards
> 
> Kai


Ok. Given the footprint of Qt TextToSpeech, I don’t think it’s worth the hassle 
to make this configurable.

Volker

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

[Development] Qt Multimedia: proposing behavior change to QAudioSink::resume

[Volker Hilsheimer via Development]

Hi,


TL;DR: I’d like to change QAudioSink::resume() to always change the sink to 
Active state, no matter how the sink was start()’ed.


QAudioSink provides low-level access to an audio device, allowing applications 
to provide PCM data.

The class operates in one of two modes: in pull mode, the application provides 
a QIODevice when calling QAudioSink::start(QIODevice *), and the sink will pull 
data from that devices as needed. In push mode, the QAudioSink creates and 
returns a QIODevice from the other QAudioSink::start() overload. Applications 
write PCM data into that device.

The problem is with QAudioSink::resume. The function is documented to behavior 
differently depending on how start() was called:

/*!
Resumes processing audio data after a suspend().

Sets error() to QAudio::NoError.
Sets state() to QAudio::ActiveState if you previously called 
start(QIODevice*).
Sets state() to QAudio::IdleState if you previously called start().
emits stateChanged() signal.
*/

QAudioSink::suspend() behaves the same way in both modes: audio stops 
immediately, already buffered data is preserved.

This means that on a sink that has 10 seconds worth of data, calling suspend() 
after 1 second, and then resume()’ing changes the state of a push-mode audio 
sink to Idle, audio will play for 9 seconds while the sink reports to be idle, 
and the sink doesn’t change to “really idle” when all the audio data has been 
played.

This means also that applications have no way of knowing when it’s time to 
write more data, as an underflow error is never reported - the sink is already 
idle, there are no state changes. This is pretty broken IMHO making the 
push-style API practically useless if suspend/resume are used. However, the 
behavior is documented, and verified in tests.

A sane behavior would be to move the sink to Active after resume (and to handle 
buffer under-runs as usual, resulting in Idle state with error).

I’m not sure yet that we can implement the sane behavior on all platforms. 
Pull-mode evidently implements it, but I don’t know yet if we can inspect the 
amount of data buffered by the underlying audio system. Before we start 
investigating that - can anyone think of any particular reason why the existing 
behavior is a good idea?


Volker

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