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

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

That’s awesome, nice work Gaurav!

- Tor Arne

On 26 Sep 2022, at 18:47, Gaurav Guleria  wrote:



Yes, CPDB is just a different backend for the existing print dialog GUI. It's 
merely a different way of enumerating printers and their features.

I have already prepared a simple CPDB plugin (still requires a few changes and 
additions) which can already respond to QPrinterInfo::availablePrinters() 
queries: https://github.com/TinyTrebuchet/qtbase/commits/cpdb.

On 9/26/22 21:30, Shawn Rutledge wrote:

On 2022 Sep 26, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog.

But it was already pointed out that the widget dialog is intended to look 
exactly the same, right?  This is not a native dialog, it’s just a different 
backend that the same old widget dialog should learn how to deal with, AFAIU.  
And qprintdialog_unix.cpp is really building up the widget hierarchy for it.  
It has a complex feature set.  We haven’t been writing new widgets ourselves, 
and a few more #if’s will be less to maintain than a whole new widget-based 
dialog would be.

Refactoring into whatever plugins or QPA stuff is worth discussing, but I guess 
it will be easier to visualize the refactoring after we’ve got something that 
works.  And I haven’t dug into the implementation enough to think about whether 
anything there is reusable in Qt Quick.  QPrinterInfo is public, so I guess the 
first natural “model” for the dialog is going to end up being the list returned 
from QPrinterInfo::availablePrinters() anyway.




___
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] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 26 Sep 2022, at 17:19, Till Kamppeter  wrote:
> 
> But we must also take into account that Gaurav has not arbitrarily much time. 
> His GSoC project is already in the extension. So he needs to know now how he 
> can get CPDB support in quickly, especially without need to design a new GUI 
> and to create the code for all ins and outs of a print dialog.

Will Gaurav maintain the code if added to the existing print dialogs? If not, I 
guess it’s up to the maintainer of the print dialogs whether they want to take 
on the additional technical debt.

Cheers,
Tor Arne 

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

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

On 26 Sep 2022, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:



On 25 Sep 2022, at 20:58, Albert Astals Cid 
mailto:aa...@kde.org>> wrote:

El dissabte, 24 de setembre de 2022, a les 12:45:00 (CEST), Tor Arne Vestbø va
escriure:
On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria 
mailto:gaurav.g...@gmail.com>>
wrote:

As far as I know, the CUPS is currently implemented in Qt at two different
places: src/plugins/printsupport/cups/ and directly within the dialog
src/printsupport/dialogs/qprintdialog_unix.cpp. By implementing CPDB
support as a plugin, does it mean that we create a similar
src/plugins/printsupport/cpdb which uses CPDB to enumerate printers
instead of CUPS? If so, what about the unix print dialog, don't we need
to add the CPDB code there too (#if QT_CONFIG(cpdb) ... #endif
constructs, just like CUPS)?

The QCupsJobWidget is documented as "a widget to add to QPrintDialog to
enable extra CUPS options such as Job Scheduling, Job Priority or Job
Billing”, so I don’t think having any CPDB specific code in the UNIX print
dialog is required as a first step to bring a CPDB print backend up.

Once we get to that point we can look at possibly adding new API for the
print engines to deal with the needs of QCupsJobWidget and the like, so
that we don’t need CUPS/CPDB specifics in the dialog code.

The "problem" is not QCupsJobWidget, but the print dialog itself.

qprintdialog_unix.cpp and qpagesetupdialog_unix.cpp are full of
#if QT_CONFIG(cups)

IMHO for now the same solution of adding ifdefs should be accepted for CPDB.

Ideally in the future an abstraction so that those ifdefs are not needed
should be introduced, but I have the feeling that asking that abstraction to
be added now is a bit of "asking too much".

Cheers,
Albert

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog. Or rather two implementations, as Shawn has pointed out: one for 
Qt Widgets and one for Qt Quick. And if those two are then based on a common 
abstraction that provides the logic and is informed by what we already have in 
QAbstractPrintDialog - but without the dependency to Qt Widgets - then that 
might perhaps become a basis for what we want in QPA.

Yeah, the print dialogs are much more coupled to the print engines than I 
initially thought/expected. I agree that a separate dialog is preferable to 
adding even more #ifdefs to the existing unix dialog. Then we have a basis for 
possible future abstractions.

Cheers,
Tor Arne

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

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria  wrote:
> 
> As far as I know, the CUPS is currently implemented in Qt at two different 
> places: src/plugins/printsupport/cups/ and directly within the dialog 
> src/printsupport/dialogs/qprintdialog_unix.cpp. By implementing CPDB support 
> as a plugin, does it mean that we create a similar 
> src/plugins/printsupport/cpdb which uses CPDB to enumerate printers instead 
> of CUPS? If so, what about the unix print dialog, don't we need to add the 
> CPDB code there too (#if QT_CONFIG(cpdb) ... #endif constructs, just like 
> CUPS)?

The QCupsJobWidget is documented as "a widget to add to QPrintDialog to enable 
extra CUPS options such as Job Scheduling, Job Priority or Job Billing”, so I 
don’t think having any CPDB specific code in the UNIX print dialog is required 
as a first step to bring a CPDB print backend up.

Once we get to that point we can look at possibly adding new API for the print 
engines to deal with the needs of QCupsJobWidget and the like, so that we don’t 
need CUPS/CPDB specifics in the dialog code.

Cheers,
Tor Arne

> 
> On 9/19/22 21:59, Tor Arne Vestbø wrote:
>> 
>>> On 19 Sep 2022, at 18:21, Till Kamppeter  wrote:
>>> 
>>> On 19/09/2022 15:43, Tor Arne Vestbø wrote:
>>>>> First is to create a new Qt print backend, what, instead of communicating 
>>>>> directly with CUPS, communicates with the CPDB backends. It is some kind 
>>>>> of "middle end", on one end being a Qt print backend and on the other end 
>>>>> being a CPDB frontend.''
>>>> This sounds like a good first step. It doesn’t involve any of the GUI 
>>>> bits, just the enumeration and communication with the various CPDB-exposed 
>>>> printers.
>>>> Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the 
>>>> CPDB print backend should be a plugin.
>>>> 
>>> OK, Gaurav so you should be able to provide the CPDB support as a plugin 
>>> (Tor, is this a Qt print backend like the one for CUPS for example?).
>> Correct. Note that for Qt 6, some of the print engines that were previously 
>> plugins were moved into the QtPrintSupport library directly, such as the 
>> macOS print engine, but the interface for enumerating these from Qt’s point 
>> of view is still as print engine “plugins”. The CUPS engine is a fully 
>> standalone plugin, so it’s a good basis for the CPDB work.
>> 
>> Cheers,
>> Tor Arne
>> 
>> ___
>> 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] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 19 Sep 2022, at 18:21, Till Kamppeter  wrote:
> 
> On 19/09/2022 15:43, Tor Arne Vestbø wrote:
>>> 
>>> First is to create a new Qt print backend, what, instead of communicating 
>>> directly with CUPS, communicates with the CPDB backends. It is some kind of 
>>> "middle end", on one end being a Qt print backend and on the other end 
>>> being a CPDB frontend.''
>> This sounds like a good first step. It doesn’t involve any of the GUI bits, 
>> just the enumeration and communication with the various CPDB-exposed 
>> printers.
>> Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the 
>> CPDB print backend should be a plugin.
>> 
> 
> OK, Gaurav so you should be able to provide the CPDB support as a plugin 
> (Tor, is this a Qt print backend like the one for CUPS for example?).

Correct. Note that for Qt 6, some of the print engines that were previously 
plugins were moved into the QtPrintSupport library directly, such as the macOS 
print engine, but the interface for enumerating these from Qt’s point of view 
is still as print engine “plugins”. The CUPS engine is a fully standalone 
plugin, so it’s a good basis for the CPDB work.

Cheers,
Tor Arne 

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

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 19 Sep 2022, at 00:51, Till Kamppeter  wrote:

> We do not do any GUI design or change as part of our project. We only add a 
> new method to obtain the available printers, their capabilities and options, 
> and to send off print jobs to them.

That’s good news.

> 
> First is to create a new Qt print backend, what, instead of communicating 
> directly with CUPS, communicates with the CPDB backends. It is some kind of 
> "middle end", on one end being a Qt print backend and on the other end being 
> a CPDB frontend.''

This sounds like a good first step. It doesn’t involve any of the GUI bits, 
just the enumeration and communication with the various CPDB-exposed printers.

Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the CPDB 
print backend should be a plugin.

> The second is to throw the backend concept of the Qt dialog over board and 
> replace it by CPDB, the Qt print dialog itself using cpdb-libs to connect to 
> backends, which are now only the CPDB backends, no Qt print backends any 
> more. By conditional compiling one could decide here at build time to use the 
> CPDB concept, the old Qt print backend concept, or both (and in that case 
> which has priority).

This can only be done if CPDB is available on all platforms Qt supports.

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

Re: [Development] Nominating David and Eskil as Qt Wayland maintainers

[Tor Arne Vestbø]

+1 !

Cheers,
Tor Arne

> On 24 Aug 2022, at 10:36+02:00, Volker Hilsheimer  
> wrote:
> 
> Hi,
> 
> 
> Giulio has informed me that he won’t be able to continue as the maintainer of 
> Qt Wayland. Thanks Giulio for your contribution!
> 
> Qt Wayland is currently listed as a single module on the wiki, but The 
> qtwayland repository falls into two modules that share a bit of code and need 
> to be reasonably well aligned to correctly support Qt specific protocol 
> extensions:
> 
> - Qt Wayland Client, which includes the QPA plugin that is used by Qt 
> applications running on Wayland
> 
> - Qt Wayland Compositor, with C++ and QML types developing of custom display 
> servers
> 
> 
> I’d like to nominate David Edmundson (davidedmund...@kde.org) as the 
> maintainer of the Qt Wayland Client module, and Eskil Abrahamsen Blomfeld 
> (eskil.abrahamsen-blomfe...@qt.io) as the maintainer of the Qt Wayland 
> Compositor module. They both have a long track record of working on Qt 
> Wayland [1] [2], and have been setting the direction of the module together 
> with other contributors e.g. during respective sessions at Qt Contributors 
> Summits. They have both agreed to take on the responsibility.
> 
> 
> [1] 
> https://codereview.qt-project.org/q/repo:qt/qtwayland+owner:davidedmundson%2540kde.org
> [2] 
> https://codereview.qt-project.org/q/repo:qt/qtwayland+owner:eskil.abrahamsen-blomfeldt%2540qt.io
> 
> 
> 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] Windows plugin customisation: QWindowsKeyMapper

[Tor Arne Vestbø]

On 30 Jul 2022, at 18:29, Laszlo Papp mailto:lp...@kde.org>> 
wrote:

Thanks.

Should the event first be sent to the application and only if not handled, 
passed to Windows?

I guess that depends on what your goal is. The default implementation calls 
showSystemMenu(), so it doesn’t seem to pass through the app AFAICT.

Tor Arne


On Sat, Jul 30, 2022 at 5:15 PM Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:
Actually, you might be able to filter out the event via

https://doc.qt.io/qt-6/qcoreapplication.html#installNativeEventFilter

And pass it on manually to windows via DefWindowProc

Tor Arne

On 30 Jul 2022, at 18:12, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Hi,

I don’t think there’s any way to customize that behavior today, apart from 
maintaining a customized version of the Windows platform plugin.

You could perhaps have some luck intercepting WM_APPCOMMAND before it reaches 
the Qt message proc?

Tor Arne

On 30 Jul 2022, at 14:12, Laszlo Papp mailto:lp...@kde.org>> 
wrote:

Hi,

What is the recommended way to customise the behaviour of built-in plugins, 
like a windows plugin , QWindowsKeyMapper in particular?

To be specific, if we wanted to pass this alt+space to the application rather 
than Qt forwarding it to Windows, the operating system? Like a potential break 
here before showing the system menu?

https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/windows/qwindowskeymapper.cpp#n1219

Trying to figure out what the most forward-looking and future proof way rather 
than directly modify vanilla Qt.

Another use case (not ours) that I was told is that if someone writes a remote 
desktop client in Qt and it is desirable to pass alt+f4 to this application to 
process it inside the guest as opposed to closing the remote desktop Qt 
application or something similar.

One idea is environment variables, but may not be the best. Seeking your input 
and hope we can sort this out together.

Thank you in advance!

Kind regards,
László
___
Development mailing list
Development@qt-project.org<mailto: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] Windows plugin customisation: QWindowsKeyMapper

[Tor Arne Vestbø]

Actually, you might be able to filter out the event via

https://doc.qt.io/qt-6/qcoreapplication.html#installNativeEventFilter

And pass it on manually to windows via DefWindowProc

Tor Arne

On 30 Jul 2022, at 18:12, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Hi,

I don’t think there’s any way to customize that behavior today, apart from 
maintaining a customized version of the Windows platform plugin.

You could perhaps have some luck intercepting WM_APPCOMMAND before it reaches 
the Qt message proc?

Tor Arne

On 30 Jul 2022, at 14:12, Laszlo Papp mailto:lp...@kde.org>> 
wrote:

Hi,

What is the recommended way to customise the behaviour of built-in plugins, 
like a windows plugin , QWindowsKeyMapper in particular?

To be specific, if we wanted to pass this alt+space to the application rather 
than Qt forwarding it to Windows, the operating system? Like a potential break 
here before showing the system menu?

https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/windows/qwindowskeymapper.cpp#n1219

Trying to figure out what the most forward-looking and future proof way rather 
than directly modify vanilla Qt.

Another use case (not ours) that I was told is that if someone writes a remote 
desktop client in Qt and it is desirable to pass alt+f4 to this application to 
process it inside the guest as opposed to closing the remote desktop Qt 
application or something similar.

One idea is environment variables, but may not be the best. Seeking your input 
and hope we can sort this out together.

Thank you in advance!

Kind regards,
László
___
Development mailing list
Development@qt-project.org<mailto: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] Windows plugin customisation: QWindowsKeyMapper

[Tor Arne Vestbø]

Hi,

I don’t think there’s any way to customize that behavior today, apart from 
maintaining a customized version of the Windows platform plugin.

You could perhaps have some luck intercepting WM_APPCOMMAND before it reaches 
the Qt message proc?

Tor Arne

On 30 Jul 2022, at 14:12, Laszlo Papp mailto:lp...@kde.org>> 
wrote:

Hi,

What is the recommended way to customise the behaviour of built-in plugins, 
like a windows plugin , QWindowsKeyMapper in particular?

To be specific, if we wanted to pass this alt+space to the application rather 
than Qt forwarding it to Windows, the operating system? Like a potential break 
here before showing the system menu?

https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/windows/qwindowskeymapper.cpp#n1219

Trying to figure out what the most forward-looking and future proof way rather 
than directly modify vanilla Qt.

Another use case (not ours) that I was told is that if someone writes a remote 
desktop client in Qt and it is desirable to pass alt+f4 to this application to 
process it inside the guest as opposed to closing the remote desktop Qt 
application or something similar.

One idea is environment variables, but may not be the best. Seeking your input 
and hope we can sort this out together.

Thank you in advance!

Kind regards,
László
___
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] Feature freeze exception for permission API

[Tor Arne Vestbø]

Hi,

The permission API (https://bugreports.qt.io/browse/QTBUG-90498 / 
https://codereview.qt-project.org/c/qt/qtbase/+/409324) was planned for Qt 6.4, 
but unfortunately did not stabilize enough in time for the freeze.

To avoid pushing the API to 6.5, and to get some user feedback on the both the 
APIs, the implementation, and the use-cases, we’re hoping to make the APIs 
tech-preview/preliminary in 6.4.

The API itself is self-contained and fairly minimal, not affecting other parts 
of Qt, so the risk is low, and if we last minute find issues we can disable it 
entirely via the Qt configure system.

The remaining work to get it into tech-preview/preliminary shape is expected to 
take another week.

Given the above, would it be possible to grant a feature freeze exemption until 
end of next week for this feature?

Cheers,
Tor Arne

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

Re: [Development] Using Git notes to reflect actual cherry-picks

[Tor Arne Vestbø]

See comment in review.

I think a prerequisite for running this kind of script against our repos is 
that the notes are namespaced, e.g. refs/notes/cherry-picks so that fetching 
and showing them in git log output is optional.

Other than that I think it’s a nice feature :)

Tor Arne

On 25 May 2022, at 04:50, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Saturday, 5 March 2022 11:07:17 PDT Thiago Macieira wrote:
All this requires is that someone run a cron job every week and have
rights
to push to the refs/notes/* hierarchy.

Anyone?

No one?

The script here is working.
https://codereview.qt-project.org/c/qt/qtbase/+/395465

--
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] Jira tickets for Qt Print Support (Was: Volunteer wanted: update use of CUPS API)

[Tor Arne Vestbø]

On 5 May 2022, at 10:32, Alex Blasche 
mailto:alexander.blas...@qt.io>> wrote:

-Original Message-
From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Sze
Howe Koh
On Mon, 4 May 2020 at 15:19, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

On 4 May 2020, at 09:08, Albert Astals Cid via Development
mailto:development@qt-project.org>> wrote:

P.S: Someone should really really remove John Layt as printinting
mantainer stuff, i don't think he's been around for years.

Agreed. I’ll remove him.

Cheers,
Lars

All of the printing-related tickets still get auto-assigned to John.
There are lots of recently-opened ones:

The much more difficult question is who the new default assignee is. Was this 
anywhere mentioned?

Otherwise, it makes no difference whether John is the auto assignee or not.

If there is no maintainer then the default assignee should be “Unassigned”. 
Although that might not make any difference in practice of fixing those issue, 
it does make a difference in being honest about the situation.

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

Re: [Development] Nominating David Skoland as approver

[Tor Arne Vestbø]

+1!

Disclaimer: I am David's line manager in The Qt Company.

Cheers,
Tor Arne

On 21 Apr 2022, at 14:00, Morten Sørvig 
mailto:morten.sor...@qt.io>> wrote:

I'd like to nominate David Skoland as approver for the Qt Project.

David is employed by the Qt company has been contributing to Qt since late 
2020, with patches and reviews to several modules. He has recently shifted 
focus to work on Qt for WebAssembly, where he’s already made several good 
contributions and is currently taking on getting auto-tests running in the CI 
system.

I trust him to be a good approver.

https://codereview.qt-project.org/q/owner:david.skoland%2540qt.io
https://codereview.qt-project.org/q/reviewer:david.skoland%2540qt.io

Best Regards,
Morten Sørvig


___
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 Morten Sørvig as maintainer of high-DPI

[Tor Arne Vestbø]

This has now been effectuated: https://wiki.qt.io/Maintainers#Qt_Maintainers

Cheers,
Tor Arne

On 4 Jan 2022, at 16:18, Eirik Aavitsland 
mailto:eirik.aavitsl...@qt.io>> wrote:

+1!

- Eirik Aa.

On 12/20/21 4:35 PM, Tor Arne Vestbø wrote:
Hello all,
I’d like to nominate Morten Sørvig as maintainer of high-DPI in the Qt Project 
[1].
Morten has been instrumental in the development of Qt’s high-DPI support, and 
has been the de-factor maintainer for a while now. Let’s make it official.
Cheers,
Tor Arne
[1] Under qtbase/QtGui in https://wiki.qt.io/Maintainers 
<https://wiki.qt.io/Maintainers>
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org<mailto: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 Git notes to reflect actual cherry-picks

[Tor Arne Vestbø]

Very cool! As ossi suggests, this could potentially be handled by Gerrit, 
similar to this:

https://gerrit.googlesource.com/plugins/reviewnotes/%2B/master/src/main/resources/Documentation/refs-notes-review.md

If we enable something like this we should namespace the notes, e.g. 
refs/notes/cherry-picks so that fetching and showing them in git log output is 
optional.

Cheers,
Tor Arne

sOn 12 Feb 2022, at 08:04, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

Implementation: https://codereview.qt-project.org/c/qt/qtbase/+/395465
(I don't think qtbase is the right place for this)

TL;DR:
I'd like to propose we use Git notes to include information into commits about
successful cherry-picks. I have the scripts done, see above. All we need is
that they are run weekly or the results pushed into the repository.

Long version:
The Pick-To footer is very useful so we don't have to remember to actually
cherry-pick a commit when it's done integrating: the bot will take care of
doing that for us and let us know if it fails. However, it's not reliable:

* a change may be abandoned in Gerrit after the bot started with it (too
  difficult to continue, author didn't realise it didn't apply, etc.)
* a change may be cherry-picked without the footer, either in Gerrit or
  directly using git cherry-pick -x

For that reason, I'd like to ask that we add the use of notes, to indicate
cherry-picks that have succeeded. Moreover, it will tell the user what commit
exists in that particular branch. For example, after running the script, I see
for a commit of mine:

   Pick-to: 6.2.3 6.2 6.3
   Change-Id: Icad7c1bad46a449c8e8afffd16cb743e622b3405
   Reviewed-by: Lars Knoll mailto:lars.kn...@qt.io>>

Notes:
   Cherry-picks:
   6.3: 34545edc501947a498bc6b1873624a5e307a7b1a

That tells us that the cherry-picks to 6.2 and 6.2.3 aren't present (I
abandoned after conflicts happened).

Similarly:

   Fixes: QTBUG-99668
   Pick-to: 6.3 6.2 6.2.3 5.15
   Change-Id: I07321ad91be5adce524be18e4ab82eee7110dc6a
   Reviewed-by: Mårten Nordheim 
mailto:marten.nordh...@qt.io>>

Notes:
   Cherry-picks:
   6.2.3: 4db05007d72963c082f3ffdfcc7a68c1fb53c266
   6.3: 84ab463aa3e75c2b78f99d62c95577c6a0b5950f

This one looks wrong: 6.2.3 is present but not 6.2, So I searched Gerrit and
indeed, the change simply failed in the CI 3 weeks ago and no one pushed the
button again.

The scripts are pretty fast, but I've also made them work incrementally. See
the attached run example.
--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel DPG 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] XCB platform plugin maintainer change

[Tor Arne Vestbø]

+1!

On 1 Feb 2022, at 10:50, Gatis Paeglis 
mailto:gatis.paeg...@qt.io>> wrote:

Hi all,

I would like to propose a change in Qt's Linux/XCB maintainership.
Since 2019, I have moved full time to the Qt for MCUs project and
there is no time left for XCB work.

/qtbase/src/plugins/platforms/xcb$ git shortlog --since=2021 --no-merges -s -n .

11  Liang Qi
     6  Tor Arne Vestbø
 3  Gatis Paeglis

I would like to propose Liang Qi as the new maintainer. He has been
with the company for more than a decade.

Gatis Paeglis.
___
Development mailing list
Development@qt-project.org<mailto: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] Proposing to officially allow C++20 types in Qt 6 ABIs

[Tor Arne Vestbø]

> On 27 Jan 2022, at 18:14, Thiago Macieira  wrote:
> 
> On Thursday, 27 January 2022 08:53:31 PST Tor Arne Vestbø wrote:
>> I don’t know what other things you’re referring to, but just to clarify,
>> this is not the case for macOS. We build the binary Qt packages with as
>> recent of an Xcode (and corresponding toolchain) as we have available in
>> the CI, typically the latest version.
> 
> The Xcode case has the same constraint, just a different implementation of it.
> 
> We use the latest compiler and the latest SDK that Apple provides for us, but 
> we set the minimum macOS target (and the other Apple platforms) to the 
> minimum 
> that we still support. That has the effect that functions that have been 
> added 
> to the SDK since that minimum become weak symbols, which allow us to verify 
> whether they are present at runtime.

Right, I’m aware, just wanted to make sure we were on the same page on that bit 
:) 

Thanks!

Cheers,
Tor Arne

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

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Tor Arne Vestbø]

> On 27 Jan 2022, at 17:19, Thiago Macieira  wrote:
> 
> We know a great deal of our users use the binary builds by the Qt Company. In 
> order to make those the most widely supported, they are compiled with the 
> oldest compiler we still support. 

I don’t know what other things you’re referring to, but just to clarify, this 
is not the case for macOS. We build the binary Qt packages with as recent of an 
Xcode (and corresponding toolchain) as we have available in the CI, typically 
the latest version.

Cheers,
Tor Arne

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

Re: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Tor Arne Vestbø]

+1!

> On 25 Jan 2022, at 09:38, Richard Gustavsen  wrote:
> 
> Hi all!
> 
> I would like to propose a change in the maintenance of Qt Widgets [1]. I’m 
> the current maintainer of the module, but I’m happy to inform you that Volker 
> Hilsheimer has agreed to join me as a co-maintainer. Volker is one of the 
> biggest contributors to Widgets [2], and has been helping out maintaining the 
> module for a long time already. So let’s make it formal as well!
> 
> [1] https://wiki.qt.io/Maintainers#Qt_Maintainers
> [2] 
> https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged
> 
> Best Regards,
> Richard Moe Gustavsen
> Principal Engineer
> The Qt Company
> Oslo, Norway
> 
> ___
> 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 Dimitrios "Jimis" Apostolou as Approver

[Tor Arne Vestbø]

+1!

> On 19 Jan 2022, at 12:59, Volker Hilsheimer  wrote:
> 
> Hi,
> 
> I’d like to nominate Dimitrios Apostolou, aka Jimis, as approver in the Qt 
> Project.
> 
> Jimis has been working as a Software Engineer in the Qt Company since 2019 
> and has made a number of contributions [0] and reviews [1]. Most of his work 
> happens in the build and test machinery and the infrastructure around it, 
> which doesn’t leave a lot of traces in gerrit. I appreciate Jimis as a 
> passionate, knowledgable, and open minded software developer and systems 
> engineer, and I trust that he’ll use the approver status responsibly.
> 
> Disclaimer: Jimis reports to me in The Qt Company.
> 
> 
> Volker
> 
> 
> [0] - https://codereview.qt-project.org/q/owner:jimis%2540qt.io
> [1] - https://codereview.qt-project.org/q/reviewedby:jimis%2540qt.io
> 
> ___
> 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] Updating x86 SIMD support in Qt

[Tor Arne Vestbø]

Hey hey,

On 19 Jan 2022, at 04:01, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

3) add a way to have multi-arch glibc-based Linux builds

If we go down this road I ask that we align both the porcelain and plumbing 
(configure, build system, C++ APIs, etc) . We already have universal builds on 
macOS and iOS done one way, and multi-arch/abi on Android another way. Let’s 
not add a third slightly different way, but instead use the opportunity to pay 
off some of the technical debts in this area.


4) up the defaults from where they are today

Question:
- iOS simulator builds are x86, but currently only SSE2. Does anyone know if
raising to SSE4, which *ALL*  64-bit Mac machines support, would be a problem?

That should be fine. The only reason SSE2 was chosen at the time was to ensure 
we built the draw helpers for the simulator build.

6) for macOS, raise the minimum to v3 (x86_64h)


macOS has supported an extra architecture called "x86_64h" for some time (the
"h" stands for "haswell"). Apple ceased offering macOS updates to processors
without AVX2 back with the Mojave release (10.14) in 2018. Since that's the
minimum version we require for Qt, it means all Intel-based Macs Qt can run on
also support this sub-arch.

One data point here, that I don’t know is worth anything, is that on macOS 12 
at least, none of the system binaries in /bin or /sbin are x86_64h, they are 
all x86_64+arm64e (arm64e reserved for Apple for now).

On the other hand, the dyld shared cache (of all the system frameworks) 
provides x86_64h:

❯ ls /System/Library/dyld/
aot_shared_cache.0aot_shared_cache.3
aot_shared_cache.t8027.2  dyld_shared_cache_arm64e.1
dyld_shared_cache_x86_64.1dyld_shared_cache_x86_64.map  
dyld_shared_cache_x86_64h.2
aot_shared_cache.1aot_shared_cache.t8027.0  
aot_shared_cache.t8027.3  dyld_shared_cache_arm64e.map  
dyld_shared_cache_x86_64.2dyld_shared_cache_x86_64h 
dyld_shared_cache_x86_64h.3
aot_shared_cache.2aot_shared_cache.t8027.1  
dyld_shared_cache_arm64e  dyld_shared_cache_x86_64  
dyld_shared_cache_x86_64.3dyld_shared_cache_x86_64h.1   
dyld_shared_cache_x86_64h.map

It might also need some more work than just changing our default. E.g, changing 
the arch in a simple Xcode project gives:

The run destination My Mac is not valid for Running the scheme 'rasterwindow’.
My Mac doesn’t support any of rasterwindow.app’s architectures. You can set 
rasterwindow.app’s Architectures build setting to Standard Architectures to 
support My Mac.

This is on a 2019 MBP

Xcode’s ARCH_STANDARD build variable is [x86_64, arm64].

The same problem persists after updating VALID_ARCHS from the default [arm64 
arm64e i386 x86_64] to [arm64 arm64e i386 x86_64 x86_64h].

I'd like to do this for all libraries and by default on binaries from 
qt.io.
However, I understand the ARM translation application cannot deal with the AVX
instructions, so it would fail to run our default binaries for the
applications that couldn't rebuild as ARM. Is it acceptable to require those
application developers to rebuild Qt from source?

I believe we detect that situation at runtime and explicitly turn off AVX 
support, so we wouldn’t be hitting any of those AVX code paths, if I understand 
things correctly?

Cheers,
Tor Arne

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

[Development] Nominating Morten Sørvig as maintainer of high-DPI

[Tor Arne Vestbø]

Hello all,

I’d like to nominate Morten Sørvig as maintainer of high-DPI in the Qt Project 
[1].

Morten has been instrumental in the development of Qt’s high-DPI support, and 
has been the de-factor maintainer for a while now. Let’s make it official.

Cheers,
Tor Arne

[1] Under qtbase/QtGui in https://wiki.qt.io/Maintainers

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

Re: [Development] Qt 6 not seeing the same DPI as Qt 5

[Tor Arne Vestbø]

On 29 Nov 2021, at 23:43, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Monday, 29 November 2021 13:20:58 PST Tor Arne Vestbø wrote:
If you know that the physical DPI being reported is correct you can use
QT_USE_PHYSICAL_DPI to override the behavior as documented.

I did, but that makes no difference:

$ QT_USE_PHYSICAL_DPI=1 ~/obj/qt/installed/bin/qtdiag | grep DPI
 QT_USE_PHYSICAL_DPI="1"
Screens: 2, High DPI scaling: active
 Physical DPI: 120.118,120 Logical DPI: 96,96 Subpixel_None
 High DPI scaling factor: 2 DevicePixelRatio: 2
 Physical DPI: 120.118,120 Logical DPI: 96,96 Subpixel_None
 High DPI scaling factor: 2 DevicePixelRatio: 2

The priority matters, so perhaps you have set one of the other things we might 
pick up? Xft/DPI or Xft.dpi?

https://doc-snapshots.qt.io/qt6-dev/highdpi.html#configuring-x11

Cheers,
Tor Arne

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

Re: [Development] Qt 6 not seeing the same DPI as Qt 5

[Tor Arne Vestbø]

On 29 Nov 2021, at 19:05, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Monday, 29 November 2021 09:09:16 PST Tor Arne Vestbø wrote:
What's changed between 5 and 6?

https://doc-snapshots.qt.io/qt6-dev/highdpi.html#configuring-x11

Thanks, Tor Arne. I see in the link that the RandR physical DPI is marked "Qt
5 only". Why did we remove this?

It wasn’t removed per se, but we no longer pick it up by default.

The rationale for that was that physical DPI is not the same as logical DPI, 
plus that physical DPI reporter by RandR may sometimes be wildly inaccurate, 
giving surprising results for users if we picked it up.

If you know that the physical DPI being reported is correct you can use 
QT_USE_PHYSICAL_DPI to override the behavior as documented.

Sadly X doesn’t expose any per-monitor logical DPI. Some desktop environments 
solve it pretending like everything is rendered at 2x, with an Xft.dpi that 
matches, and then downscaling to the target monitor.

We tried to open a discussion about how to treat the various X DPI settings, 
logical or physical, in 
https://lists.x.org/archives/xorg-devel/2020-September/058612.html, but sadly I 
got pulled in to other stuff and wasn’t able to follow up, and there wasn’t any 
reply from the X core developers, so it stalled.

If we change things in Qt I would prefer to align how Qt behaves in this regard 
with a clear authoritative guideline from the X people on how to interpret each 
setting, and preferably this would be aligned across toolkits as well.

Cheers,
Tor Arne

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

Re: [Development] Qt 6 not seeing the same DPI as Qt 5

[Tor Arne Vestbø]

Cheers,
Tor Arne

On 29 Nov 2021, at 17:41, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

I'll probably have to report this as a bug, but just in case someone has seen
it before:

$ diff -u qtdiag5 qtdiag6
[...]
  Geometry: 1920x1200+0+0 (native: 3840x2400+0+0) Available: 1920x1200+0+0
  Virtual geometry: 5760x1200+0+0 Available: 5760x1200+0+0
  2 virtual siblings
-  Physical size: 288x180 mm  Refresh: 59.9939 Hz Power state: 0
-  Physical DPI: 169.333,169.333 Logical DPI: 120.118,120 (native:
240.236,240) Subpixel_None
+  Physical size: 406x228.6 mm  Refresh: 29.9806 Hz Power state: 0
+  Physical DPI: 120.118,120 Logical DPI: 96,96 Subpixel_None
  High DPI scaling factor: 2 DevicePixelRatio: 2

Qt 5 agrees with xrandr:
$ xrandr | grep eDP-1
eDP-1 connected primary 3840x2400+0+0 (normal left inverted right x axis y
axis) 288mm x 180mm

I start X with the "-dpi 240" setting, which gives me the best font size to
work on either display. Qt 5 obeys it just fine, dividing it by 2 because of
the scale factor, so my desktop looks fine. However, the one Qt 6 application
I use (Qt Creator) does not and has tiny fonts. I can override it with
QT_FONT_DPI=240 in the environment, but shouldn't have to.

That logical DPI of 96 makes zero sense. It's not physically correct and is
not part of the X config. Where is it coming from?

What's changed between 5 and 6?

https://doc-snapshots.qt.io/qt6-dev/highdpi.html#configuring-x11

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

Re: [Development] Proposing to move deploy tools to qtbase

[Tor Arne Vestbø]

Agreed, +1

Cheers,
Tor Arne

On 16 Nov 2021, at 15:23, Ulf Hermann 
mailto:ulf.herm...@qt.io>> wrote:

I’m working on adding new CMake APIs for install support for Qt 6.3. As part of 
that, there will be conveniences for invoking the appropriate xxxdeployqt tool 
where available. At the moment, macdeployqt and windeployqt live in qttools, 
whereas androiddeployqt lives in qtbase. I’d like to propose moving macdeployqt 
and windeployqt to qtbase as well.

+1

Installation and deployment has to be part of the core functionality of Qt's 
build system, not some afterthought.
___
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] Jira and issues left "In Progress"

[Tor Arne Vestbø]

On 1 Nov 2021, at 12:27, David Skoland 
mailto:david.skol...@qt.io>> wrote:

One caveat: Jira has no state for indicating "the work is done but not
yet integrated"

This is a good point. We could add a state in Jira called something like “Patch 
submitted” in the In Progress status category. Moreover, it’s even possible to 
automate state change to this whenever a change is submitted in Gerrit with 
either the Fixes or the Task footer.

There may be many reasons why a task is “In progress” but has not transitioned 
out of that state yet. I do not think we need to model all the intermediate 
steps involved in “in progress”, the JIRA workflow is complicated enough as it 
is :)

The state of any submitted patches should be visible from the JIRA Gerrit 
integration in any case.

tor arne


Cheers,

David Skoland

On 29 Oct 2021, at 10:39, Edward Welbourne 
mailto:edward.welbou...@qt.io>> wrote:

On Thursday, 28 October 2021 06:44:43 PDT Alex Blasche wrote:
My proposal would be to return every "In Progress" issue to "Open"
if there was no change for 3 month.

I'd appreciate your feedback.

Thiago Macieira (28 October 2021 17:51) replied
That's probably sufficient nagging to the current assignee if they
forgot the issue in that state. If it still in progress after that
long, they can move it back to In Progress for another 3 months.

Indeed.

I take it the return to Open would come with a message saying what the
'bot is doing and why; that could include a gentle encouragement to at
least add an update comment saying what the current state is and what's
causing the delay.

Lars Knoll mailto:lars.kn...@qt.io>> (29 October 2021 09:56) 
replied:
+1 from my side. If nothing has happened to the task for 3 months,
it’s very likely there’s no progress.

One caveat: Jira has no state for indicating "the work is done but not
yet integrated" - which most commonly happens due to delays in review,
but could also happen in other cases like needing help with testing
whether the fix really has fixed the reporter's problem.  As a result,
In Progress can just mean "review is taking a long time" or "waiting for
a device to test it on".  None the less, the flip-flop in state would be
constructive, giving the reporter and fixer a reminder to poke relevant
folk to move the work forward.

Eddy.
___
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 Oliver Eftevaag as Approver

[Tor Arne Vestbø]

+1

On 27 Oct 2021, at 06:25, Paul Wicking 
mailto:paul.wick...@qt.io>> wrote:

Hi all,

I'd like to nominate Oliver Eftevaag as an approver.

Oliver has been working as a software engineer for the Qt Company for almost a 
year now and has made a fair number of contributions to Qt [0]. He also 
participates actively in reviews [1]. He's curious and passionate about 
learning new things, and happy to share his knowledge with his colleagues.

I trust he'll use the approver rights responsibly.

Disclaimer: we sporadically meet for lunch or by the coffee machine.

//! Paul

[0] - 
https://codereview.qt-project.org/q/owner:oliver.eftevaag%2540qt.io
[1] - 
https://codereview.qt-project.org/q/reviewer:oliver.eftevaag%2540qt.io
___
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 Doris Verria as Approver

[Tor Arne Vestbø]

+1

> On 27 Oct 2021, at 11:56, Volker Hilsheimer  wrote:
> 
> Hello World,
> 
> I’d like to nominate Doris Verria as approver in the Qt Project.
> 
> Doris has been working as a Software Engineer for The Qt Company for over a 
> year, and has made great contributions to Qt [0]. I have come to appreciate 
> her as a coder that bravely takes on new challenges, and as a thorough code 
> reviewer [1].
> 
> I’ll trust she’ll use the approver rights responsibly.
> 
> Disclaimer: Doris reports directly to me in The Qt Company.
> 
> Volker
> 
> 
> [0] https://codereview.qt-project.org/q/owner:doris.verria%2540qt.io
> [1] https://codereview.qt-project.org/q/reviewer:doris.verria%2540qt.io
> 
> 
> ___
> 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] Qt Android Extras "stopgap"

[Tor Arne Vestbø]

On 18 Sep 2021, at 11:43, Jarkko Koivikko 
mailto:jarkko.koivi...@code-q.fi>> wrote:

The correct header is:

#include 

Thanks, updated blog post, docs will follow.

Cheers,
Tor Arne


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

Re: [Development] Feature freeze exception for QTBUG-95587

[Tor Arne Vestbø]

I agree, this feels like it should have some wider discussion.

Cheers,
tor arne 

> On 13 Sep 2021, at 13:27, André Somers  wrote:
> 
> 
> On 09-09-2021 17:32, Ulf Hermann wrote:
>> Hello,
>> 
>> due to the magnitude of the above mentioned bug, I'm considerng to introduce 
>> a new feature in Qt 6.2.1. The new "@" operator in QML relieves you from 
>> typing "Qt.resolvedUrl" over and over. See 
>> https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987
>> 
>> Now the question is whether we want to relax the feature freeze for this 
>> particular issue or not.
>> 
> To me, the fact that this raises discussion on if this syntax should have 
> other applications perhaps already justifies a "no" to your actual question: 
> should this be allowed in a bugfix release.
> 
> I would think not just a small library tool but an actual language change 
> warrants a bit more consideration and should not be introduced in a what is 
> supposed to be a bugfix release. This is more than just a bugfix, it's a 
> significant feature. Adding those without giving them proper consideration 
> seems to be an excellent way to grow ugly warts on the language that will be 
> very hard to plaster over later on.
> 
> Cheers,
> 
> André
> 
> 
> ___
> 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] Merging qtquickcontrols2 into qtdeclarative

[Tor Arne Vestbø]

On 12 Jul 2021, at 21:19, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

So a full history import MAY have negligible marginal impact over a squashed
import (.git is compressed). I recommend trying both and seeing by how much
the qtdeclarative repository increases, then deciding whether "git blame" and
"git log" working out of the box without a "git replace" is worth the extra
cost.

That’s a good point.

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

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Tor Arne Vestbø]

On 12 Jul 2021, at 17:03, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:

On Mon, Jul 12, 2021 at 02:17:01PM +0000, Tor Arne Vestbø wrote:
One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

it would be actually also just a subtree merge, but of a re-import, to which 
the old history would be grafted (that is, git-replaced when using up-to-date 
git mechanisms).
that would avoid duplicating the history, which would make the repo somewhat 
smaller and leave us with only one authoritative copy of said history (the 
original module will have to stay around for quite a while and keep receiving 
fixes anyway).

Ah, right, so a subtree merge of a “Import controls2” squashed commit that is 
then grafted to point to the old repo’s history if needed for log/bisects (or 
something along those line).

Can you help out with the concrete git steps that are needed for that since you 
have the flow mapped out better than me and Mitch?

Thanks!

Cheers,
Tor Arne



___
Development mailing list
Development@qt-project.org<mailto: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] Merging qtquickcontrols2 into qtdeclarative

[Tor Arne Vestbø]

One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

Cheers,
Tor Arne

On 12 Jul 2021, at 14:42, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

Hi.

The consensus from the contributor's summit session regarding 
https://bugreports.qt.io/browse/QTBUG-79454 was that qtquickcontrols2 should be 
merged into qtdeclarative:

https://wiki.qt.io/QtCS2021_-_Testing_upstream_changes_with_downstream_modules#Move_specific_modules_into_the_repository_of_the_module_they_depend_on

In terms of Git, what is the best way to proceed with this? Which commands 
should be used? Any specific things to be aware of? For example, one note made 
during the session was:

“Graft history in, don't merge it.”

Cheers.
___
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] Version-controlling the SVGs of built-in icons

[Tor Arne Vestbø]

Hey hey, 

Thanks for bringing this up, I’ve been in that situation myself, for example 
looking for diagrams in the documentation.

I generally think that assets that make up a product should live together. That 
is, the source code, image assets, docs, examples, tests, etc, for a 
module/library.

I understand the argument of easier access for digital artists, but I think 
that can be solved by partial/sparse git clones and the like, at least to a 
degree that votes in favour of keeping stuff together.

Cheers,
tor arne

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

Re: [Development] Windows maintainer change

[Tor Arne Vestbø]

Hear hear! +1

> On 15 Jun 2021, at 11:05, Shawn Rutledge  wrote:
> 
> +1
> 
> Thanks for the work that all 3 of you have put into it over the years.
> 
>> On 15 Jun 2021, at 09:27, Oliver Wolff  wrote:
>> 
>> Hi all,
>> 
>> I would like to propose a change in Qt's Windows maintainership. I think 
>> that everybody knows, that Friedemann has been doing a great job maintaining 
>> the Windows platform specifics in Qt's code base. He wants to focus on Qt 
>> for Python now so we have been looking for an alternative way of maintenance.
>> 
>> I propose a shared maintenance between Andre de la Rocha and me for Windows. 
>> Andre has been involved in Qt's Windows development for almost 4 years now. 
>> He is responsible for our accessibility backend on Windows and rewrote 
>> mouse/touch/pen handling for that platform. He also wrote the "win32" 
>> bluetooth backend and fixed bugs in various areas of Qt.
>> 
>> I have been part of the winrt maintainership and wrote and maintain the 
>> "winrt" backend for Bluetooth (which is also used in Qt6 as the backend also 
>> works for "desktop" applications on Windows 10).
>> 
>> Thanks again to Friedemann for all the work he put into the maintenance of 
>> Qt. You have been doing a great job and I hope that we can ask for some 
>> guidance now and then ;)
> 
> ___
> 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 Multimedia

[Tor Arne Vestbø]

Cheers,
Tor Arne

On 28 May 2021, at 10:54, Samuel Gaist via Development 
mailto:development@qt-project.org>> wrote:


On 28 May 2021, at 10:37, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

How have you implemented those? If you implemented a gstreamer element for 
those cameras, and gst-device-monitor lists them correctly, we’ll simply pick 
them up.

Cheers,
Lars

Not GStreamer as almost all devices required a custom SDK to operate the 
hardware.

These SDKs were available for different platforms. The main targets were macOS 
and Windows with testing on Linux when possible.

They were all QMediaService plugins providing Q_MEDIASERVICE_CAMERA.

Similar to GStreamer, could these HW not be implemented/exposed as camera 
providers at the OS level on macOS and Windows?

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

Re: [Development] Mac Big Sur - Qt Open-Source Support For

[Tor Arne Vestbø]

> On 7 May 2021, at 12:28, coroberti  wrote:
> 
> Dear Tor Arne,
> Thank you for your reply.
> It's less useful since Qt-6 is a phantom, beta, and it will remain so
> for a year or more.

A wise person once said:

> I'd appreciate not to hijack this question for any discussions beyond the
> very narrow scope of this question.

 

Cheers,
Tor Arne

> 
> Kind regards,
> Robert Iakobashvili
> 
> 
> On Fri, May 7, 2021 at 12:47 PM Tor Arne Vestbø  wrote:
>> 
>> Qt 6.0 and above has official support for Big Sur:
>> 
>> https://doc.qt.io/archives/qt-6.0/macos.html
>> 
>> 5.15 is not yet officially supported, but should work fine as well, so 
>> please report any issues in JIRA, thanks!
>> 
>> Cheers,
>> Tor Arne
>> 
>> On 7 May 2021, at 11:00, coroberti  wrote:
>> 
>> Dear Tukka and others,
>> Since September Big Sur is a reality.
>> 
>> Which Qt-version supports correctly QWidgets for this platform for
>> open-source development.
>> 
>> If there's no such version, when the support is planned if ever.
>> 
>> I'd appreciate not to hijack this question for any discussions beyond the
>> very narrow scope of this question.
>> 
>> Thanks,
>> 
>> Kind regards,
>> Robert
>> ___
>> 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] Mac Big Sur - Qt Open-Source Support For

[Tor Arne Vestbø]

Qt 6.0 and above has official support for Big Sur:

https://doc.qt.io/archives/qt-6.0/macos.html

5.15 is not yet officially supported, but should work fine as well, so please 
report any issues in JIRA, thanks!

Cheers,
Tor Arne

On 7 May 2021, at 11:00, coroberti 
mailto:corobe...@gmail.com>> wrote:

Dear Tukka and others,
Since September Big Sur is a reality.

Which Qt-version supports correctly QWidgets for this platform for
open-source development.

If there's no such version, when the support is planned if ever.

I'd appreciate not to hijack this question for any discussions beyond the
very narrow scope of this question.

Thanks,

Kind regards,
Robert
___
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 features in CI

[Tor Arne Vestbø]

On 1 Mar 2021, at 17:22, Edward Welbourne 
mailto:edward.welbou...@qt.io>> wrote:

If a staging branch passes, all the changes contained in that branch
will be merged into the target branch (can be a fast-forward merge).

you mean actual git merges, rather than rebases/cherry-picks? that will
lead to a completely insane history in busy repositories.

I'm a bit curious about that one myself; but it can perfectly well be
implemented as a rebase, after all.

This seems to indeed be the case:

[X]

The merge commits are also wrongly attributed to the author of the last commit 
(HEAD) in the integration branch, and the subject of the merge commit reflects 
only that commit, not the set of (likely unrelated) commits in the integration.

A lot (most) of the merge commits are empty, so I assume they could then just 
be cherry-picks instead.

We we please improve this by:

 1. Attempt to cherry-pick the commits in the tested branch into dev, before 
falling back to a merge commit (if needed)
 2. If we need to merge:
   - Reflecting the CI as the author of the merge commit
   - Reflecting the set of commits in the merge commit message, e.g. based on 
git shortlog
   - Using a commit message subject that explains what’s going on, eg.

---o<---

Merge integration #1615461139

https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1615461141

Eskil Abrahamsen Blomfeldt (3):
  Skip tst_QOpenGL::glxContext test on Wayland
  Fix tst_QDialog::keepPositionOnClose on Wayland
  Make tst_shortcut pass on Wayland

Mårten Nordheim (1):
  QEventDispatcher(Win): Always honor interrupted status to avoid races

Zhang Yong (1):
  The conditional statement is missing parentheses

---o<---

Cheers,
Tor Arne


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

Re: [Development] User-defined literals for QString (and QByteArray)

[Tor Arne Vestbø]

On 3 Mar 2021, at 16:53, Andrei Golubev 
mailto:andrei.golu...@qt.io>> wrote:

QString hello = u"Hello"; // oops, compilation error

This seems like a bug though? From an API point of view, I’d expect this simple 
assignment to JustWorkTM, without requiring syntactic sugar all over the place. 
Shouldn’t we fix this, so we don’t need (or leave optional) an explicit _qs 
suffix?

Tor Arne

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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 17 Feb 2021, at 23:39, Thiago Macieira  wrote:
> 
> On Wednesday, 17 February 2021 00:32:13 PST Joerg Bornemann wrote:
>> Yes, and that's all good, and with
>> https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an
>> offical recommendation.
>> I will also add a documentation page in the vicinity of
>> https://doc.qt.io/qt-6/linux-building.html
> 
> Make that "mac building" too, because it shall apply to Homebrew.

Sorry, no. If Homebrew renames binaries, that’s a Homebrew documentation 
installation documentation issue. How Qt is built from source on macOS has no 
relation to that.

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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 16 Feb 2021, at 14:31, Kai Köhne  wrote:
> 
> Well, let's just realize that, by renaming qmake to qmake6 everywhere 
> (including in the documentation), we actually create some confusion for our 
> existing users, too. Also, I think adding version numbers to the name of 
> tools is just no good user experience, and creates unnecessary friction when 
> switching between Qt versions.
> 
> To be honest, the whole discussion feels to me that we are being held hostage 
> right now for the fraction of Linux users that cannot use update-alternatives 
> (because they are not administrators). If having different names of tools is 
> such a big problem, why wasn't this addressed by now in Linux itself?
> 
> And again, this is not something limited to Qt. Last time I checked, the 
> executable to run Python 3 on Windows is python.exe, not python3.exe. On 
> Debian at least it's python3. This hasn't blocked Python from being perceived 
> as overall beginner friendly ...
> 
> So, I would stick to qmake as canonical name, also in the documentation. We 
> can mention that it's sometimes called qmake6 on Linux. But forcing everyone 
> to change their habit and scripts just for the sake of consistency with a 
> fraction of the users that use a global installation on Linux, and do not use 
> update-alternatives, is IMO not a good move.

I fully agree with everything Kai said above. 

Tor Arne

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

Re: [Development] Qt modules, API changes and Qt 6

[Tor Arne Vestbø]

On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
for example, the information that a build with updated dependencies is required 
can be stored as an annotation in the commit message (that's exactly what zuul 
does, afaik), and the incremental propagation of the dependencies can be done 
in a "shadow" branch of the qt5 repository (technically, that could be a single 
gerrit change that gets progressively updated).

Yeah, I was also thinking of using git notes perhaps for storing the 
information separately. (Doesn't seem to be enabled in our Gerrit? Hopefully 
I'm wrong :).

i don't think using git notes is particularly useful here. the number of 
affected commits would be rather low, so having an additional commit message 
footer would not hurt. extracting that information would also be rather easy 
(git log from the last reference point).

Do I understand your proposals correctly:

Let’s say I make a change in qtdeclarative that depends on a merged change 
‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like

dependencies: qtbase:shaA qtsvg:shaB

(or whatever syntax we want) to my qtdeclarative commit message?

This information does not belong in the commit message.

It belongs in dependencies.yaml, and a git-merge-driver for dependencies.yaml 
should be able to resolve those to a compatible set for each integration, or 
report back if the dependencies can not be satisfied. This would also avoid the 
dance we have have (had) where a submodule update needs to be carefully staged 
with other changes that depend on it or fix something as a result of the update.

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

Re: [Development] Qt6 repo

[Tor Arne Vestbø]

Cheers,
Tor Arne

On 13 Jan 2021, at 14:37, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

On 13 Jan 2021, at 14:17, Dominik Holland 
mailto:dominik.holl...@qt.io>> wrote:

Am 1/13/21 um 1:19 PM schrieb Allan Sandfeld Jensen:

On Mittwoch, 13. Januar 2021 13:07:00 CET NIkolai Marchenko wrote:
that's ... kinda what you're supposed to avoid... at least as far as I
understand the convo earlier. so that two major versions aren't pushed to
the same repo confusing people.

I don't see any problems with that. It is how all the other modules are used.

'Allan

Why not create a qt6 super repo, which host qt6 for now and just create
a alias qt.git which always points to the latest qt release.

Later this could point to a qt7 release. I guess we don't want to go
back to a monorepo, but we never know, so this would atleast help to not
block this road...

Dominik


Let me make a more radical proposal:

+1 on all of the proposed.

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

Re: [Development] Qt6 repo

[Tor Arne Vestbø]

> 
> On 13 Jan 2021, at 12:38, Allan Sandfeld Jensen  wrote:
> 
> On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
>> that's the obvious choice, if it was not already used by qt4.
>> 
> Then rename the qt4 repo, it is not actively maintained anymore and only 
> stored for history. We couldn't do that when creating qt5 as it was still 
> actively maintained and would break a lot of checkouts, but we could do it 
> now.

I agree, that seems like the easiest and most future-proof solution.

Cheers,
Tor Arne


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

Re: [Development] Switch the main "Qt Build System"

[Tor Arne Vestbø]

Awesome work!! 

Cheers,
Tor Arne

On 8 Dec 2020, at 17:51, Alexandru Croitor 
mailto:alexandru.croi...@qt.io>> wrote:

Hi again,

A short update on the build system switch.

Sine my last email (half a year ago) a number of issues were raised that we had 
to tackle in order to consider switching Qt's main build system to CMake.

Some of those issues were tracked in the following JIRA issues
https://bugreports.qt.io/browse/QTBUG-86053
https://bugreports.qt.io/browse/QTBUG-88741
as well as some other ones.

Since then:
- most of the important issues have been fixed
- multiple improvements have been done to the Qt build DeveloperXperience
- qmake CI coverage has been mirrored
- configure's default has been changed to build Qt with CMake
- our CI and packaging pipelines have switched to using CMake for a while now
- the Qt 6.0.0 that shipped today was built using CMake

As such, we intend to remove support for building Qt with qmake in the 6.1 
branch (aka dev)

This means:
- we will remove the qmake CI configurations in dev branch
- we will change configure to refuse configuring Qt with the -qmake option
- pro2cmake will not be used anymore, and the CMakeLists.txt files become the 
source of truth
 which means CMakeLists.txt files will now have to be modified directly
- configurejson2cmake will not be used anymore, and the configure.cmake files 
will become the source of truth (not configure.json)
 which means configure.cmake files will now have to be modified directly
- we will not remove the qmake .pro and configure.json files for now, it will 
be done sometime later in the future https://bugreports.qt.io/browse/QTBUG-88742

We intend to do it by the end of the week, if nothing critical comes up.

Regards,
Alex.


On 1. Jul 2020, at 13:31, Alexandru Croitor  wrote:

Hi everyone,

An update on the build system switch.


On the 8th of June I mentioned that we wanted to make the "CMake build system" 
the main one and remove the .pro files.
The tentative date was 1st of July (today).

As a result of the discussion, we identified some items that had to be tackled 
first.
Not all of those have been addressed yet.

So we are postponing the switch until further notice.

Regards,
Alexandru.

___
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] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 14:21, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Wed, 18 Nov 2020 at 10:16, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:



On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:
[snip]
Let’s clarify this, so we’re talking about the same thing:

1. Application end-users
2. Application developers using Qt
3. Qt developers

Let me expand it:

1. Application end-users
2.1. Application developers using Qt as provided by distro.
2.2. Application developers using more than one Qt major/minor version.
3. Qt developers.

#3 develops Qt for use by #2 to produce applications for #1

When you are talking about end users, which one of these do you refer to?

1 and 2.1.

The application end user (#1) shouldn’t need access to any of Qt’s binaries 
AFAIK. What’s there for us to fix for them?

qdbus can be called by an app ran by an end-user.

That sounds like a deployment issue. If the app needs qdbus, it needs to bundle 
it, or make sure it knows the full path to it (but that sounds like a fragile 
thing to rely on). Besides, shouldn’t an app using dbus use 
https://doc.qt.io/qt-5/qtdbus-index.html and not an external binary?

So (#1) is mostly (fully?) cleared, then we still have (#2.1).

Okey, good to get #1 out of the way first. Thanks!

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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> [snip]
>> Let’s clarify this, so we’re talking about the same thing:
>> 
>> 1. Application end-users
>> 2. Application developers using Qt
>> 3. Qt developers
> 
> Let me expand it:
> 
> 1. Application end-users
> 2.1. Application developers using Qt as provided by distro.
> 2.2. Application developers using more than one Qt major/minor version.
> 3. Qt developers.
> 
>> #3 develops Qt for use by #2 to produce applications for #1
>> 
>> When you are talking about end users, which one of these do you refer to?
> 
> 1 and 2.1.

The application end user (#1) shouldn’t need access to any of Qt’s binaries 
AFAIK. What’s there for us to fix for them? 

Cheers,
Tor Arne 

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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 13:39, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

Right, and this are all developer's tools. End users shouldn't care
nor even know about them. Remember, we are talking about
distribution-provided binaries.

Let’s clarify this, so we’re talking about the same thing:

 1. Application end-users
 2. Application developers using Qt
 3. Qt developers

#3 develops Qt for use by #2 to produce applications for #1

When you are talking about end users, which one of these do you refer to?

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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 12:11, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

What we need is a command line tool for doing the same. That’s how other 
project solve things too (nvm, rvm, pyenv, etc)

For some context:

  *   https://github.com/nvm-sh/nvm
  *   https://rvm.io/
  *   https://github.com/rbenv/rbenv/
  *   https://github.com/pyenv/pyenv
  *   
https://doc.rust-lang.org/edition-guide/rust-2018/rustup-for-managing-rust-versions.html
  *   https://github.com/kylef/swiftenv

Some of these tools modify PATH on behalf of the user, while others add a 
custom directory to the PATH where they then swap symlinks around (which is how 
qtchooser works as far as I know?).

They also allow per project (local) version pinning, which can be useful.

Tor Arne






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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

Morning,

IMHO, suffixing our binaries is a kludge. It “solves” the major version 
transition, but not any of the other use cases such as minor version upgrades, 
different builds of the same Qt version, etc.

Qt Creator already provides a way to manage and switch Qt versions: 
https://doc.qt.io/qtcreator/creator-project-qmake.html

What we need is a command line tool for doing the same. That’s how other 
project solve things too (nvm, rvm, pyenv, etc). And we already have a tool for 
that, qtchooser. If maintenance of that is an issue, then let’s solve that.

Why is that not an acceptable solution for distros?

Tor Arne

On 27 Oct 2020, at 17:34, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

Have we fixed it?

I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
binary with the same name as Qt 5 did.

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel DPG 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 use Markdown for the dist/changes changelog

[Tor Arne Vestbø]

> On 3 Nov 2020, at 10:52, Richard Gustavsen  wrote:
> 
> Would it be better if we required all commits to have a ChangeLog entry, so 
> that no one
> forgets? And if your commit shouldn't be in the log, you need to state that 
> explicitly, e.g: [NoChangeLog]

No, that would just add noice to the git log. The commit message template 
should already have
a reminder to add a changelog entry _if applicable_.

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

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 27 Oct 2020, at 19:34, Marius Kittler 
mailto:mkitt...@suse.de>> wrote:

For the Windows target that counts as well besides the "qtmain" problem. I
used so far the following patch to workaround it:
https://github.com/Martchus/PKGBUILDs/commit/
87c7401193391438554de35f1a8b062dcf59bd20#diff-484f0d9d749b6b5fdde1f91fd329a93c73e409defb4a494c4d90b3f08590d330
It seems like this b5af1408099dedd132f36e04d19cb5771a23ec28 "fixed" the
problem. Actually, it isn't really fixed because when Qt 7 comes out there
will be the same issue again.

The library now has the Qt6 prefix in its name, so it should not be an issue. 
Or are you thinking of something else?

tor arne

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

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

[Tor Arne Vestbø]

> On 2 Sep 2020, at 16:49, Thiago Macieira  wrote:
> 
> Tor Arne wrote:
>> As a user of this API I was also stumped by not being able to just call
>> printf with %z and a qsizetype, under the assumption that qsizetype’s
>> purpose in life was to mask _away_ the differences of what a size was
>> represented as.
> 
> For restricted scenarios (MSVC-only or Unix-only code), you can use those 
> modifiers. And in MSVC-only scenarios, there will be no type mismatch either, 
> in both 32- and 64-bit.
> 
> On 64-bit Unix, the result will be correct too, since the types are the right 
> size. The only thing is you may get a compiler warning that the types 
> mismatched. We could disable -Wformat.

Right, I was talking about the fact that even using %z will give you a warning, 
which seems counter to the assumed promise that qsizetype is a generic size 
type that masks away the platform differences. I’d expect one of the things it 
would do well, from an API/usability pov, is to be printable with the “size” 
format specifier  

Today you need printf(“%z\n”, size_t(foo.size()));

Cheers,
Tor Arne




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

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

[Tor Arne Vestbø]

As a user of this API I was also stumped by not being able to just call printf 
with %z and a qsizetype, under the assumption that qsizetype’s purpose in life 
was to mask _away_ the differences of what a size was represented as. 

Since it all flattens down to e.g. qint64 I don’t suppose there’s anything we 
can do to make the %z case less confusing by adding convenience for size_t? If 
not a doc update would be helpful at least.

Cheers,
Tor Arne 

> On 2 Sep 2020, at 09:15, Mathias Hasselmann  wrote:
> 
> I'd rather say that cast is entirely ugly. Seems like a perfect example or 
> code smell: Something is fundamentally wrong they way qsizetype is defined.
> 
> Am 01.09.2020 um 19:29 schrieb Thiago Macieira:
>> On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> Il 01/09/20 16:23, Thiago Macieira ha scritto:
 So even if you use %td or %zd, GCC will complain in one of three different
 platform configurations (namely, 64-bit Unix).
>>> Pedantically, do we need the PRIxQSS (?) macro and friends to use
>>> qsizetype into qWarning etc.?
>> That's ugly. Just cast the type itself to ptrdiff_t or int.
>> 
>> That is, write:
>> 
>> qWarning("List too big: %zd", ptrdiff_t(list.size());
>> 
>> Qt's internal sprintf-like functions actually use qsizetype, not ptrdiff_t, 
>> so
>> pedantically-strictly speaking the compiler is wrong and your code was right
>> without the cast. In real-life, it just works.
>> 
>> Note: this only applies to the functions that actually use Qt's own sprintf-
>> like functions. You can't use with printf family itself because we still
>> support MinGW and that one uses a C99-incompatible standard library by 
>> default
>> (no "z" and no "t" modifier and no 64-bit support on 32-bit systems).
>> 
> ___
> 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] Qt5.14 Prl files are missing for Mac framework build?

[Tor Arne Vestbø]

> On 27 Jul 2020, at 23:55, Иван Комиссаров  wrote:
> 
> Hello again!
> 
> What about qt6? In the snapshot files are back in framework root… Is that a 
> regression?

Yeah, that’s a regression when transitioning to CMake. Thanks for the heads up!

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

Re: [Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

[Tor Arne Vestbø]

> On 3 Jul 2020, at 02:49, Thiago Macieira  wrote:
> 
> On Thursday, 2 July 2020 15:46:24 PDT Tor Arne Vestbø wrote:
>> I think I prefer permanently, and then clearly documenting that the fallback
>> conversion to a string for non-listed types may be lossy, teaching the user
>> to either encode the data into one of the well defined and non-lossy types
>> (e.g. use a QString if what you're representing is a string, or
>> base64-encode raw binary data), or use CBOR instead.
> 
>> That leaves less amount of surprises when upgrading to Qt 6 while being
>> clear about the possible downsides.
> 
> Thank you.
> 
> For Qt 6, I think we should look at the list of meta types and explicitly 
> list 
> how they are converted to CBOR and JSON, so for QByteArray it would be clear 
> that it's a lossy conversion using fromUtf8. Any type not in the white list 
> gets converted to JSON null or CBOR undefined but subject to change.
> 
> And unit-test them.

That sounds like a great way forward. Thank you Thiago!

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

Re: [Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

[Tor Arne Vestbø]

> On 2 Jul 2020, at 19:07, Thiago Macieira  wrote:
> 
> On Thursday, 2 July 2020 03:57:08 PDT Tor Arne Vestbø wrote:
>> Which does not match the documented behavior, so I think a revert makes
>> sense to avoid the surprising behavior change.
> 
> Thanks for the opinion, Tor Arne. For the record, revert permanently or 
> revert 
> only in 5.15?

I think I prefer permanently, and then clearly documenting that the fallback 
conversion to a string for non-listed types may be lossy, teaching the user to 
either encode the data into one of the well defined and non-lossy types (e.g. 
use a QString if what you're representing is a string, or base64-encode raw 
binary data), or use CBOR instead.

That leaves less amount of surprises when upgrading to Qt 6 while being clear 
about the possible downsides.

Cheers,
Tor Arne

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

Re: [Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

[Tor Arne Vestbø]

On 1 Jul 2020, at 23:21, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:


It wasn't entirely undocumented. QJsonValue::fromVariant said:
   For all other QVariant types a conversion to a QString will be attempted.
   If the returned string
   is empty, a Null QJsonValue will be stored, otherwise a String value using
   the returned QString.
[this text is changed in https://codereview.qt-project.org/305996]

Since it depends on QVariant::toString(), it's implicit that the behaviour can
change from version to version. For Qt 6.0, we're already discussing whether
conversion between types in QVariant makes sense and toString() is one of
those cases.

Looking at this some more, the documented behaviour is:

"For all other QVariant types a 
conversion to a QString will be attempted. 
If the returned string is empty, a Null 
QJsonValue will be stored, otherwise a 
String value using the returned QString."

auto variant = QVariant::fromValue(QByteArray("ASCII text.\n"));
auto stringForJson = variant.toString(); // "a conversion to a QString will be 
attempted"
printf("%s", qPrintable(stringForJson));

Which for me results in printing "ASCII text.”

The new behavior injects an extra step here:

variant = QVariant::fromValue(QByteArray("ASCII text.\n"));
auto base64Encoded = variant.toByteArray().toBase64(); // <-
auto stringForJsonBase64 = QString::fromUtf8(base64Encoded);
printf("%s", qPrintable(stringForJsonBase64));

Which does not match the documented behavior, so I think a revert makes sense 
to avoid the surprising behavior change.

Especially since users who encode true binary data will do their own 
(base64)-encoding anyways.

We can document that this might result in data loss and recommend pre-encoding 
the data. At least the user is in control then.

Tor Arne


As can be seen in the testcase, the old behaviour is silently lossy, which
means it's dangerous. The new behaviour is surprising, but it's not lossy, as
the original byte data is retrievable:

$ base64 -d <
 Software Architect - Intel System Software Products



___
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] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

[Tor Arne Vestbø]

Hi,

I can sympathize with the reporter that this is a quite serious regression from 
the user’s point of view, but I also see your point about the new behavior not 
being lossy.

Would it be an alternative to add an argument to QJsonValue::fromVariant e.g. 
that defaults to the old, unsurprising behavior, but allows opting in to the 
safer approach?

I assume people who put “true” binary data into their QByteArrays and convert 
that to JSON would have pre-base64-encoded it manually already, to avoid the 
data loss, so this is a surprising change for those that just use it as a poor 
man’s string. 

That the documentation says "a conversion to a QString will be attempted.” 
reads to me as being a conversion that is as close to the original as possible, 
and results in a string. So while the new behavior is technically a string, I 
can see how it’s surprising that it’s not exactly close to the original ascii 
data e.g. 

My 2øre

Tor Arne 

> On 1 Jul 2020, at 23:21, Thiago Macieira  wrote:
> 
> Re: https://bugreports.qt.io/browse/QTBUG-84739
> Summary: Qt 5.15 has an unintentional change in behaviour that has broken 
> existing applications. We need to decide whether to:
> a) leave as-is
> b) revert permanently
> c) revert for 5.15.x but keep the new behaviour in 6.x
> 
> (a) implies one change in behaviour (5.14.2 to 5.15.0)
> (b) implies two changes in behaviour (to and from 5.15.0)
> (c) implies three changes in behaviour: 5.14.2→5.15.0, 5.15.0→5.15.1, 
> 5.15.x→6.0
> 
> Testcase:
>const char binarydata[] = "\0\1\2\3\xff";
>QVariantMap vmap = {
>{"ascii", QByteArray("ASCII text.\n")},
>{"latin1", QByteArray("R\xe9sum\xe9")},
>{"utf8", QByteArray("Résumé")},
>{"binary", QByteArray(binarydata, sizeof(binarydata) - 1)}
>};
>QJsonObject jobj = QJsonObject::fromVariantMap(vmap);
>printf("%s", qPrintable(QJsonDocument(jobj).toJson()));
> 
> Because of the switch in QJsonValue/Object/Array to use the CBOR classes as a 
> backend, we had an uninteded change in behaviour in how the JSON 
> fromVariantXxx functions behave for some variant types that are not part of 
> the JSON specification. In the bug report, this happened specifically for 
> QByteArray.
> 
> Qt 5.14 output:
> {
>"ascii": "ASCII text.\n",
>"binary": null,
>"latin1": "R�sum�",
>"utf8": "Résumé"
> }
> 
> Qt 5.15 output:
> {
>"ascii": "QVNDSUkgdGV4dC4K",
>"binary": "AAECA_8",
>"latin1": "UulzdW3p",
>"utf8": "UsOpc3Vtw6k"
> }
> 
> The Qt 5.15 output is the Base64url encoding of the original byte array data, 
> following the CBOR recommendations on how to convert CBOR to JSON (RFC 7049 
> section 4.1[1]). This was unintentional and happened only due to code reuse. 
> The QtJson unit tests did not test this and do not test how converting from 
> any QVariant types except the base ones that apply to JSON, plus QUrl and 
> QUuid. But it has broken user code that relied on this feature.
> 
> It wasn't entirely undocumented. QJsonValue::fromVariant said:
>For all other QVariant types a conversion to a QString will be attempted.
>If the returned string
>is empty, a Null QJsonValue will be stored, otherwise a String value using
>the returned QString.
> [this text is changed in https://codereview.qt-project.org/305996]
> 
> Since it depends on QVariant::toString(), it's implicit that the behaviour 
> can 
> change from version to version. For Qt 6.0, we're already discussing whether 
> conversion between types in QVariant makes sense and toString() is one of 
> those cases.
> 
> As can be seen in the testcase, the old behaviour is silently lossy, which 
> means it's dangerous. The new behaviour is surprising, but it's not lossy, as 
> the original byte data is retrievable:
> 
>   $ base64 -d <<   ASCII text.
>   $ base64 -d <<   000   R 351   s   u   m 351
>   $ base64 -d <<   Résumé  
> 
> 
> (the type change is inevitable and is accepted by the user)
> 
> Request For Opinion: what do we do now? See options at the beginning of the 
> email.
> 
> Note also this behaviour is not completely correct, because fromVariant 
> converts *empty* strings to null, but it should only convert null QStrings to 
> null, leaving empty strings alone (that's the QCborValue::fromVariant 
> behaviour). I also don't think the implementation is self-consistent, because 
> the conversion code appears more than once.
> 
> [1] https://tools.ietf.org/html/rfc7049#section-4.1
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list