Re: [Development] Using string literals in autotests

[Edward Welbourne via Development]

Andre' (28 March 2024 15:22) asked:
> What was _qs's life time from invention to deprecation?
> A bit more than a year?

Yes: _qs was added in 6.2 (2021-03-04) and, in 6.4 (2022-03-21, when _s
was added), declared deprecated from 6.8.

Mistakes get made.  We fix them as soon as we reasonably can after
recognising they've been made.  I very much doubt that _s and its peers
will suffer a similar fate.  They've already lasted twice as long as what
they replaced.

Friedemann Kleint (Thu, Mar 28, 2024 at 12:14:35PM +0100) had asked:
>> Surely, the Foundation Team is in the process of creating instructive
>> documentation on string theory?

https://bugreports.qt.io/browse/QTBUG-77020
Hopefully soon.

Andre' answered:
> On a sarcastic day I might be tempted to suggest creating an RSS feed
> for that.  On the other days I'd say that's a two-liner: Recommend
> QT_RESTRICTED_CAST_FROM_ASCII at least for non-library code (this
> includes tests) and be done.

That sounds like a fairly good TL;DR summary of one sane policy.
A QT_RESTRICTED_CAST_FROM_ASCII how-to would improve it.

While I'd generally encourage folk changing code to, as long as they're
confident they know what's better, modernise string usage in the changed
code, it seems unreasonable to require those fixing bugs to the choice
of string representation to make unrelated changes to fix such
preexisting details.  Suggest it as a possibly worth-while drive-by, to
be sure, but it shouldn't block their bug-fixes or feature development.

I'm afraid any energy savings per run of CI, that could be made by
mildly improving string usage, have to be offset against at least the
(energy costs of the) extra CI runs
* that must be made to integrate such modernisation changes, and
* that'll be forced when other folks' subsequent changes follow the
  modern form after a modernisation, are picked back to before it and
  then fail to build until the author fixes them to be compatible with
  the older code-base.

While that won't stop me modernising as part of cleaning up existing
code, when I feel moved to do that, I'd encourage doing any such
clean-up as a single comprehensive revision (of at least one whole test)
rather than piecemeal, so as to reduce the number of extra CI runs due
to at least the first of these.  Of course, changes made as part of
other work avoid those extra CI runs, so provide a path towards
incremental improvement, when they fit naturally for those doing that
other work.

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

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

[Edward Welbourne via Development]

Giuseppe D'Angelo (18 March 2024 12:12)
> Therefore, when one creates a QObject subclass with an event()
> override, then:
>
> * either they didn't know about the fact that it was public in
>   QObject, and thought it was protected/private (because virtual
>   functions should normally be protected), without think about the
>   above C++ """feature""" at all, etc. (mistake in good faith);
>
> * or they were *deliberately* trying to change the access level, i.e.
>   trying to *outsmart* C++, but that goes nowhere; making it more
>   restrictive simply doesn't work (can be bypassed by upcasting,
>   breaks generic code that codes against the interface, breaks
>   subclasses).

Or they could be thinking: "surely that *should* be protected in QObject,
so I'll make it protected in my derived class so that *when* someone
gets round to (at a major version change) making QObject::event()
protected, this overload shall be ready-protected in support of that."
Whether that's a good plan or not is another story, but it's another
possible motive.

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

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

[Edward Welbourne via Development]

Eskil Abrahamsen Blomfeldt (13 March 2024 09:15) wrote:
> I would like to nominate Hatem ElKharashy for maintainership of the Qt
> Svg module. This module currently does not have any active maintainer,
> but it has been part of my team's responsibility and backlog within
> The Qt Company.

+1 - it's wonderful to see some features finally getting implemented,
that I've been using in my own SVGs for more than a decade.
QtSvg needs some love - thanks, Hatem, for giving it some,

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

Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

[Edward Welbourne via Development]

Andre' Poenitz  (21 February 2024 19:21) wrote:
> 1. 'static' is attached to individual functions, not a scope of
> uncertain extend. When working on unfamiliar code it helps to
> understand the context. With 'static' the locality is obvious in the
> immediate context of the function and not set by some 'namespace {'
> potentiall a dozen functions and hundreds of lines of code away.

In particular this means that if someone picks up the function and moves
it elsewhere in the file, cut and paste, it's very easy to fail to
notice that they've moved it out of a nameless namespace and thereby
suddenly made it visible to the linker.  They'd have taken that little
word "static" on the front of the declaration with it, if it'd been
there, because it's not so easy to miss.

(Incidentally, the ways I can think of to say "has no name" tend to
suffer from some degree of precedent as "has a name but it has not been
disclosed" - the anonymous author of a pamphlet, the unnamed person who
reported a problem.  I'm currently unable to think of such a precedent
for "nameless", but I suspect that's only that I can't currently think
of it.  Then again, if a namespace with no name actually does have a
secret name, I guess that just matches the linguistic baggage.)

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

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

[Edward Welbourne via Development]

Volker Hilsheimer (23 January 2024 10:00) wrote:
> I also like the general idea of supporting the header review process
> with more information, such as links to the relevant documentation, or
> even a documentation diff, or even change on gerrit that introduced
> the change; but that’s probably orders of magnitude harder and complex
> to implement, so let’s not wait for that.

Doing this as part of the api-review-gen process would complicate an
already brittle process, but it might be possible to write a gerrit
script that would, in similar manner to the inanity 'bot, scan these
reviews and post links to docs.qt.io for the new API or, perhaps more
valuably, determine whether there *are* docs there and post comments on
the review if not.  That would decouple the doc-posting from the scripts
that generate the reviews.

We should also consider coaxing the inanity 'bot and API-change 'bot
into recognising the API change reviews (they have a recognisable first
line of commit message pattern) and not spamming them with
irrelevancies.

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

Re: [Development] script languages (was: Buddy group to help new contributors)

[Edward Welbourne via Development]

Thiago Macieira (5 January 2024 17:41) wrote:
> Eddy's argument is that he doesn't want to maintain Perl, but if others are,
> he doesn't have to.

and yet I end up maintaining perl scripts; others willing to do so (and with the
time to spare for it) are thin on the ground.

> The question in this thread is that of barrier of entry to developers with
> bare-bones environments.

Yes, this side-thread about rewriting away from perl is a digression (and not 
crucial).

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

Re: [Development] Buddy group to help new contributors

[Edward Welbourne via Development]

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):
>>>> Would it make a huge difference if we didn’t require perl (and IIRC
>>>> we only need it for the init-repository script)?

On Thu, Jan 04, 2024 at 11:35:45AM +0000, Edward Welbourne via Development 
wrote:
>> Our post-commit hook also invokes sanitize-commit, which is a perl
>> script.
>>
>> Of course, it would not be beyond the wit of developers to rewrite
>> both into python; [...]

Oswald Buddenhagen (4 January 2024 15:15) wrote:
> this whole "get rid of perl for the sake of windows users" is a
> monumental red herring. because ...

Just to be clear here, while maybe Volker's reason for suggesting we
ditch perl might have been about windows users, *my* reason for wanting
to ditch perl is that I do not enjoy maintaining perl scripts.

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

Re: [Development] Buddy group to help new contributors

[Edward Welbourne via Development]

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):
>>> Would it make a huge difference if we didn’t require perl (and IIRC
>>> we only need it for the init-repository script)?

Our post-commit hook also invokes sanitize-commit, which is a perl
script.

Of course, it would not be beyond the wit of developers to rewrite both
into python; and doing so might well be an opportunity to study each
closely and think about what we really want from these scripts and how
to do it better.  But we'd have to set aside some suitable developer's
time to do all of that.

Elias Steurer (9 December 2023 15:21) wrote (among diverse good points):
>> In the current state the wiki is a mix of outdated and redundant
>> information.

This is a common problem with wikis.
(See also Mike's comment, below, about "written by software engineers".)

It is easy to write a page that says things that are true at the time of
writing.  It takes some extra effort to actually make that page
discoverable - link it from the right other places, add it to the right
categories, make sure it'll match search terms those who need the
information are going to actually ask about.  As ever with writing, it's
important also to think about what you're so used to taking for granted
that you might not realise the reader needs help with; and to link
relevant parts of the page to where the reader can find more material.

And that's just creating a good page.  Then there's the era of bit-rot:
eventually the page shall be out of date, but how can the reader whose
search has taken them to it discover that ?  I fear the Qt wiki has more
dead pages (that don't know they're dead) than usable live ones.

A wiki lives or dies like a garden, by having enough gardeners giving it
enough of their time to keep it vibrant.

Mike Trahearn (10 December 2023 00:11) wrote (inter alia):
> The entry learning curve is definitely very hard and tricky to set up
> and the wiki looks like it was written by software engineers (that's
> not a good thing). That would be my first point of change.

I distinctly remember, eight and a bit years back, that there was a lot
to sort out and it wasn't easy to find all the details I needed in the
jumble of out-dated pages - and that was with an office-mate who already
knew the ropes to help me out when I hit problems.

> It took me an entire week to get one commit over the line which in
> comparison to what I'm used to is unacceptably slow.

I managed to fix my first bug within my first week - and my boss was
astonished; so yes, I think everyone in the project knows the overhead
is a significant issue.  The problem is devising a process that deals
with all the complexities of this huge [*] project in good ways that we
can make work efficiently for regular high-throughput contributors while
also being learnable for beginners.  That's a tricky problem, so don't
expect an easy answer any time soon; but, yes, we do need to listen to
feedback, particularly from newcomers.

[*] Qt is huge in several ways: the amount built on it, the number of
folk involved in it, the diversity of ways it's used, the range of
platforms on which it works and, of course, the vast amount of code.

One thing I do with new recruits is encourage them to make a note of any
problems they hit, so that we can come back later to sort them out.
There are surely other ways to get feedback from newcomers.
If we don't know about a problem, it's hard to fix,

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

[Edward Welbourne via Development]

On Monday, 4 December 2023 02:10:43 PST Dominik Holland via Development wrote:
>>> the qtinterfaceframework module currently also hosts two reference
>>> APIs (qtifmedia and qtifvehiclefunctions). Both are very much
>>> automotive specific. In order to make the module also available for
>>> other industries we would like to move those two modules to a new
>>> qt-labs repository.
>>>
>>> Name of the repository: qt-labs/qtif-reference-apis.git Description:
>>> Reference modules based on the Qt Interface Framework

Am 12/4/23 um 20:34 schrieb Thiago Macieira:
>> Can we have a more descriptive name than "interface"?
>>
>> Neither QNetworkInterface nor QDBusInterface belong there, therefore
>> there must be a constraint of some sort.

Dominik Holland (5 December 2023 10:03) replied:
> The Qt Interface Framework is a module which already exists
> (https://doc.qt.io/QtInterfaceFramework) that's what the Reference
> APIs are based on.

That doesn't change the fact that the name is rather generic (and leads
to the prefix qtif, which might be mistaken for a reference to an image
format, tiff); and the module seems to be about middleware, so perhaps
Qt Middleware Interface Framework would be a more apt name, or maybe
even just Qt Middleware Framework.  I don't know what this module's
history is, or whether it's previously had its name scrutinised for
compatibility with the rest of the Qt framework, but the fact that
you're asking to add it to qt-labs makes this a moment when such
scrutiny naturally arises.

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

[Edward Welbourne via Development]

Volker Hilsheimer (14 November 2023 10:00) wrote:
> Adding Qt::snake_case interims that are BC with std, with conversion
> from/to QPartialOrdering, is the right thing to do.

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

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

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

Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers

[Edward Welbourne via Development]

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

+1 - makes sense to me.

Full disclosure: one's in the same team as me, the other sporadically
rescues me from CMake woes.  I've also been reviewing large swathes of
these modules.  But that just means I've seen their work enough to form
an opinion ;^>

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

Re: [Development] Memory leak in libQt5Core.so.5.15.7

[Edward Welbourne via Development]

Khande, Chandrakant Gulab (31 October 2023 09:48) wrote:
> Found the memory leak in libQt5Core.so.5.15.7
> Following is the valgrind stack, can Qt help to resolve this, any fix version 
> available for Rocky 8

Please file a ticket in the bug tracker [0] - you may need to create an
account to do so.  Attach the valgrind log and provide a test program
that reproduces the issue, or at least give some clue to how to
reproduce it.  (I see Rocky is yet another Linux [1].)

[0] https://bugreports.qt.io/
[1] https://rockylinux.org/

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

[Edward Welbourne via Development]

Thiago wrote:
>> See my other email: the (1) is not discoverable, teachable, or
>> particularly understandable by average C++ developers. It is not a
>> good corner of C++.

Ivan Solovev (21 September 2023 11:10) replied:
> As you correctly pointed out, most of the developers will just use
> public operator==(), and, come C++20, operator<=>().
>
> But I'd say that if someone wants to implement three-way comparison
> for their classes in C++17, then a bit better understanding of the
> language features is a reasonable expectation.

You're not thinking of all the different users of code.  The author of a
class using Qt, that opts to use our mechanism for comparisons, can
indeed be expected to understand the fancy new language features, around
which that mechanism is built.

However, the client of that code, who just wants to compare two things,
is a separate player in the game; you're also expecting them to have
that level of sophistication.  That's more of a stretch: they're just
trying to coax their template into coping with one of its parameters
being this class that someone using Qt has exposed to them in a library
they're using.  They may not even be using Qt themselves, merely
publishing a helper template that someone else is trying to use in
conjunction with some classes written using Qt.  We don't want them to
throw up their hands and tell the users of their template they don't
support use of Qt classes with their templates because "Qt does things
weirdly" (as far as they're concerned).

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

Re: [Development] How to document API only deprecated in future Qt versions

[Edward Welbourne via Development]

On 9/15/23 09:36, Kai Köhne via Development wrote:
>> The methods are formally marked as deprecated for Qt 6.10. But the
>> methods are already in the '-obsolete' page for Qt 6.6, which leaves
>> the API in a weird in-between state.

Christian Kandeler (15 September 2023 10:31) wrote:
> Radical idea: Treat all deprecated functions as if they didn't exist,
> i.e. remove the documentation entirely. It seems counter-intuitive
> that legacy interfaces should take more documentation effort than
> current ones. Also, this way, fewer people will even be tempted to
> short-sightedly use them.

Tempting as that radical approach is, the temptation you're trying to
prevent is mostly avoided by hiding the docs of deprecated functions on
the -obsolete page; and we do have to think of folk who are trying to
work out what their existing code does.  It's hard to port away from an
old API if you don't have a clear description of what your old code was
achieving by using it, so as to be sure you've achieved the same result
with your use of the new API.  The documentation of a deprecated
function should, also, tell the reader what to use instead, to help them
work that out; they can't read that advice if it's not there.

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

Re: [Development] How to document API only deprecated in future Qt versions

[Edward Welbourne via Development]

Kai Köhne (15 September 2023 09:36) wrote:
> I see why this 'conservative' approach is beneficial. Projects like Qt
> Creator tend to support multiple Qt versions, and immediately
> deprecating an old API in the same version the replacement API got
> added makes this hard to handle.

Note that QT_WARN_DEPRECATED_UP_TO provides the means to ignore warnings
for things deprecated from even the current version, if you want.  So a
project can perfectly well set that to QT_VERSION_CHECK(6, 0, 0) and be
saved deprecation warnings added since 6.0 - although, obviously, it
would be prudent to build without that override at least sometimes, so
they know what technical debt they're accumulating.

> Anyhow, it creates a challenge for documentation. Take e.g.
>
> https://doc-snapshots.qt.io/qt6-6.6/qtfuture-obsolete.html
>
> The methods are formally marked as deprecated for Qt 6.10. But the
> methods are already in the '-obsolete' page for Qt 6.6, which leaves
> the API in a weird in-between state.
>
> I see two fixes for this;
>
> - Keep the documentation API fix separate from the header file fix,
>   and only merge it when Qt 6.9 got branched. This requires 'someone'
>   to follow up on these things, though, more than a year after the
>   deprecation decision has been made.

As you observe, this has problems of coordination.

> - Deprecate the API already _in the documentation_ for 6.6, but only
>   follow up with the compiler warning in Qt 6.10.
>
> I'm actually in favor of the second approach; documentation is mostly
> read when writing _new_ code, and that should already be written with
> the new API. But it's not something we've done so far, IMO.
>
> Do you agree?

I suggest a third alternative: QDoc, when generating documention for a
future deprecation, can treat it as current but, instead of phrasing
that as "deprecated since x.y", express it as "deprecated and will start
producing warnings about that from x.y" -  or something similar.

When it comes down to it, because the replacement should already be
available by the time the old API is future-deprecated, omitting the old
from the main API docs makes perfect sense: we don't want folk to add
new uses of it, we'd much sooner they use the replacement already, and
that should be present in the API docs.  If they're looking up what the
old API does in order to make sense of code using it, they'll still find
it, but if they're looking at the class to find out how to do the thing
the old API does, they'll find the new API instead and use that.

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

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

[Edward Welbourne via Development]

Marc Mutz (12 September 2023 19:29) wrote:
> TL;DR:
> - remove _clang-format in qt5.git
> - add it instead to submodules which conform to it
[snip]
> WDYT?

Well - given that (after init-repository has set up the symlinks "for"
me), my first reaction to any message from clang-format is usually to
rename the symlink to .git/hooks/clang-uglify-pre-commit (because its
suggestions are usually bad and it's very stubborn) - I'm all for it.
I'd love to see a working autoformat as part of the tool-chain, but a
broken one is worse than none.

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

Re: [Development] Nominating Ahmad Samir for approver

[Edward Welbourne via Development]

Volker Hilsheimer (11 September 2023 11:16) wrote:
> I would like to nominate Ahmad Samir for approver rights in the Qt project.
>
> For many months, Ahmad has produced a consistent flow of good contributions 
> and reviews to Qt:

Indeed, very much appreciated,

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

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

[Edward Welbourne via Development]

Lars Knoll (23 August 2023 13:32) wrote
> We have been adding new enum values in certain cases. The operating
> system versions needing to be amended to support a new version of
> macOS is one example. That has happened a couple of times within LTS
> releases as far as I remember.
>
> We’ve also once or twice upgraded CLDR or Unicode versions within
> patch level releases to fix serious bugs, and I believe have in that
> process also added new enum values.

On 23 Aug 2023, at 11:48, Edward Welbourne wrote:
>> I agree with Marc that we should, at the very least, be clearer about
>> what exactly our policy is - and stick to it,

> I agree with that, but would propose to amend our policy and
> explicitly allow adding enum values in those limited cases. Updates to
> Unicode data, supporting new OS versions and maybe a few other limited
> cases come to my mind here.

Sounds like an update to QUIP 6, or possibly a new QUIP superseding it.
https://contribute.qt-project.org/quips/6

So we have

* QOperatingSystemVersion
  Not an enum; { OSType, int, int, int } tuple, with a mass of constants
  of this type to behave a bit like an enum. Adds one such constant for
  each newly supported OS version.

* QChar (UCD) enums:
  - UnicodeVersion -- updates whenever we upgrade
  - Script -- also tangles with HarfBuzz's enum hb_script_t

  Those both routinely update.  In principle, any of CombiningClass,
  JoiningType, Decomposition, Direction, Category may get new members in
  a new Unicode release, too.

* QLocale (CLDR) enums:
  - Language, Script, Territory

(Peculiarly, QLocale::Script and QChar::Script never seem to cross paths.)

In searching for the HarfBuzz tie-in to QChar (which I remember from
doing some UCD updates) I didn't find anything in QFont's public API
that was obviously affected, but that may just reveal the depth of my
ignorance of fonts.

I inevitably wonder whether anyone else involved in 3rdparty updates has
other examples where an external update extends enums (or other families
of names) in our public APIs.  Please speak up if you know of any.

The other question that arises is: do we try to formulate some
generalised characterisation of the circumstances under which this
policy applies - public API exposing details of third-party reality - or
do we simply document a list of cases where exceptions are permitted ?
In the latter case, each extension would require a QUIP update; which
conservatively may be considered good, but may be found tiresome in
practice.  A general rule would allow Maintainers to exercise judgement,
possibly in conference with their peers.

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

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

[Edward Welbourne via Development]

On Tuesday, 22 August 2023 14:27:09 PDT Marc Mutz via Development wrote:
>>> I think we should decide what we mean by forward BC and SC and
>>> describe it in https://wiki.qt.io/Qt-Version-Compatibility more
>>> precisely.

On 23.08.23 04:48, Thiago Macieira wrote:
>> I thought the rule was "no new symbols, period" with the exception
>> for QOperatingSystemVersion for operating systems that have been
>> released since that Qt release was made.

Marc Mutz  (23 August 2023 07:52) replied:
> Indeed. This is how I remember it, too (though the exception is new to
> me), but that is clearly not what the project is producing atm,
> therefore I decided to raise this here.

All of which makes perfectly good sense, but we do have history of
adding new members to other enums.  The example I'm familiar with - that
I dimly remember, although one should be wary of trusting my memory and
I can't find where it happened, asking Lars about when he was Chief
Maintainer, and continuing at his bidding - is adding members to
QLocale's Language, Script and (formerly and still technically Country,
now to be thought of as) Territory enums.

The documentation of these does get "since" annotations (and these will
reference future versions, if we don't amend them during or after
picking) that could be the basis for "don't use these overtly in code if
you care about backwards-and-forwards compatibility" docs (that should
be added, if we continue doing this).  They only present a problem if
the client code overtly exercises the new enum members.

To quote (with [minor changes]) the commit message of (trial baloon)
https://codereview.qt-project.org/c/qt/qtbase/+/498607

  The counter-case is that client code generally only queries the
  available locales to ask the user to pick one, then uses it; or reads
  a locale ID from some source (e.g. HTTP headers) and passes it to
  QLocale to make sense of it. That [may] exercise newly-added enum
  members, in which case it will be a behavior change between patch
  releases (we now support locales we did not before), but the same can
  arise simply from CLDR adding data for locales we already do have the
  codes for in our enums. In any case, code doing this will run when
  compiled and run-time linked against different patch releases, in
  either direction; and users gain the benefit of the new enum members
  [and locales] if they update their Qt libraries.

which I suppose to be the rationale for past post-x.y.0 additions to
these enums.  This benefit may well be significant for some users and
authors of client code do have to go out of their way to break it.

I agree with Marc that we should, at the very least, be clearer about
what exactly our policy is - and stick to it,

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

[Edward Welbourne via Development]

Haowei Hsu (14 August 2023 13:27) wrote:
> The reason why I run vcvarsall.bat is to let CMake find MSVC compilers.

Understandable, just not given by README.md

> As for init-repository, I didn't see its instructions in README.md [...] 
> Where is it?

https://github.com/qt/qt5/blob/dev/README.git
Lines 17 to 21.

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

[Edward Welbourne via Development]

Haowei Hsu (13 August 2023 14:08) wrote:
> Recently, I tried to configure the qt/qt5
> repository. The following commands are what I use to configure the
> project according to its README.md:
>
>   1.  git clone --recursive https://github.com/qt/qt5.git
>   2.  chdir qt5
>   3.  git status
>   4.  git checkout v6.5.2
>   5.  git submodule update --recursive
>   6.  vcvarsall.bat x64
>   7.  configure.bat

These instructions do not appear in README.md; it contains, for example,
no mention of vcvarsall.bat and its instructions for updating quite
explicitly mention running init-repository.  See README.git for the
details of how to clone and set up an initial checkout of Qt.  Note that
it does not use --recursive to git clone; init-repository takes care of
the recursing into submodules.

> However, it turns out that there are some errors occurred.
> What do I miss? How to fix these errors?

Follow the actual instructions in README.git and README.md5 - and please
report any problems you have then, as those would imply we need to
update these files.

> NOTE: Currently, I just want to build Qt's Documentation instead of the
> whole Qt's artifacts.

That will involve building at least QDoc, hence at least QtCore, so
you'll get some artifacts, but indeed you won't need all.  After you run
configure, ninja -t targets will list all possible targets; search that
for ones containig "doc" and you should find one suitable.

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

Re: [Development] What are differences/relations among CMake targets with "docs" word?

[Edward Welbourne via Development]

Haowei Hsu (4 August 2023 20:33) wrote:
> There is another question confusing me:
> What are the qattributionsscanner_XXX targets doing?

The attribution scanner reads the qt_attribution.json files that we use
to describe third-party dependencies, so that we can generate
documentation giving credit to the other folk whose work is incorporated
into Qt.  See [QUIP 4] for the details.

[QUIP 4] https://contribute.qt-project.org/quips/4

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

[Edward Welbourne via Development]

On Monday, 31 July 2023 02:36:41 PDT Ivan Solovev via Development wrote:
>> Basically, what you suggest is that for every pair of comparable Qt
>> types we would need to double the amount of work that we do - provide
>> not only the helper functions for the macros, but also the overload
>> for some public functions for the end-users.

Thiago Macieira (31 July 2023 17:23) replied:
> Every pair? Under what conditions do we need to implement
> heterogeneous comparisons, outside of the primitives? Even with the
> primitives, I don't see more than a handful of heterogeneous, between
> integers and floating point, plus a few other dispatchers to avoid
> ambiguous lookups for integer to integer.

There'd also be our plethora of string types - but still, indeed, only a
fairly limited set of cross-type comparisons.

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

[Development] Relocated QUIPs (was Re: Behavior-changing bugfixes in patch-level releases)

[Edward Welbourne via Development]

Volker Hilsheimer (12 July 2023 12:21) wrote (inter alia):
> The branch policy lives on 
> http://quips-qt-io.herokuapp.com/quip-0016-branch-policy.html

which reminds me: that server is no longer maintained and shall sooner
or later be killed.  The current preferred URLs for QUIPs are on
qt-project.org; the one above becomes

https://contribute.qt-project.org/quips/16

and, if you're linking to one from our Wiki, the preferred form is to
use the QUIP template, in any of the following forms:

{{QUIP|16}} -- plain and simple "QUIP 16"
{{QUIP|16|Workflow}} -- link to section (2nd arg is fragment identifier) 
"Workflow"
{{QUIP|16||Branch Policy}} -- 3rd arg is link text "Branch Policy"
{{QUIP|16|Workflow|QUIP 16, Branch Policy: Workflow}} -- link to section, give 
full title.
Note: don't try to use a | in the link text, as Wiki-syntax will
interpret that as the separator starting yet another parameter to the
template.

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

[Edward Welbourne via Development]

Marc Mutz (14 June 2023 10:52) wrote:
> == Naming E ==
>
> So far, we've been using equal(). equals() doesn't work for technical
> reasons, but while it'd work as a member function lhs.equals(rhs),
> it's also kinda wrong if the function is taking two arguments
> (equals(lhs, rhs), but there are _two_ objects). So equal() as the
> plural form or equals() makes sense.

No, it really doesn't (but it's illuminating to finally see why you
thought it did).

Sure, if we have two objects whose masses together equal that of a
third, you get "equal" as the plural of "equals" but it's *still
transitive* and its "those two equal this one".  You can stretch to
"these two equal one another" but it's severely contrived to do so; you
would say "these two are equal".  Besides, if you don't like areEqual(),
you're really not going to welcome equalOneAnother().

I've no objection to eq() and cmp(), though,

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

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

[Edward Welbourne via Development]

On 4 May 2023, at 12:10, Marc Mutz via Development  
wrote:
>> 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...)

Volker Hilsheimer (24 May 2023 09:53) wrote:
> Eddy is now listed as the maintainer for Locale,Date, and Time on
>
> https://wiki.qt.io/Maintainers#Qt_Maintainers
>
> Congratulations Eddy!

Thank you all.  I guess that's as close as an old Dr. Who fan can hope
to get to having "Time Lord" as my job title.  I shall continue
diligently taking good care of the code involved,

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

Re: [Development] Nominating Tatiana Borisova as approver

[Edward Welbourne via Development]

Alexey Edelev (23 May 2023 15:39) wrote:
> I would like to nominate Tatiana Borisova for approver rights in the Qt 
> project.

+1

I'm also in the same team but, before I was, Tatiana was a whole lot of
help in sorting out issues with INTEGRITY, and has been diligently
making protobuf work, among other things, more recently.

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

Re: [Development] is property compliance of vah264dec an int or a string?

[Edward Welbourne via Development]

Joe (cfd new, 9 May 2023 17:59) wrote:
> I made a pipeline to receive rtsp streaming with vah264dec 
> compliance=flexible.

Given that the token "vah264dec" does not appear in any Qt source code I
have checked out, I suspect you need to give more context to what you're
asking about and at least some hint to how it relates to Qt.  Did you,
in fact, mean to send this to a mailing-list related to gstreamer ?

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

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

[Edward Welbourne via Development]

Volker Hilsheimer (9 May 2023 17:01) wrote:
> The primary purpose of the header review is to catch *technical*
> mistakes - BC or SC breakages - rather than to discuss API design,
> naming, or style.

Some technical errors are future-readiness: as long as we have BC and SC
commitments, we have to think about whether what we design today will
leave us with a BC or SC constraint preventing us from improving on
today's design later, when new requirements surface or we discover any
limitations of the initial design.  Consequently, discussions of API
design, naming and even style can be relevant to determining whether we
have made a technical error in the present design.

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

We certainly can't close a review until after FF, even if we do start
one before.  The advantage of starting early is to give more time for
the conversations to happen and the consequent fixes to be sorted out.

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

Obviously the best time to review a new API or a change to API is when
it is first introduced, long before FF or the API change review.  All
the same, the latter can bring more eyes to the change and more insights
into potential problems with the change.  The initial change was
typically reviewed by folk working closely with the particular part of
the code-base; the API change review is apt to bring the change to the
attention of potential clients of the new API, or to folk who've
previously designed similar-shaped APIs for other purposes, who may have
valuable insights into the new design.

OTOH, when we're all rushing headlong towards the deadline of FF, an
early start to the API change review might be of limited value, simply
because relevant folk are too busy to have those conversations.  And the
part of the process which has been slow at recent releases has been
getting all the modules signed off by their respective Maintainers; it's
not really clear to me that an earlier start would help with that.

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

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

[Edward Welbourne via Development]

Thiago Macieira (3 May 2023 19:20) wrote:
> I don't see us adopting Modules any time soon, not even for the 6.9
> release. It's not well supported *today*.

Also, they're a radical change to how source is organised and it "might
not be a bad idea" to wait until the C++ world has developed some common
practices in how to use them, and maybe even some best practices, so
that however we go about using them can conform to the latter as far as
is compatible with the former.  That won't happen until support has been
commonplace for long enough for (preferably other) people to make the
mistakes that will establish the antipatterns that will inform the
development of both common and best practices.

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

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

[Edward Welbourne via Development]

Volker Hilsheimer (2 May 2023 10:57) wrote:
> With Qt 6.5 out for a while already, and roughly a month to go until
> Qt 6.6 feature freeze and the start of the various activities that
> lead up to the release, it’s perhaps not too early to review some of
> the pain points we experienced with 6.5, and discuss how we can
> improve.

One pain point that came up at the time was that the reviews don't get
enough attention; another that we maybe need more time.  I think the
first of those is somewhat covered by one of your other sub-threads.

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

I like that plan.

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

OK, then (see Subject):

We could simply start the review earlier.  The only real significance of
the feature-freeze is that it's the cut-off for changes to API, aside
from the changes to changed API that get prompted by the review.  So we
could perfectly well start that earlier, and maybe get some of the fixed
changes in before feature-freeze.  OTOH, that would be more work for the
release team, having to update the reviews more times.

Another approach would be for Maintainers to run the scripts [0] on
their modules locally and have a look for anything in the result that
looks like it needs more eye-balls on it.  They can either dig up the
original gerrit reviews of the changes and drag relevant eye-balls to
take a look at that, or fake up a commit based on the one the
api-review-gen script produced, that captures the particular piece(s)
they want reviewed and push that to gerrit.

[0] they're in qtqa/scripts/api-review/, stick that in your PATH and run
api-review-gen --help
for details.  You'll need the dulwich python package installed.

Incidentally, if anyone does run these scripts for themselves and finds
difficulties with that, I'd love to hear from you, via Jira if you think
it's worth it.  The "break up git modules by Qt module" feature request
already exists, QTQAINFRA-4763.

What (else) could we do to make the review run more smoothly and quickly ?

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

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

[Edward Welbourne via Development]

Lars Knoll (18 April 2023 09:46) replied
>> I think this should be the goal, but I’d vote for a slightly faster
>> schedule.
>>
>> (a) and (b) are things we should be able to do right now.

I (18 April 2023 14:05) commented:
> Sounds sensible to me.

... so have opened QTBUG-112954 and QTBUG-112955 for the
opening move of making it possible for the user to opt in,

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

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

[Edward Welbourne via Development]

On 17 Apr 2023, at 18:16, Thiago Macieira  wrote:
>> But anything that goes through QIODeivce::read or write (QProcess,
>> QFile, Q{Udp,Tcp,Local}Socket) will suffer if there's no agreement on
>> what that encoding is.

And that's a cross-platform problem for anyone who has to consume data
produced by a (presumably non-Qt) source that's using legacy codecs.
At present our answer is to use Qt-with-ICU or some separate codec-converter.

>> [snip] What has changed is that the Windows API has matured to the
>> point that this is now a viable choice (previously, it was
>> experimental and known to cause issues). But it's still an
>> application choice; we can't enforce it.

But we *can* document how to do it as part of our "how to package your
application" instructions, thereby encouraging users of Qt to do so.

>> But I think we should:
>> a) do it for our own applications, since we do know our own code
>> b) advise users somehow that they should opt-in to this
>> c) decide if we want to change from opt-in to opt-out in the medium
>>term (7.0 for example)
>> d) decide if we want to enforce it in the long-term
>>
>> Option (d) depends on (c). Option (c) informs whether we need a Qt
>> CMake API or whether we can simply say upstream CMake should handle
>> it.

Lars Knoll (18 April 2023 09:46) replied
> I think this should be the goal, but I’d vote for a slightly faster
> schedule.
>
> (a) and (b) are things we should be able to do right now.

Sounds sensible to me.

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

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

[Edward Welbourne via Development]

Thiago Macieira (31 October 2019 22:11) wrote [0]:
> This RFC (...) is meant to discuss how we'll deal with locales on Unix
> systems on Qt 6. This does not apply to Windows because on Windows we
> cannot reasonably be expected to use UTF-8 for the 8-bit encoding.

[0] https://lists.qt-project.org/pipermail/development/2019-October/037791.html

The GNU make mailing list currently has a thread (starts at [1]) about
handling of encodings on Windows.

[1] https://lists.gnu.org/archive/html/bug-make/2023-03/msg00066.html

The discussion there seems to indicate that setting the system code-page
to UTF-8 can be done in a way that interoperates gracefully with other
processes and the file system, presumably thanks to the system being
substantially UTF-16-based, so all 8-bit encodings go via that anyway.

The means to achieve this appear [2] to hinge on setting the active
codepage for the application in a manifest file, that it gets combined
with after it is linked.

[2] 
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

There do appear to be some vagaries still, it may depend on UCRT and I'm
not sure I've really understood it all, but it looks like we may, in
time, be able to consistently use UTF-8 as 8-bit encoding on Windows.

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

Re: [Development] QUIP 14: The module life-cycle and criteria for transitions

[Edward Welbourne via Development]

Back on 23 November 2018 around 10:53 I wrote:
> Back in 12 January 2017, when we were discussing Qt Remotes Object as
> a Tech Preview for Qt 5.9, Lars set out [0] some criteria for modules
> to enter tech preview.  It occurred to me that this was worth turning
> into a QUIP, along with criteria for the other transitions of a
> module's life-cycle.  I've now pushed a first draft of that for review
> [1].
>
> * [0] 
> https://lists.qt-project.org/pipermail/development/2017-January/028313.html
> * [1] https://codereview.qt-project.org/246320
>
> There are some big TODOs that require discussion on this mailing list.
> I'll endeavour to formulate whatever consensus I hear in that QUIP.
> What are (or should be) the criteria for transitions to the
> maintained, obsolete and deprecated states ?

Kai has helpfully answered some of those questions and, once I'd found
my way back to this post (roughly contemporary with a server upgrade
that broke the link) I thought of some more TODO questions that need
answers before this can move forward.

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

[Edward Welbourne via Development]

Kai Köhne (15 February 2023 08:50) replied:
>>> Well, you can also achieve this by duplicating comment fields:
>>>
>>> {
>>>   "Comment": "Upstream files are src/x.cpp, include/y.h",
>>>   "Files": [ "x.cpp", "y_p.h"]
>>>   "Comment": "Copyright info is from dist/COPYING",
>>>   "Copyright": "Copyright (C) 2023 Joe Doe"
>>> }

Edward Welbourne (Wednesday, February 15, 2023 10:45 AM) objected:
>> The problem with that is that I was given to understand that
>> duplicated keys is actually malformed JSON - perhaps I misunderstood.
>> If that's legitimate JSON, then I'm fine with just one.

and, overlapping with my follow-up correcting that,
Kai Köhne (15 February 2023 17:10) replied:

> To my understanding it's valid JSON, at least from the syntax
> side. From
> https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
> :

>  The JSON syntax does not impose any restrictions on the strings used
>  as names, *does not require that name strings be unique*, and does
>  not assign any significance to the ordering of name/value
>  pairs. These are all semantic considerations that may be defined by
>  JSON processors or in specifications defining specific uses of JSON
>  for data interchange

It seems we read the same standard at about the same time, arriving at
the same conclusion ;^>

> And the JSON parsers I tested (Python, Qt) don't treat it as an error,
> either. There seems to be some online linters like
> https://jsonlint.com/ that complain about it, tough.

I think we can live with ignoring a warning from linters that aren't
part of our tool-chain ;^>

I've updated my reviews to the "Comment" version.

That just leaves us with the open question of whether to, instead,
switch to some other way of storing the data - preferably one that
supports multi-line strings - with Ulf currently championing QML and
Thiago YAML.

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

[Edward Welbourne via Development]

So I finally found time to look at the JSON specification [0] and find
that (in section 6) it says, of the name/value pairs in an object:


The JSON syntax does not impose any restrictions on
the strings used as names, does not require that name strings be unique, 


[0] PDF linked from ECMA 404,
https://www.ecma-international.org/publications-and-standards/standards/ecma-404/

It's possible that some JSON linters or tools complain about non-unique
keys, but they're not an *abuse* as such, so we can legitimately go with
the simpler approach Kai has proposed, just one field, Comment (taking
any data as value) will do.

I'll amend my proposed change to QUIP 7 accordingly,

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

[Edward Welbourne via Development]

Kai Köhne (15 February 2023 08:50) replied:
> did you intentionally sent this off-list?

oops - no, outlook's UI tricked me :-(
And, in fact, it just did it again, although I'm sure I hit Reply All this time.
Manually adding development to CC...

For the benefit of everyone else, my reply is below, after the bit of
Kai's earlier mail, that I quoted:

>>> Anyhow, I wonder whether it wouldn't suffice to have _one_ comments
>>> field, instead of a dedicated UpstreamFiles field, and *Notes fields
>>> for every single entry. E.g.
>>>
>>> {
>>>   "Comments": [
>>>  "Upstream files were copied from:",
>>>  "   src/dir1, src/dir2",
>>>  "The license and copyright was derived from dist/LICENSE.txt"
>>>   ]
>>> }
>>>
>>> The benefit I see is that qtattributionsscanner (and any other JSON
>>> tool that might be used by others) has only to care about one
>>> additional field, not multiple ones.

Edward Welbourne (Tuesday, February 14, 2023 7:37 PM) had written:
>> I see the case for it, but it comes at the cost of all the comments being in 
>> one
>> place, not each comment next to the part of the content it relates to.
>>
>> If someone is updating one of many data in an attribution and the comments
>> aren't close at hand, both the author of the change and the reviewers may 
>> fail
>> to notice the detail that the comment mentions that makes it obvious they're
>> doing something wrong.
>>
>> That's not a fatal argument: each attribution is fairly short, so putting the
>> comments in the middle should make it easy to see them when looking at any
>> of the lines they relate to.  None the less, comments and documentation 
>> belong
>> close to the code they relate to ...

> Well, you can also achieve this by duplicating comment fields:
>
> {
>   "Comment": "Upstream files are src/x.cpp, include/y.h",
>   "Files": [ "x.cpp", "y_p.h"]
>   "Comment": "Copyright info is from dist/COPYING",
>   "Copyright": "Copyright (C) 2023 Joe Doe"
> }

The problem with that is that I was given to understand that duplicated
keys is actually malformed JSON - perhaps I misunderstood.  If that's
legitimate JSON, then I'm fine with just one.

> I just don't see the point of dedicated fields if the whole purpose is
> to ignore them in the tooling.

Well, there's more tooling to consider - someone, at least, has run a
JSON-validation checker on some qt_attributions.json files and submitted
patches to fix issues reported there (like line-breaks instead of \n;
and I think that's where I heard about duplicate keys being invalid) -
and in any case there are developers who need to read it, who may
benefit from the keys having names that makes clear which
tooling-relevant keys they relate to.

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

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

[Edward Welbourne via Development]

Hi all,

Having taken part in various third-party updates and felt a need to
leave notes for those who will do the same in future, I have run up
against JSON not having a comment format.  To work round that, I propose
to allow some fields to be included in a qt_attribution.json file for
that purpose.  As a general pattern, I propose allowing ${Field}Notes
for any ${FIELD} that already exists; and a separate UpstreamFiles
field, corresponding to the Files one, to list where in the upstream
source tree to find the files that are to be copied.

This will make the work easier for those who do third-party updates and
avoid various kludges presently in use to work round the lack of
comments (for example, abusing an existing field to first write the note
and then over-write it with the value; the tools that process the files
cope, but it's malformed JSON).

See:
* https://codereview.qt-project.org/c/meta/quips/+/460358
* https://codereview.qt-project.org/c/qt/qttools/+/460116
* https://codereview.qt-project.org/c/qt/qttools/+/460181
* https://codereview.qt-project.org/c/qt/qtbase/+/458824

The last triggered this; the previous two implement it and the first is
an update to QUIP 7.

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

Re: [Development] Do we need VS2019 for Qt 6.6?

[Edward Welbourne via Development]

On 17/01/2023 23:07, Thiago Macieira wrote:
>> The reason is that it is failing to parse a constant expression.

Oliver Wolff (27 January 2023 08:23) replied:
> Generally I think that raising the minimal version could be done, but
> is that reason alone good enough to warrant a minimal version raise
> for every MSVC Qt user? How severe is that issue and how hard is it to
> work around it?
>
> It looks like a minor thing if you put it like that.

So the issue is that we have run into several cases where we need
something to be constexpr, for example in order to be able to use it in
a template, and By The Rules it *is* but MSVC 2019 doesn't grok that
it's really constexpr, so we're blocked from doing what we should be
able to do.

Two examples:

https://codereview.qt-project.org/c/qt/qtbase/+/453446/12
I'm obliged to kludge round this (see latest PS, 17) in order to split a
template's implementation between the case of a numerator that's a power
of two or not. PS 12 is code that Should Just Work (TM).

https://codereview.qt-project.org/c/qt/qtbase/+/441286
Thiago wrote a nice little character-set matcher to help me make
QLocale's number-parsing more efficient, which depends on
makeCharacterSetMatch() being constexpr, but MSVC 2019 lets us down.
That's blocking my fix for QTBUG-107801, issues with some tokens we've
always assumed were single-character actually being multi-glyph in some
(not even vaguely obscure) locales.  Marc has a suggestion for how to
maybe kludge round it, but if we could drop MSVC 2019 we could save some
kludge-research time and just get on with Doing It Naturally.

I doubt these are the only examples out there, and I'm quite sure that
we'll trip over more as time goes by.  I dare say Thiago, Marc or Ville
can give more thorough answers - but, in short, MSVC 2019 is getting in
the way of Doing Things Right and making the most of modern C++,

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

Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )

[Edward Welbourne via Development]

On Monday, 16 January 2023 04:49:23 PST Friedemann Kleint via Development wrote:
>>>>> Summmarising: we stand to gain a speed-up of compilation;
>>>>> particularly for clean builds like in COIN; but it requires some
>>>>> work. We might do a step-by step approach process enabling modules
>>>>> one by one. What do you think?

On 17.01.23 05:09, Thiago Macieira wrote:
>>>> I was going to object to it being in COIN, but considering it may
>>>> improve build times in the CI, especially for constrained platforms
>>>> (like macOS), I withdraw my objection before I even make it. I
>>>> think this effort is worth it.

Christian Tismer-Sperling (17 January 2023 11:55) asked:
>>> What was the reason that you first considered to object to it?

On 17 Jan 2023, at 13:35, Edward Welbourne via Development 
 wrote:
>> While I can't be sure what Thiago was thinking of, one obvious
>> objection to doing this in Coin would be that: if someone changes a
>> source file in a way that needs a #include addition to the changed
>> source file, but Coin's Unity build combines that file with one that
>> has the #include, Coin won't notice, the change will get integrated
>> and those doing a non-Unity builds, or for whom the Unity build
>> splits files up differently, may find themselves with broken builds.
>> I imagine there are other mistakes that can likewise be concealed by
>> a Unity build.

Volker Hilsheimer (17 January 2023 16:26) replied:
> I would actually turn Thiago’s objection on its head and ask that we
> have at least one configuration in COIN that verifies that
> UNITY_BUILDs work, if we agree that this is a good idea.

That's more or less the conclusion I understood Thaigo to have reached,
too.

> In the short term I don’t expect that this will improve effective CI
> performance considerably, at least not until every CI configuration
> uses UNITY_BUILDs. The spread of build times in
> e.g. https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1681530493
> is wild (from a few minutes to almost 1.5hours). No idea why
> windows-11_22h2-mingw11-developer-build is so slow, but in the end,
> the slowest platform for building and testing defines the time we have
> to wait until we know that our changes were good (failing build or
> test shortcuts that, of course).

That rather suggests making the slower builders use Unity while keeping
the fastest build of each platform a traditional build.  Then we test
that both types work while improving Coin's build speeds.

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

Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )

[Edward Welbourne via Development]

On Monday, 16 January 2023 04:49:23 PST Friedemann Kleint via Development wrote:
>>> Summmarising: we stand to gain a speed-up of compilation; particularly
>>> for clean builds like in COIN; but it requires some work. We might do a
>>> step-by step approach process enabling modules one by one. What do you
>>> think?

On 17.01.23 05:09, Thiago Macieira wrote:
>> I was going to object to it being in COIN, but considering it may improve
>> build times in the CI, especially for constrained platforms (like macOS), I
>> withdraw my objection before I even make it. I think this effort is worth it.

Christian Tismer-Sperling (17 January 2023 11:55) asked:
> What was the reason that you first considered to object to it?

While I can't be sure what Thiago was thinking of, one obvious objection
to doing this in Coin would be that: if someone changes a source file in
a way that needs a #include addition to the changed source file, but
Coin's Unity build combines that file with one that has the #include,
Coin won't notice, the change will get integrated and those doing a
non-Unity builds, or for whom the Unity build splits files up
differently, may find themselves with broken builds.  I imagine there
are other mistakes that can likewise be concealed by a Unity build.

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

Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?

[Edward Welbourne via Development]

On Friday, 13 January 2023 06:12:44 PST Samuli Piippo via Development wrote:
>> bitbake runs branch validation as 'git branch --contains  --list
>> '

Thiago Macieira (13 January 2023 16:32) replied:
> Then don't do *branch* validation. I'm sure it can validate tags too.

Indeed, git can: for example

 git tag --contains  --list v5.15.*

just the same as for branches, but using a glob for the tags.

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

Re: [Development] Proposal: let's change the release schedules a bit

[Edward Welbourne via Development]

Tuukka Turunen (14 December 2022 10:44) wrote:
> One of the main problems we face every time with the feature freeze is
> a lot of changes coming in just before the deadline.

That's how deadlines work.

> Having the FF date just before a major holiday period is one item that
> possibly increases the instability. Not everyone is on vacation at the
> same time and especially during the summer different countries tend to
> have a bit different general preferences for the primary holiday
> period.

All of which, to me, is a case for moving the FF a little *earlier*, to
ensure it is robustly before the holiday for (as near as we can hope to
attain) everyone.

> Having the FF in January instead of December and August instead of
> June

Your point about different places having their holidays at different
times makes August a very bad choice: it is *not* after the holidays -
for at least some countries it *is* the holidays.

> would likely reduce the number of changes coming in just before
> the deadline. Spreading the changes more evenly in the feature
> development timeline makes it easier to keep integration test rounds
> passing regularly.

I do not think this would spread the changes more evenly.  Reducing the
number of changes that make it in time for feature freeze won't change
how unevenly they arrive, it'll just change when the mad rush happens.
And putting the FF after some people's holidays and slap bang in the
middle of other folk's holidays (at least for the summer one) would cast
an ugly shadow over those holidays.

Moving a week or three earlier would be better than trying to land after
the holidays and instead landing in the midst of them,

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

Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?

[Edward Welbourne via Development]

On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote:
>>> Will these be returning at some point?

On 1/12/23 01:24, Thiago Macieira wrote:
>> No.

Christian Kandeler (12 January 2023 09:24) asked:
> Out of curiosity: Who gains what by removing branches?

On Gerrit it makes sense; we should kill dead branches there.  I suspect
the code.qt.io deletions were more by accident than design, probably the
mirroring scripts doing something that made no difference until December
(when I believe the old branches were deleted).  I see that github
retains old branches still.

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

Re: [Development] Jira update on 3rd Janaury 2023

[Edward Welbourne via Development]

In response to
>> IMO everybody should only be able to modify their own comments.

André Hartmann (3 January 2023 17:02) replied:
> This is true for almost all cases; but I remember e.g. fixing links in
> other's comments to make further reader's life easier.

I also, not infrequently, improve formatting (e.g. wrapping output in
{noformat} or code in {code}) and fix typos where I believe this will
make it easier for (me and) others to read.  However, I have also on
occasion accidentally clicked the edit pen when I meant to write a new
comment, with problematic consequences (I think I put it back the way
it was, once I noticed ... but what if I did this and failed to notice ?)

> But that is such a rare thing that it should be hidden in a menu or so.

Putting it in a menu would also reduce the foot-gun risk.
And yes, the old icons were less intrusive, but I can live with the
buttons (although the fact that they're buttons close to the "Add
comment" one might increase the foot-gun risk.)

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

Re: [Development] Proposal: let's change the release schedules a bit

[Edward Welbourne via Development]

Ivan Solovev (5 December 2022 14:42) wrote:
> Also, as a developer, I personally find it good that we have FF before
> the holidays. Because having it right after the holidays would anyway
> mean that I need to have everything ready before the holidays. But
> I'll just have less time for that.  I can imagine that the Release
> Team has different opinion, though.

I have a sneaking suspicion Jani's idea is that, with no holiday between
an August FF and October release, it may be possible to narrow the
interval between them.  However, for January to April there is a holiday
intruding, Easter, which isn't even at a fixed point in the calendar
from one year to the next.

Like Ivan I do not relish the prospect of a FF shortly after a holiday;
it would mean getting back from a holiday to a frantic rush to get
things finished up, the anticipation of which might hang over the
holiday.  I would sooner move the schedule half a month earlier -
November FF for February release, May FF for August release - and
accept the calendar interval between the two.

Jani: what is the problem with that calendar interval's present length ?

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

[Edward Welbourne via Development]

El mar, 29 nov 2022 a las 14:56, Volker Hilsheimer [...] escribió:
> I’d like to nominate Mårten Nordheim and Timur Pocheptsov as
> co-maintainers.

+1

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

Re: [Development] Sub-arch optimisations (was: How qAsConst and qExchange lead to qNN)

[Edward Welbourne via Development]

Thiago Macieira (23 November 2022 22:11) wrote:
>> I'll fix it.

> That was easy. I just had to remove code to make it work.

Always a satisfying solution to a problem ;^>

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

Re: [Development] Renaming quint128

[Edward Welbourne via Development]

Thiago shared:
>> https://codereview.qt-project.org/c/qt/qtbase/+/444237
>> https://codereview.qt-project.org/c/qt/qtbase/+/444238
>> https://codereview.qt-project.org/c/qt/qtbase/+/444239

Ivan Solovev (21 November 2022 11:52) replied:
> I can only access the first patch. The other two links show "Not found".

I had a similar problem, but if you go to the first link the other two
are the next two in its relation chain.  Not sure why the pasted URLs
fail, but you can bypass the need for them,

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

Re: [Development] IMPORTANT: Codereview scheduled maintenance break on Monday 7-Nov 7 am CET

[Edward Welbourne via Development]

Thiago Macieira (7 November 2022 19:22) requested:
> Can you confirm the ED25519 key?
>
> $ ssh-keygen -l -f /home/tjmaciei/.ssh/known_hosts | grep codereview
> 256 SHA256:DwwqNluQyJVkOk+3bFMK6NwWYIGjMnqGP+R0k59e3CY 
> [codereview.qt-project.org]:29418 (ED25519)

I can confirm that; it did indeed appear in another of Jukka's mails,

>> ssh_host_ed25519_key
>> 256 SHA256:DwwqNluQyJVkOk+3bFMK6NwWYIGjMnqGP+R0k59e3CY (ED25519)

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

Re: [Development] How qAsConst and qExchange lead to qNN

[Edward Welbourne via Development]

Volker Hilsheimer (7 November 2022 16:51) wrote:
> The open question is whether and when we should deprecate such a
> stop-gap 1:1 reimplementations of std functionality. How to deprecate
> is now well documented, but the wiki starts with the process of doing
> so once we concluded that we shall. It doesn’t give us any guidance
> yet on how to come to that conclusion.

And, just to be clear, that omission was entirely deliberate.  When I
wrote [[Deprecation]], I was quite sure we did not have a consensus on
the answer to that question, so what I wrote takes no position on the
controversy.  On the one hand, the benefits of getting rid of old cruft
argue for deprecating anything for which there is now a better way to do
whatever it was there for; on the other hand, disruption to users of Qt
is unwelcome, arguing for only deprecating anything when its use is
actually apt to cause harm (e.g. the old API incorporates a design bug).

For Qt to remain relevant in the rapidly-evolving C++ landscape, it
needs to change; but one of its strong selling-points has long been its
conservatism in API and ABI, that lets working code keep working.

There is thus an inevitable tension between "move forward, leaving the
past behind" and "if it ain't broke, don't 'fix' it",

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

[Edward Welbourne via Development]

On 04.11.22 12:13, Ulf Hermann via Development wrote:
>> One thing I haven't understood about the ordering problem is why we
>> cannot just define our "invalid" values to always be < any valid one and
>> equal to other invalid ones. This way we get at least weak ordering for
>> all our types and we're done.

Marc Mutz via Development (4 November 2022 16:15)
> That's what we're currently doing, yes. At least for QDateTime.

One factor in why I think partial order is probably a good choice is
that invalid QDateTimes are a bit more complicated than, say, null
QStrings; there is a null QDateTime, but you can also get an invalid one
by asking for a time that doesn't exist in the zone (overtly for spec =
TimeZone, implicitly for spec = LocalTime) in use, when folk moved their
clocks forward over that time in the given zone, typically in spring at
the start of DST.  These QDateTime instances, although invalid, do have
a toMSecsSinceEpoch() that's suitable to passing to
fromMSecsSinceEpoch() to reconstruct a valid date-time that's not what
you originally asked for but is close by.  See [0] for my attempt to do
better than that kludge.

[0] https://codereview.qt-project.org/c/qt/qtbase/+/308729/25

> For QString, we have that isNull() compares equal to empty.

Which makes a fair amount of sense, IMO.
Default-constructed string is empty.

> ... that prompted
> me to remember QOperatingSystemVersion, where we really, genuinely
> have several sets of values where elements from different sets are not
> ordered (Win10  There, partial_ordering is consistent with the current implementation.

Good example.

> We don't _need_ to make invalid values unordered, but it would be the
> mathematically correct thing to do.

... in some cases, at least.  For containers, like QString,
null-is-empty makes perfect mathematical sense, for example; the empty
set is the "null" set (and relation, and function), in so many senses.
Indeed, IIRC, the first teacher to introduce me to it used a
slashed-zero called "null" to denote it.

> We removed QVariant::op< because of these problems. partial_ordering
> would allow [us] to bring it back.

Albeit "whether we *should*" remains a separate story.

>> There may be types where existing operator< work differently (*cough*
>> QTypeRevision), but that just means we need to emulate that same
>> behavior with the new operators.

> Without having looked at QTypeRevision, I agree in general.

Certainly in the first instance we should match existing behaviour as
closely as possible with the new operators; but partial ordering does
present (once we're fully migrated to C++20) a new option that may be a
good choice for some types.  I don't advocate a blanket "do this
everywhere"; but there may well be types for which it makes sense.

>> Indeed the NaN behavior has always been a pain to deal with every time
>> I've encountered it. If we have a chance to avoid it, we should.
>>
>> What is the downside of such an approach?

> The (potential) downside is that it's arbitrary and classes might behave
> inconsistently (one sorts invalid before valid ones, the other vice
> versa). It may also be a bit more work to document (unless we choose not
> to mention that little detail). Or we can't reap any future tool support
> that might be developed for partial_ordering (sanitizers, etc).

The NaN behaviour is a necessary escape from worse surprises; for
example, "if x < 0 and y < 0, then x * y > 0" - except that if you make
NaN < 0 that'll fail.  Of course, having the NaN drop into the else
branch of an if (x < 0) is apt to have it mistakenly presumed to be >=
0, when it also isn't that.  Still, with the language now actually
supporting partial order, we get the option of using it and at least
giving diligent programmers the chance to handle such cases gracefully'
and by overtly making some orderings partial, alert them to the need to.

The question remains: for which of our types will it actually make sense
to have a partial ordering ?  I trust those closest to the code to have
a clue, in each instance.

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

[Edward Welbourne via Development]

On Thursday, 3 November 2022 09:48:49 PDT Marc Mutz via Development wrote:
>>> Here, too, I feel lost. I'm struggling to see what a NIH
>>> std::partial_ordering w/o the weak and strong counterparts and w/o
>>> op<=> language support could achieve, except another vocabulary type
>>> mismatch.  Can you elaborate?

On 03.11.22 18:38, Thiago Macieira wrote:
>> We can use it until we can depend on C++20. Like QSpan, that's why it's 
>> there.

Marc Mutz (4 November 2022 11:22)
> The difference is that QSpan vs. std::span doesn't create an impedance
> mismatch. QPartialOrdering vs. std::partial_ordering does, esp. since
> QPartialOrdering lacks an implicit conversion to/from
> std::partial_ordering, and the member names are different.

Since my comments on QDateTime are implicated here, I should note that -
since it would be a behaviour change - an initial transition to a weak
ordering that preserves invalid < valid could perfectly well suffice
until we *do* transition to C++20 and *can* use std::partial_order, at
which point I do think it would make sense to change our types with
invalid (but supported) null-forms to make them incomparable, ideally
all at the same time.

> With the exception of qfloat32, I'm not aware of any Qt type that
> would exhibit partial ordering semantics atm.

I take it you mean qfloat16, whose NaN is incomparable,

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

Re: [Development] Duplicated test data tags

[Edward Welbourne via Development]

Mitch Curtis (14 October 2022 03:40) replied:
>>> QTest::failOnWarning (introduced in 6.3) could also be used by tests
>>> to make that warning fail the test:
>>>
>>> https://doc.qt.io/qt-6/qtest.html#failOnWarning

Edward Welbourne (Friday, 14 October 2022 4:56 PM) answered:
>> True enough; but you would need to add that to the start of your
>> _data() function; I think a global setting is more in line with
>> what's needed.

Mitch Curtis (17 October 2022 02:59) asked:
> So even init() would be too late? I would have thought that would run
> before the data function.

It's only run before the test itself - from invokeTestOnData(), which is
what we loop over per call to the test function after we've built the
data table.

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

Re: [Development] Duplicated test data tags

[Edward Welbourne via Development]

Milian Wolff (Friday, 14 October 2022 3:00 AM) wrote:
>> >> I have many times accidentally written bogus code that duplicated the
>> >> tags.  Getting a warning is useful, so thanks for working on that!
>> >> 
>> >> But we won't easily spot these in the thousands of lines of outputs a
>> >> large test suite is generating.

On Freitag, 14. Oktober 2022 10:55:54 CEST Edward Welbourne wrote:
>> Indeed, that strikes me as eminently plausible.
>> Especially as one of the things I've been picking up on (and I've fixed
>> various of them, at least in QtCore) as a result of chasing these down
>> is that we have quite a few tests with QWARN messages, that really
>> should be anticipated (so that the test fails if the warning isn't
>> produced; and so that the test log isn't cluttered with the warnings)
>> using QTest::ignoreWarning().
>> 
>> I should also take this opportunity to encourage all developers to watch
>> out for QWARN messages in test output: if it's unexpected, it may be the
>> symptom of a lurking bug; otherwise, its presence should be tested for,
>> see preceding.  If the code under test fails to produce a warning that
>> was expected, that's an issue the test should catch.

>> >> At the very least I would suggest something akin to QT_FATAL_WARNINGS
>> >> that can be set to more easily spot faulty client code.
>> 
>> Perhaps, given the above, we should just encourage developers to use
>> QT_FATAL_WARNINGS more often ?
>> 
>> I do note, however, that it seems not to have been documented; I shall
>> add a doc update to my branch.

Milian Wolff (Friday, October 14, 2022 12:29) replied:
> That is sadly not an option in many situations. The silencing of the warnings 
> does not influence the fatal-abort to my knowledge? See 
> `QMessageLogger::warning`:
> 
> ```
> void QMessageLogger::warning(const char *msg, ...) const
> {
>     va_list ap;
>     va_start(ap, msg); // use variable arg list
>     const QString message = qt_message(QtWarningMsg, context, msg, ap);
>     va_end(ap);
>
>     if (isFatal(QtWarningMsg))
>     qt_message_fatal(QtWarningMsg, context, message);
> }
> ```

That sounds like something we should look into changing.  It runs
counter to what QTest::ignoreWarnings() tells its user; they may
reasonably expect setting the environment variable to catch only
warnings they haven't suppressed.  However, that's very much within
QMessageLogger code, not under QTest's control :-(
QTBUG-107659

> So while `qt_message` is intercepted, the `qt_message_fatal` is not which 
> then 
> would kill the app even for "expected" warnings.

:-(

> What's worse, there are many warnings where you don't know how many of them 
> will occur. We e.g. run our unit test suite using the offscreen platform 
> plugin and are drowning in warnings such as:
>
> ```
> This plugin does not support setParent!
> ```
>
> And so far I could not find a reliable way to prevent this.

QTBUG-107660

> Similarly, we need a custom OpenGL profile which always triggers this warning 
> when Qt WebEngine is also used:
>
> ```
> An OpenGL Core Profile was requested, but it is not supported on the current 
> platform. Falling back to a non-Core profile. Note that this might cause 
> rendering issues.
> ```
>
> Meaning: there are sadly some situations where warnings are emitted that you 
> do not have control over. Meaning, Qt_FATAL_WARNINGS is sadly not an option 
> today :(

Sounds painful.
Thanks for the dose of real-world practicality.  I'll need to give
further thought to how to make the new warnings "enforceable"
(without enforcing them all the time).

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

Re: [Development] Duplicated test data tags

[Edward Welbourne via Development]

Milian Wolff (Friday, 14 October 2022 3:00 AM)
>> I have many times accidentally written bogus code that duplicated the
>> tags.  Getting a warning is useful, so thanks for working on that!
>>
>> But we won't easily spot these in the thousands of lines of outputs a
>> large test suite is generating.

Indeed, that strikes me as eminently plausible.
Especially as one of the things I've been picking up on (and I've fixed
various of them, at least in QtCore) as a result of chasing these down
is that we have quite a few tests with QWARN messages, that really
should be anticipated (so that the test fails if the warning isn't
produced; and so that the test log isn't cluttered with the warnings)
using QTest::ignoreWarning().

I should also take this opportunity to encourage all developers to watch
out for QWARN messages in test output: if it's unexpected, it may be the
symptom of a lurking bug; otherwise, its presence should be tested for,
see preceding.  If the code under test fails to produce a warning that
was expected, that's an issue the test should catch.

>> At the very least I would suggest something akin to QT_FATAL_WARNINGS
>> that can be set to more easily spot faulty client code.

Perhaps, given the above, we should just encourage developers to use
QT_FATAL_WARNINGS more often ?

I do note, however, that it seems not to have been documented; I shall
add a doc update to my branch.

Mitch Curtis (14 October 2022 03:40) replied:
> QTest::failOnWarning (introduced in 6.3) could also be used by tests
> to make that warning fail the test:
>
> https://doc.qt.io/qt-6/qtest.html#failOnWarning

True enough; but you would need to add that to the start of your _data()
function; I think a global setting is more in line with what's needed.
Fortunately we do have QT_FATAL_WARNINGS; I had forgotten about that.

So the question is: does it suffice to encourage developers to test with
that enabled, or do we need something more specific to the particular
issue of tag and column names in _data() functions ?

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

[Development] Duplicated test data tags

[Edward Welbourne via Development]

QTBUG-107185 revealed that QTest did not check for duplicated test data
tags, i.e. parameters to newRow() / addRow(); when I looked at the
implementation I found it also neglected to check for duplicated
addColumn names.  So [0] sets out to fix that.

It turns out that Qt itself has "quite a lot" of instances of duplicate
test data tags.  (I've only found one duplicate column, thankfully; but
there may be more.)  So, for now, the fix merely produces a warning; and
I do encourage all to watch out for "Duplicate data tag ... - please
rename." messages in test output (once [0] has landed).  Likewise for
similar with "column" in place of "tag".

[0] https://codereview.qt-project.org/c/qt/qtbase/+/436495

You can see from the branch it's the tip of, currently, some of the many
cases of duplication we had before it brought them to my attention.
There remain more even in qtbase and I haven't (for now, at least)
looked further afield.

The present draft of that change has #if-ery to turn duplication of
column or row names, in QTest data tables, at Qt 7, into a fatal error.
How realistic do folk think it is that client code authors will respond
to the warnings in time for that ?

I have, for now, included #if-ery complications that let you, when
building QtTestLib, define Q_TEST_REJECT_DUPLICATE_ROW to 0 or 1 in the
build system (and likewise for ..._COLUMN) to override the default
behaviour (0 means warning only even for Qt 7; 1 means fatal even before
Qt 7) but without any build infrastructure (yet) to set that.  Is this
adequate or overkill; does anyone have a better suggestion ?

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

Re: [Development] C++20 goodies (was: Using '#pragma once' instead of include guards?)

[Edward Welbourne via Development]

Henry Skoglund (11 October 2022 22:18) wrote:
> Sometime in the far future when Qt requires c++20 things might
> improve: we could use std::source_location::filename
> (https://en.cppreference.com/w/cpp/utility/source_location/file_name )

Nice.  I'm a bit surprised file_name() returns a char* rather than a
std::filesystem::path, but it'll do.  It's also nice to see
source_location has a function_name() that can finally unify the
disparate ways of getting that information.

More things to look forward to when we eventually get to C++20 ...

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