Re: [Development] qsizetype

[Thiago Macieira]

On Thursday, 9 March 2023 05:08:48 PST Hasselmann Mathias via Development 
wrote:
> My take on qsizetype: Just revert this failed experiment. It's a huge
> annoyance for little to no benefit. I'll never understand how this very
> broken and incomplete experiment could make it into Qt's main branch at all.

Pretty sure reverting now would be even more disruptive than just fixing the 
remaining issues. It does mean Qt 7 anyway.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[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] qsizetype

[Hasselmann Mathias via Development]

My take on qsizetype: Just revert this failed experiment. It's a huge 
annoyance for little to no benefit. I'll never understand how this very 
broken and incomplete experiment could make it into Qt's main branch at all.


Am 13.09.2022 um 15:12 schrieb Volker Hilsheimer:

On 12 Sep 2022, at 20:04, A. Pönitz  wrote:

On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:

On Mon, Sep 05, 2022 at 05:15:45PM +, Marc Mutz wrote:

[...]
   We have the tools (QT_REMOVED_SINCE + Ivan's work on
   -disable-deprecated-until) to have a user-configurable, rolling BC window
   now We should use these tools to avoid accumulating too much technical
   [...]
   That said, sometimes it's just simpler to do the API change together with
   the rest. I wouldn't worry too much about the effect this has on users of
   Qt APIs: Function argument widening is SC,

I currently fail to understand why all this work needs to have user-visible
consequences *at all* before 7.0 - especially, but not limited, to the now
apparently planned incoming stream of source-incompatible changes including
related deprecations starting to hard-hit users from 6.8 on.

What would have been wrong with starting with

#ifdef I_AM_WORKING_ON_IT
using qsizetyp_ = qsizetype;
#else
using qsizetyp_ = int;
#endif

then have the people working on it (and only those, plus perhaps potential
early adopters) define the macro locally, "port" int to qsizetyp_, and when
everyone is happy with the scope and the implication ofthe change, at 7.0 time,
globally replace qsizetyp_ by qsizetype ?

Why is all this done as operation at an "open heart" instead of having
a "staging" and "production" setup?


Could anyone involved in the decision making that resulted in
the approach taken here please comment?


I can't claim that I was involved in the decision making, but here’s how I see 
it:

We have the tools to change - with some limitations - API signatures without 
breaking either source or binary compatibility. We can deprecate and “weaken” 
old overloads in favour of new overloads; or we can remove the old overload 
completely from the public API and still continue to export the old symbol 
through the module-specific ‘removed_api.cpp’ files.

This is conceptually great news, it gives us a bigger toolbox than what we had 
before. Technically, this is very powerful and useful, allowing us to fix 
mistakes gradually, while giving users control over what kind of deprecation 
warning level they want (from completely silent, up to code no longer 
compiling).

This is IMHO superior to a temporary type alias: A string-based signal/slot 
connection where the signal has been ported ot emit a qsizetyp_ while the slot 
still receives int will fail. So that would break source compatibility. But if 
both slot overloads are still visible for moc when Qt is built, but not to the 
compiler when Qt is used, then those connections will continue to work.

So, I think we have the right tools. The discussion we need to have is when to 
use them. As I have proposed in this thread: this has to be a case by case 
decision.

QTimer should allow timeouts longer than 2^31 msecs, i.e. < 25 days. Great that 
we could fix this before Qt 7.

QDir::count and operator[] now work with qsizetype. I suppose there can be >2^31 files in 
a directory, perhaps more so in 10 years than now. Nevertheless, I do wonder whether this is 
worth the potential source compatibility breakage that is pointed out in the comment 
message. But as long as users need to opt into deprecation warnings explicitly, that is ok 
as well (and would be a “staging" and “production" setup, in practice).


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

[Ahmad Samir]

On 9/3/23 10:14, Marc Mutz via Development wrote:

On 08.03.23 15:30, Ahmad Samir wrote:

So, named casts (static_cast) are better in such cases, as searching for
them in source code is much easier than searching for:
- int(foo)
- (int)foo
- (int)(foo)


In which situation would you want to search for all casts in a piece of source
code? Without the use of a semantic grep tool?



The tool (in this case compiling with -Wshorten-64-to-32, then checking with 
clangd or the build log ...etc) would warn about implicit casts, but not explicit 
ones? now if there is a named cast, then I can search for that much easier than I 
would for the C-style cast (int)foo, or int(foo).


(I haven't checked clang-tidy, but I am guessing it won't be that much different 
than clangd).



I wouldn't like the extra noise of a static_cast when a constructor call
would suffice. Obviously, C-style casts should be avoided (in headers,
IIRC, they're caught by headerscheck).



Good luck with avoiding C-style casts in a huge codebase, e.g. qtbase, there is 
code that's been there since the 90's, and any attempt to "fix" C-style casts in 
the whole codebase would be seen as "churn".



Thanks,
Marc



Thanks,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] [Announce] Qt 5.15.13 LTS Commercial released

[List for announcements regarding Qt releases and development via Announce via Development]

Hi all,

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

The list of fixes and the overview of all important changes in Qt 5.15.13 can 
be found in the release note.
It is available via Qt Account (https://login.qt.io/login): in Downloads, 
select Product: Qt and Version: 5.15.13.


Big thanks to everyone involved!



Best regards

Tarja Sundqvist

Release Manager


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

Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Kai Köhne via Development]

> -Original Message-
> From: Development  On Behalf Of
> Hasselmann Mathias via Development
> Subject: Re: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
> 
> Hi,
> 
> Just to make ensure all options are considered: How about the elephant in the
> room?
> How about "simply" implementing JSONC (JSON with Comments) in Qt's JSON
> parser instead?
> 
> * People wonder regularly when they learnm that there are no comments in
> JSON.
> * JSONC is used by popular software like VSCode and TypeScript.
> * The runtime parsers of PowerShell, .NET, and probably others already
> support
>    it out of the box. For JavaScript and Python there are drop-in libraries.
> * A MIT licensed implementation with examples and tests can be found here:
>    https://github.com/Microsoft/node-jsonc-parser

Supporting this in QJson would be nice, indeed. This could be an additional 
mode, like described in https://bugreports.qt.io/browse/QTBUG-44226 . 

Anyhow, given that this wasn't high priority so far, I wouldn't like to wait 
for it. Even if we get such a JSON mod at one point, there is arguably little 
harm in having the extra Comment field.

So, to wrap up: Let's go for the Comment field, as this fixes the immediate 
need. Extending our JSON support to allow comments, or even switching to an 
alternative file system is something we can still consider mid-term.

Regards

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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Marc Mutz via Development]

On 20.09.22 14:47, Volker Hilsheimer wrote:
[...]
> https://wiki.qt.io/Third_Party_Code_in_Qt
[...]

Sorry for being late to the discussion, but a wiki page will _always_ be 
stale. And it cannot answer the question differently for different branches.

When we started using SPDX, I thought it was so as to automate the 
creation of Qt's SBOM? If we haven't done that, yet, start there.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

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

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

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

Re: [Development] qsizetype

[Marc Mutz via Development]

On 08.03.23 15:30, Ahmad Samir wrote:
> So, named casts (static_cast) are better in such cases, as searching for 
> them in source code is much easier than searching for:
> - int(foo)
> - (int)foo
> - (int)(foo)

In which situation would you want to search for all casts in a piece of source 
code? Without the use of a semantic grep tool?

I wouldn't like the extra noise of a static_cast when a constructor call 
would suffice. Obviously, C-style casts should be avoided (in headers, 
IIRC, they're caught by headerscheck).

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