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

[Tor Arne Vestbø via Development]

> On 8 May 2024, at 07:32, Marc Mutz via Development 
>  wrote:
> 
> I'd like an option that actually solves for the needs of QtNetworkAuth.

1. Move the plumbing of the URL handling to private APIs in QtCore, used by 
QDesktopServices
2a. Add a helper QOAuth2AuthorizationCodeFlow::openChallengeUrl function that 
uses the QtCore private api
2b. Have QOAuth2AuthorizationCodeFlow automatically open the browser via the 
QtCore private API

No public API changes needed to QDesktopServices needed, which means we’re not 
blocking the QtNetworkAuth work on the work required to research 
activities/intents APIs (which is not scheduled for 6.8).

Tor Arne

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

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

[Tor Arne Vestbø via Development]

> On 7 May 2024, at 12:51, Marc Mutz via Development 
>  wrote:
> 
> On 06.05.24 13:08, Tor Arne Vestbø via Development wrote:
>> 
>> 
>>> On 6 May 2024, at 13:06, Juha Vuolle  wrote:
>>> 
>>>> QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage
>>>> at the user's discretion, and thus that currently won't force a Gui
>>>> dependency.
>>> 
>>> (Ah shoot. Correcting myself, in the new qtnetworkauth class we do
>>> need to call QDesktopServices::openUrl() too to forward any unhandled
>>> URLs.)
>> 
>> Which you can do through the private QtCore API that we add.
> 
> AFAIU, it's the user that needs to make a connection to openUrl() from 
> an OAuth signal: 
> https://code.qt.io/cgit/qt/qtnetworkauth.git/tree/examples/oauth/redditclient/redditwrapper.cpp#n28


Looking at the API, does the user even need to connect authorizeWithBrowser to 
openUrl? Couldn’t QOAuth2AuthorizationCodeFlow do that automatically?

> 
> So, no, private-only API won't cut it.

An alternative that wouldn’t require the QtCore move is to expose an 
openChallengeUrl on QOAuth2AuthorizationCodeFlow

> Honestly, I don't understand the push-back for the move. It seems only 
> logical to me: QUrl is in QtCore, so IMHO, it's only logical to have 
> QUrl _handlers_ in QtCore, too. And in other emails, I showed use-cases 
> of CLI programs that need openUrl(), but not the rest of QtGui.
> 
> So, we have use-cases and we seem to have no technical reason to not 
> move the code (if we can provide it as private API, there can't be many).

As I mentioned earlier, twice I think now, there is overlap to 
intents/activities, which are also URL based. If we want to build a Qt API for 
this, it would make sense to not propagate the (legacy) QDesktopServices 
openUrl/urlHandler APIs further.

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

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

[Tor Arne Vestbø via Development]

> On 6 May 2024, at 13:06, Juha Vuolle  wrote:
> 
>> QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage
>> at the user's discretion, and thus that currently won't force a Gui
>> dependency.
> 
> (Ah shoot. Correcting myself, in the new qtnetworkauth class we do
> need to call QDesktopServices::openUrl() too to forward any unhandled
> URLs.)

Which you can do through the private QtCore API that we add.

Tor Arne 

> 
>> The concrete need for QtNetworkAuth at the moment is
>> QDesktopServices::setUrlHandler() and
>> QDesktopServices::unsetUrlHandler().
>> There is a new (Qt 6.8) class which needs to use these *) and that
>> would create a module-level Gui dependency (unless using plugins or
>> somesuch).
>> 
>> Hence I'm wondering if, as a pragmatic pre-move, moving the
>> implementation of those two functions behind a private header in
>> QtCore (IIUC this is Tor Arne's proposal) would be
>> sensible/acceptable?
>> 
>> *) In order to be able to use custom-scheme and https-scheme redirect_uris
>> 
>> Cheers,
>> Juha
>> 
>>> On 6 May 2024, at 09:51, Lars Knoll via Development 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 6 May 2024, at 09:02, Marc Mutz via Development 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Juha is currently improving the OAuth implementation in QtNetworkAuth.
>>> The protocol involves launching the system browser to get an access
>>> code, in turn used to get access tokens with which services can then be
>>> accessed.
>>> 
>>> OAuth therefore requires a UI to run the browser in, but not necessarily
>>> a _G_UI (the system browser could be lynx). Even if a CLI tool like a
>>> mail fetcher, backup program, or VPN client will eventually launch
>>> Firefox or Chrome, I think it's too much to ask to link to QtGui just to
>>> do the equivalent of exec xdf-open .
>>> 
>>> 
>>> I’d agree with that. And there’s no way to do OAuth without launching a 
>>> browser during the authentication process.
>>> 
>>> 
>>> I've looked at the implementation of openUrl(), and the only
>>> Gui-dependency is on the platform helpers. The handler registration is
>>> only using Core functionality.
>>> 
>>> I would therefore propose to move the services code from Gui to Core
>>> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
>>> dependency.
>>> 
>>> After a quick look, I can see two ways to do that:
>>> - keep the platform handling code in the platform helpers, incl. Gui
>>> dependency, and only move the handler registration to Core
>>> - move the platform url handlers out of the platform helpers into (a
>>> plugin for) Core
>>> 
>>> The first would enable users to write their own handlers w/o Gui
>>> dependency, but has the disadvantage that the code behaves differently,
>>> depending on whether QtGui is loaded or not.
>>> 
>>> The second would be more work, but with consistently better user experience.
>>> 
>>> Is there a reason other than history for the openUrl handlers to be in
>>> the platform handlers? We have XDG-code in QtCore already (mime types),
>>> so we should have all the information in Core already to implement the
>>> functionality, should we not?
>>> 
>>> 
>>> I believe the reason for this is mainly history. Moving this to Qt Core 
>>> makes sense IMO.
>>> 
>>> I don’t think you need a separate plugin for Qt Core to implement this 
>>> though. I’m a bit unsure about the windows code, but on Linux and macOS 
>>> it’s simply launching ‘xdg-open’ or ‘open’. It would probably fit better to 
>>> simply follow the usual pattern for Qt Core with a _platform.cpp 
>>> implementation file.
>>> 
>>> Cheers,
>>> Lars
>>> 
>>> 
>>> 
>>> Thanks,
>>> Marc
>>> 
>>> --
>>> Marc Mutz  (he/his)
>>> 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

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

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

[Tor Arne Vestbø via Development]

> On 6 May 2024, at 12:31, Allan Sandfeld Jensen  wrote:
> 
> On Monday 6 May 2024 10:02:43 CEST Tor Arne Vestbø via Development wrote:
>> There’s some overlap here with the more modern features of intents,
>> activities, etc, which we are hoping to add proper APIs for at some point,
>> so I suggest not doing any public API changes as part of this.
> 
>> We can move the registration APIs to QtCore as private APIs, that
>> QtNetworkAuth can use, and QDesktopServices can plumb to. And we can move
>> the URL handling part of the QPA plugins to QtCore under
>> src/corelib/platform
> 
> Is there any problem in moving the class all the way if we preserve the 
> headers under both QtGui and QtCore? Since QtCore is always linked when QtGui 
> is linked, it shouldn't affect BC should it? The main problem with moving 
> classes between Qt modules is source compatibility, or I am forgetting 
> something?

As I mentioned, there is overlap with similar features that we want to spend 
more time on researching. Let’s not couple the needs of QtNetworkAuth to that 
work, and let’s not rush QDesktopServices wholesale into QtCore either.

Cheers,
Tor Arne

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

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

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

[Tor Arne Vestbø via Development]

There’s some overlap here with the more modern features of intents, activities, 
etc, which we are hoping to add proper APIs for at some point, so I suggest not 
doing any public API changes as part of this.

We can move the registration APIs to QtCore as private APIs, that QtNetworkAuth 
can use, and QDesktopServices can plumb to. And we can move the URL handling 
part of the QPA plugins to QtCore under src/corelib/platform

Cheers,
Tor Arne

On 6 May 2024, at 09:51, Lars Knoll via Development 
 wrote:



On 6 May 2024, at 09:02, Marc Mutz via Development  
wrote:

Hi,

Juha is currently improving the OAuth implementation in QtNetworkAuth.
The protocol involves launching the system browser to get an access
code, in turn used to get access tokens with which services can then be
accessed.

OAuth therefore requires a UI to run the browser in, but not necessarily
a _G_UI (the system browser could be lynx). Even if a CLI tool like a
mail fetcher, backup program, or VPN client will eventually launch
Firefox or Chrome, I think it's too much to ask to link to QtGui just to
do the equivalent of exec xdf-open .

I’d agree with that. And there’s no way to do OAuth without launching a browser 
during the authentication process.

I've looked at the implementation of openUrl(), and the only
Gui-dependency is on the platform helpers. The handler registration is
only using Core functionality.

I would therefore propose to move the services code from Gui to Core
(QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
dependency.

After a quick look, I can see two ways to do that:
- keep the platform handling code in the platform helpers, incl. Gui
dependency, and only move the handler registration to Core
- move the platform url handlers out of the platform helpers into (a
plugin for) Core

The first would enable users to write their own handlers w/o Gui
dependency, but has the disadvantage that the code behaves differently,
depending on whether QtGui is loaded or not.

The second would be more work, but with consistently better user experience.

Is there a reason other than history for the openUrl handlers to be in
the platform handlers? We have XDG-code in QtCore already (mime types),
so we should have all the information in Core already to implement the
functionality, should we not?

I believe the reason for this is mainly history. Moving this to Qt Core makes 
sense IMO.

I don’t think you need a separate plugin for Qt Core to implement this though. 
I’m a bit unsure about the windows code, but on Linux and macOS it’s simply 
launching ‘xdg-open’ or ‘open’. It would probably fit better to simply follow 
the usual pattern for Qt Core with a _platform.cpp implementation file.

Cheers,
Lars



Thanks,
Marc

--
Marc Mutz  (he/his)
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] RFC: New keyword for Fixes bot "Reopens" and revert detection

[Tor Arne Vestbø via Development]

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




Additionally, also proposed with this keyword addition is automatic detection 
of reverts by the bot for jira issue tagging. The bot would search for jira 
issues related to the revert by:

 *
Any issues specified in any footers of the revert change should be tagged with 
the merged commit of the revert.
 *
Any issues specified in any footers by the original change (sha) being reverted 
should be tagged with the merged commit of the revert.

Please respond by Friday, 19 April if you have comments or further suggestions 
on this proposal.
--
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] Nominating Jøger Hansegård for approver rights

[Tor Arne Vestbø via Development]

Hi,

I would like to nominate Jøger Hansegård for approver rights in the Qt project.

Jøger joined The Qt Company 10 months ago and has since then been getting his 
hands dirty in Qt Multimedia, and lately focusing on color management.

Jøger is a thorough and responsible engineer and I trust that he will make a 
good approver for the Qt project.

Authored changes: 
https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io
Reviews: https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io

Cheers,
Tor Arne
-- 
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

[Tor Arne Vestbø via Development]

+1!

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


--
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] Using '#pragma once' instead of include guards?

[Tor Arne Vestbø via Development]

The choice of where we use/allow `#pragma once` should not be coupled to 
whether a header is considered public or not.

Let’s not create even more indirections and inference rules that one has to 
keep in mind.

If we want to make it clearer if a header is public or not, let’s make it 
explicit.

We already have two established mechanisms:

 - Header ending in _p.h
 - "We mean it” comment

Renaming files may be too much churn, so let’s add more "We mean it” comments.

It doesn’t matter whether header will be installed or not. The documentation is 
for whoever is going to look at the header, i.e us (and our tools) for 
non-installed headers, and for us and users for installed headers. Both groups 
would benefit from clarification of whether the header is public API or not.

I’m fine with using `#pragma once` more, but that discussion is orthogonal to 
how we clarify the status of a header.

Cheers,
Tor Arne

On 6 Mar 2024, at 07:57, Marc Mutz via Development  
wrote:

Hi,

TL;DR: I'd maintain that #pragma once to mark non-installed headers is
a) the least-intrusive change of all that's been proposed, b) targeting
the non-public headers only (so don't disturb e.g. the API reviews (or
customer's validation...)), which c) are the minority of Qt headers
(minimizing work) and d) has benefits other than as a static assertion
against header installation.

Longer version:

Given that there are, in general, many more public and _p.h private
headers in Qt (outside tools), I'd think the prudent approach is to
modify the (fewer) non-installed headers.

As for using a comment: We have the "We mean it" comment in _installed_
non-public headers, because installed headers are _accessible_ to users.
I see no value in adding such comments to headers that are never
installed, and are therefore _in_accessible to users.

OTOH, #pragma once has benefits other than acting as a static assertion
against header installation. In my forays into "leaf" modules, but even
in qtbase, misnamed (header guard name doesn't match file name) and
non-Q-namespaced or overly-generic header guard macro names abound, and
I even found a downright broken header guard that had only
#ifndef/#endif and was missing the #define. If we can make it easier for
Qt devs to protect headers, we should do it. #pragma once also doesn't
change when the file is renamed or otherwise moved.

Note to self: make sanity bot check that header guards start with a Q
and end in the file's name xor contain #pragma once, except in /3rdparty/.

Thanks,
Marc

On 05.03.24 11:43, Volker Hilsheimer wrote:
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 

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

[Tor Arne Vestbø via Development]

+1 :)

> On 8 Feb 2024, at 09:39, Morten Sørvig via Development 
>  wrote:
> 
> 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

Re: [Development] Nominating Vlad Zahorodnii for approval status

[Tor Arne Vestbø via Development]

+1!

> On 1 Feb 2024, at 15:11, David Edmundson  wrote:
> 
> I would like to nominate Vlad Zahorodnii for approver rights in the Qt 
> project.
> 
> Vlad has also been working on the QtWayland backend, providing insight
> based on his other role as one of the kwin maintainers.
> Vlad and I have been working together at Blue Systems for 5 years. He
> is extremely technically competent and very thorough in reviews. I
> trust that he would exercise approver rights responsibly.
> 
> Changes where he is the author:
> https://codereview.qt-project.org/q/author:vlad.zahorodnii%2540kde.org
> Changes where he commented/voted
> https://codereview.qt-project.org/q/reviewer:vlad.zahorodnii%2540kde.org
> -- 
> 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

[Tor Arne Vestbø via Development]

+1!

> 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] Nominating Matthias Rauter for approval status

[Tor Arne Vestbø via Development]

+1!

On 30 Jan 2024, at 13:11, Paul Tvete via Development 
 wrote:

Hi,

I would like to nominate Matthias Rauter as an approver for the Qt Project.

Matthias has been working on Qt for more than a year now. In this time, he has 
done great work on Qt Location and Qt SVG, among other. I have had the pleasure 
to work with him on the Curve Rendering project in Qt Quick Shapes where he has 
made impressive contributions. He has been consistently professional in 
development and review, and I am certain that he will exercise his approver 
powers responsibly.

List of changes made by Matthias: 
https://codereview.qt-project.org/q/owner:matthias.rauter%2540qt.io
Matthias's review activity: 
https://codereview.qt-project.org/q/commentby:matthias.rauter%2540qt.io

Cheers,
 - Paul
--
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] Stepping down as Android maintainer

[Tor Arne Vestbø via Development]

Thanks for all your work BogDan!

And a strong +1 to Assam!

Tor Arne

8. jan. 2024 kl. 09:47 skrev BogDan Vatra via Development 
:

Hello there,

  I have been less active on the Android port recently and Assam has been doing 
the majority of the work maintaining the Android port.
I'm therefor stepping down as the maintainer of the Android port and nominate 
Assam to take over.

Cheers,
BogDan.

--
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] QML Rectangle corner radius API for Qt 6.7

[Tor Arne Vestbø via Development]

On 22 Dec 2023, at 13:59, André Somers  wrote:


And what type would the radius property return then? I guess it would have to 
be the grouped type. But that would break all code that currently creates a 
binding on radius expecting it to be a real.

True, that would not work too well. The grouped type would need to be 
convertible to a qreal I guess?

What does `radius` return today, with the new API, when you’ve set only 
topLeftRadius?

Tor Arne



-- 
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

[Tor Arne Vestbø via Development]

On 22 Dec 2023, at 13:59, Lars Knoll  wrote:

You don't often get email from l...@knoll.priv.no<mailto:l...@knoll.priv.no>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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.

It’s not only affecting the border though, which can be a bit confusing 
perhaps? https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius has an 
explicit note of that: "The radius applies to the whole background, even if the 
element has no border;”.

Tor Arne
-- 
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

[Tor Arne Vestbø via Development]

On 22 Dec 2023, at 13:54, Tor Arne Vestbø  wrote:

We can change the `radius` property from a qreal into a group property with 
left/rigth/top/bottom, similar to anchors. We can detect in the setRadius 
setter if the incoming argument is a real, and apply that to all of the 
corners. That would be backwards compatible, and give a more granular API for 
those that need it.

And by top/left/bottom/right I of course meant topRight, etc :)

-- 
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

[Tor Arne Vestbø via Development]

> 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.

We can change the `radius` property from a qreal into a group property with 
left/rigth/top/bottom, similar to anchors. We can detect in the setRadius 
setter if the incoming argument is a real, and apply that to all of the 
corners. That would be backwards compatible, and give a more granular API for 
those that need it.

Tor Arne 

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

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

[Tor Arne Vestbø via Development]

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

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

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

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

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

Cheers,
Tor Arne




Volker


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

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

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

BR,
Maurice


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

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

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

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

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

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


So is this the Qt Middleware module?


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

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


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

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

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

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

Cheers,
Tor Arne


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

Hi,

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

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

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

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

Yours,

Tuukka

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

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

[Tor Arne Vestbø via Development]

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

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

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

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

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

So is this the Qt Middleware module?

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

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

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

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

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

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

Cheers,
Tor Arne

On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
 wrote:

Hi,

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

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

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

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs 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
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dgenivi%2Bsite%25253Ahttps%25253A%25252F%25252Flists.qt-project.org%25252Fpipermail%25252Fdevelopment%25252F=05%7C01%7Ctuukka.turunen%40qt.io%7Cc5d9d74e44014c5e22c308dbf5b48c59%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638373928019928582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=r0fpIXCgLTyWGtC9bIJ9waV7QgvH6J%2FnwRLJ%2BZMPL9k%3D=0

I don't know what kind of API reviews have been done since. But there has been
no discussion about renaming this module. Therefore, the name it is currently
using is unauthorised and does not imply a precedent.

-1 on this new module with this name.


--
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] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Tor Arne Vestbø via Development]

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 .

Tor Arne

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.

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] Failed to run configure.bat in qt/qt5 repository on Windows?

[Tor Arne Vestbø via Development]

If the goal here is to build documentation, I recommend installing Qt from the 
installer, and then doing a local build with e.g.:

cd ~/build/qt/6.x-doc && ~/dev/qt/configure -developer-build -nomake examples 
-nomake tests -no-warnings-are-errors -submodules qtbase,qtdoc -qt-host-path 
~/install/qt/6.5.1/macos -- -DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE

Passing the binary installation directory to -qt-host-path will let you build 
documentation for another branch using the host tools (qdoc, etc) from the 
binary installer.

Cheers,
Tor Arne

> On 22 Aug 2023, at 16:45, Thiago Macieira  wrote:
> 
> On Monday, 21 August 2023 23:34:17 PDT Kai Köhne via Development wrote:
>>  cmake --build . --parallel 4 --target qminimal qsqlite
> 
> As suggested before, I recommend building all of qtbase first. If you're 
> insisting on the top-level build, then:
> 
> ninja qtbase/all
> 
> 
> -- 
> 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] Changes to automatic cherry-picking

[Tor Arne Vestbø via Development]

Thanks Daniel! This sounds like a better model with less chance of orphaned 
changes.

> On 24 Jul 2023, at 10:07, Daniel Smith via Development 
>  wrote:
> 
[…]

> Because this change takes away some level of control from the user, a new 
> footer is being introduced. A new footer, proposed as "Hotfix-to: " will 
> behave as the old logic does today, blasting all Pick-to targets in parallel 
> with no gap checking or validation for existing changes. It's recommended to 
> use the "Pick-to:" footer as often as possible and reserve "Hotfix-to:" for 
> security or other critical fixes which can't wait on the waterfall 
> cherry-pick automation.

I would recommend skipping this new footer. There’s nothing preventing manual 
cherry-picks, either locally via git, or via Gerrit’s UI, and doing those 
manualy seems more appropriate anyways for the exception when a change needs to 
be rushed into a branch.

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

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

[Tor Arne Vestbø via Development]

> On 14 Jun 2023, at 17:48, 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.

This position has been explained ad nauseam. Please go back and read earlier 
emails in this thread.

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

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

[Tor Arne Vestbø via Development]

On 14 Jun 2023, at 16:20, Allan Sandfeld Jensen  wrote:

On Mittwoch, 14. Juni 2023 14:59:40 CEST Marc Mutz via Development wrote:
On 02.05.23 10:58, Volker Hilsheimer via Development wrote:
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.
Was there some consensus here? We're discussing this _again_ in the 6.6
review...

Let me propose the following, separate issues, so we have something
concrete to +1 or -1:

[All capitalized words have the meaning of IETF RFCs]

A) new enums MUST have an explicit underlying type¹²
+1 Sure

+1 Sure



B) new enums MUST be scoped, also when nested in classes¹²
-1 Disagree

-1 Disagree



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

+1 Agree, and if you find you do repeat the type name in an unscoped enum it
probably should be scoped. But isn't this already in our style guide?

+1 Agree, and yes, it’s already in our style guide.

Cheers,
Tor Arne

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

[Development] Bumping the minimum CMake version for Apple platforms to 3.21 for Qt 6.6

[Tor Arne Vestbø via Development]

Hi all,

We currently require CMake 3.16 for shared builds, and 3.21 for static builds. 
CMake 3.16 unfortunately doesn't have a feature we rely on on Apple platforms — 
finalizers — requiring us to maintain and take into account additional APIs for 
users to manually finalize their projects, with caveats and sharp corners.

We’d like to avoid the maintenance overhead of this manual finalization API 
going forward, and are proposing to bump the required CMake version for user 
projects (and Qt in effect) on Apple platforms to 3.21 for 6.6, the same 
version we require for static builds for all Qt platforms.

This should not present much problems for users on these platforms (macOS), as 
CMake is not shipped with the system, but instead installed via e.g. Homebrew, 
which already ships a recent version, and also makes it easy to upgrade. Our 
own binary installers also ship 3.24, so we’re good there as well.

As qt_finalize_target is already a noop for CMake 3.21 the work involved to 
bump the requirement is primarily updating documentation. 

Let us know if this causes concern.

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

Re: [Development] Nominating Artem Dyomin as Approver

[Tor Arne Vestbø via Development]

+1!

(Disclaimer: Artem reports to me directly).

On 27 May 2023, at 18:02, Volker Hilsheimer via Development 
 wrote:

+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

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

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

[Tor Arne Vestbø via Development]

+1!

> 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
> 
> -- 
> 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

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

[Tor Arne Vestbø via Development]

On 3 May 2023, at 19:22, Thiago Macieira  wrote:

I'd say that any new enumeration in the Qt namespace should be enum class, but
enums in classes may not be so if they're sufficiently descriptive already.

Agreed, and this is also what our current API design guide says:


API Design Principles - Qt 
Wiki
wiki.qt.io
[favicon.ico]


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

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

[Tor Arne Vestbø via Development]

On 3 May 2023, at 18:40, Giuseppe D'Angelo via Development 
 wrote:

Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:
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.

Should we vote on this? To me it's a no brainer: any new enumeration added to 
Qt shall be an enum class.

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.)

These are all straw men.

I’ll quote directly from 
https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values
Naming Enum Types and Values

The guiding principle is to avoid name clashes between enum values and to 
ensure readability code with reasonable verbosity.

Enums in Qt/global namespace

New enums in the Qt namespace should always use scoped/strong enumerators by 
default. The scoping/strong typing ensures that there is no conflict if the 
same enum value name is used multiple times:

 namespace Qt
 {
   enum class Color {
 Blue,
 Orange,
 Yellow
   };

   enum class FavoriteColor {
 Yellow,
 Orange
   };
 }

 Color yellow = Qt::Color::Yellow;
 FavoriteColor yellow2 = Qt::FavoriteColor::Yellow;
 yellow2 = Qt::Orange; // error


When using scoped enums additional naming rules (repeating of enum type name 
inside enum value name) for are not necessary.

Enums in classes

Enums inside a class do not have the same problem of names clashing, as they 
are already namespaced within the class.

There are still reasons to prefer scoped enums inside classes, but this should 
be decided on a case by case basis.

If the enum values have a clear relation to the parent class, prefer un-scoped 
enums:

 class TouchPoint
 {
   enum State {
Pressed,
Held,
Released
   };
};

// The context is clear when used outside the class
if (point.state() == TouchPoint::Pressed)
   ...

// As well as when used inside it
if (state() == Pressed)
   ...


Using scoped enums in this case would add redundant line noise:

if (point.state() == TouchPoint::State::Pressed)
   ...
if (state() == State::Pressed)
   ...


Note that the context where the enum is used, such as the name of the getter 
that returns the enum value, might be enough information to make a scoped enum 
redundant.

If the enum values do not have a natural relation to the class name, prefer 
scoped enums, e.g.:

 class QSslCertificate
 {
   enum class PatternSyntax {
RegularExpression,
Wildcard,
FixedString
   };
};

if (syntax == PatternSyntax::Wildcard)
  ...


Another option to avoid the name clash instead of scoped/strong enums is to 
embedded the enum type name into each enum value. This method was extensively 
used in Qt 4 before scoped/strong enums were available.

 class Widget
 {
  enum Corner {
   TopLeftCorner,
   BottomRightCorner,
…
  };
 };

 tabWidget->setCornerWidget(widget, Widget::TopLeftCorner);
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Archiving of the '6.x' version in JIRA

[Tor Arne Vestbø via Development]

Hey all,

We’re planning on archiving the '6.x’ version in JIRA:

https://bugreports.qt.io/projects/QTBUG/versions/18732

Now that Qt 6 has been out for a while, the version serves no purpose not 
served better otherwise:

 - The "Affects Version/s” field should always have concrete versions, so that 
we can reliably track regressions, etc.

 - Tasks and suggestions don’t mandate that "Affects Version/s” is set, so 
there’s no need to use “6.x” to signify “applies generally”.

 - Some Future Release (https://bugreports.qt.io/projects/QTBUG/versions/11533) 
as "Fix Version/s:” can be used for things that are deferred

 - 7.0 (Next Major Release) 
https://bugreports.qt.io/projects/QTBUG/versions/19400 for as "Fix Version/s:” 
can be used for things that need to wait due to BIC

If you have filters that somehow depend on this specific ‘6.x’ version, please 
update them. Thanks!

Cheers,
Tor Arne




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

Re: [Development] Qt Multimedia: proposing behavior change to QAudioSink::resume

[Tor Arne Vestbø via Development]

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

Re: [Development] New Qt example development guideline and revamping examples

[Tor Arne Vestbø via Development]

On 20 Jan 2023, at 09:49, Eike Ziller  wrote:

Am 19/01/2023 um 13:33 schrieb Giuseppe D'Angelo via Development 
:

Il 19/01/23 10:27, Tor Arne Vestbø ha scritto:
All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. 
Strongly prefer named slots. Keep the lambdas short and to the point. Do not 
use unnamed lambdas.
No, strongly prefer lambdas if they are within a reasonable size. No-one is 
arguing for 200+ line lambdas.

The reason for such a harsh rule is that "reasonable size" tends to go out of 
control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size 
opens up the door to a sorites paradox. The point is that when you write the 
lambda the first time, it'll be completely obvious what it does to you, even if 
it's long. You'll even avoid giving it a name and connect straight to it, as it 
makes "perfect sense", in the context of the code surrounding the lambda.

But on the long run, this makes the code worse to read and understand. No one 
will understand what the lambda is _meant_ to do without analyzing the body of 
the lambda, line by line (cf.: a named lambda/slot, where a proper name tells 
you everything). And reasoning on the code surrounding the lambda is also much 
harder as it's intermingled with the lambda itself.

If anything: the fact that this is seen as _questionable_ and people disagree 
on it should be a good indication that examples shouldn't do it, as examples 
shouldn't feature _questionable_ code styles.

I think with that argument any code style fall apart. People find using "auto" 
questionable, and other people find _not_ using "auto" questionable. Some 
people find that not using braces for bodies of conditional statements, even if 
they are just one line, is questionable, other people find that using braces 
for one-line bodies would bloat the code.

I find not using unnamed lambdas at all questionable. IMO named lambdas are 
worse, since they are also inline inbetween other code in the function, so they 
need to be small too (with the same question of what "small" means), but a 
reader trying to figure out what happens at the place where it is used need to 
redirect to whereever it is defined. Names are often not good enough to convey 
enough meaning, often the actual details matter, and glancing on the handful of 
lines of code directly inline is often faster to read. And not using lambdas at 
all means creating lots of member functions that are only used once, bloat the 
class API, with the same issue of requiring redirection when read, and possibly 
creating class member variables just for use of single methods which could be 
easily solved by capturing in a lambda.

Exactly. All of what Eike said. 200+ line lambdas are bad. So are single-line 
slots that could have been a lambda. Let’s trust people to use good judgement 
to decide each case, including when to rewrite a lambda as a slot when it 
becomes bigger.

Tor Arne


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

Re: [Development] New Qt example development guideline and revamping examples

[Tor Arne Vestbø via Development]

> On 18 Jan 2023, at 13:12, Giuseppe D'Angelo via Development 
>  wrote:
> 
>> RECOMMENDED
>>Prefer signal/slot connection with lambdas: 
>> https://doc.qt.io/qt-6/signalsandslots.html
> 
> All the contrary, do NOT do that, as it results in 200+ lines unnamed 
> lambdas. Strongly prefer named slots. Keep the lambdas short and to the 
> point. Do not use unnamed lambdas.

No, strongly prefer lambdas if they are within a reasonable size. No-one is 
arguing for 200+ line lambdas.

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

Re: [Development] Nominating Mikołaj Boć as approver

[Tor Arne Vestbø via Development]

+1!

(I’m Mikołaj’s direct manager)

On 21 Dec 2022, at 15:21, Morten Sørvig via Development 
 wrote:

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

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

Re: [Development] Nominating Axel Spoerl as approver

[Tor Arne Vestbø via Development]

+1

Very impressed with his fearless adventures into the abyss of flakey tests!

Cheers,
Tor Arne

> On 5 Dec 2022, at 10:57, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> I’d like to nominate Axel Spoerl as an approver for the Qt project.
> 
> Axel has been working in The Qt Company since January, writing tests, 
> analysing and fixing bugs, participating in the port of Qt Speech to Qt 6, 
> investigating and stabilising flaky tests across all platforms, and most 
> recently implementing platform theme support for GTK3-based Linux desktop 
> environments.
> 
> I trust him to be a good approver. Links to gerrit dashboards:
> 
> Patches: https://codereview.qt-project.org/q/owner:axel.spoerl%2540qt.io
> Reviews: https://codereview.qt-project.org/q/reviewer:axel.spoerl%2540qt.io
> 
> Disclosure: I’m Axel’s indirect line manager at The Qt Company in Oslo.
> 
> 
> 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] Nominating Mårten Nordheim and Timur Pocheptsov as new co-maintainers of Qt WebSocket

[Tor Arne Vestbø via Development]

+1

> On 29 Nov 2022, at 14:55, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> Kurt Pattyn is currently listed as the Maintainer fo Qt WebSocket. However, 
> he has not responded to emails I sent him over the last few months. In the 
> middle of October I informed him that I will remove him as maintainer and 
> nominate someone else unless I get a response. I cc’ed Mårten Nordheim in 
> that email. Since I have not received any answer to that email either, I am 
> now going to remove Kurt from the list of maintainers.
> 
> And I’d like to nominate Mårten Nordheim and Timur Pocheptsov as 
> co-maintainers. I’ve confirmed with them, and they would be ok with extending 
> their existing co-maintainership of Qt Network to that module as well.
> 
> 
> 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] I ❤️ Qt containers! :) (was: How qAsConst and qExchange lead to qNN)

[Tor Arne Vestbø via Development]

> On 8 Nov 2022, at 14:25, Volker Hilsheimer via Development 
>  wrote:



Tor Arne

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