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

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Edward Welbourne]

Volker Hilsheimer (26 September 2022 09:11) wrote:
> I would like to nominate Christian and Andy as co-maintainers for Qt SQL.

+1

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

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

[Edward Welbourne]

On Wed, Sep 14, 2022 at 5:16 PM Thiago Macieira wrote:
>> How about a wrapper to the wrapper?

samuel ammonius (14 September 2022 23:52) replied:
> Why wrap a wrapper that wraps C++ when you can just wrap C++? Aside
> from the fact that it probably wouldn't be any easier, it would also
> start to add up the overhead of function calls.

Given the quote Thiago followed that suggestion with, I encourage you to
interpret the suggestion as a joke,

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

Re: [Development] qsizetype

[Edward Welbourne]

Nicolas Fella wrote:
>> The fact that KDE does not use Qt6 yet has rather little to do with
>> the quality of Qt6.

Kevin Kofler (8 September 2022 01:37) replied:
> Where have I claimed that it does? I sense a strawman…
>
> My point is that it takes time for KDE and other downstreams to adopt
> a new major release of Qt, no matter the reason why it does, and that
> moving on to Qt 7 before or shortly after the downstream consumers are
> ported to Qt 6 would be very unhelpful.

Well, since you brought up the strawman, where exaactly did anyone claim
Qt 7 was in any sense so imminent that it'd be "before or shortly after"
KDE has upgraded to Qt 6 ?  Please do not mistake long-term planning for
an intent to release what we're planning any time soon.  I don't know
what the plans for the major version cycle currently are, but the
roadmap for the foreseeable future is all about continuing releases of
Qt 6.

The reason we plan for Qt 7 is that it's the next time we can make
certain kinds of backwards-incompatible changes.  When we decide that
such a change is needed, we plan for it, because we can't do it yet, or
indeed any time soon.

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

Re: [Development] qsizetype

[Edward Welbourne]

Volker Hilsheimer (5 September 2022 17:31) wrote:
>> We have virtual functions that take int and could potentially be fed
>> by the return value of container.size() (or generally need to be able
>> to handle values >2G), so should take a qsizetype (say,
>> QAbstractItemModel::insertRows, overridden by QSqlTableModel). I
>> don’t see how we can change those until Qt 7.

We can, however, get ahead of the game with the Qt 7 version already
sketched out and tested in advance, within #if-ery.  It may bitrot a bit
between now and Qt 7, but getting it substantially ready now should make
the 7.0 preparations less frenetic than what I was doing two years ago,
upon discovering how many ### Qt 6 comments were going unattended.

>> So we will have to live with some inconsistency.

Indeed.

>> For the other modules, esp those related to user interface
>> development, the chance that an int-API is called with a value above
>> 2G seems very low, even if they are operating internally on Qt
>> containers. I might be missing some real world examples though where
>> e.g. QGraphicsScene or a QTextDocument needs to operate on >2G items.

While I mostly agree, I do feel obliged to point out that there are
surprises out there.  It's now about a quarter century since I had to
rework a GIS system's datastore to cope with vector maps with more than
2 Gi of data describing the entities in them, because we had customers
whose datasets were that big.  (As this had to work on systems with
32-bit fpos_t, this involved a virtual file system.  But we had one of
those anyway, so I just had to teach it to be 64-bit safe and split each
logical file up into <= 2 GiB physical files.)  So there have been folk out
there with vast datasets for (at least) a quarter century.  I suspect
most such folk are still in the "specialised" category, so don't really
expect them to be using Qt to manage their vast data-sets, but I do
expect there shall be ever more use-cases where folk gently find the
sizes of their data-sets growing and will be "disappointed" if they hit
a 2 Gi size limit in the software they're using.

In most cases such datasets can and should be handled progressively, but
letting the author of a prototype do it the dumb way - by loading
the whole dataset in one go - will mean they can do the prototype in Qt,
which makes them more likely to still be using Qt when they do the
production version (and optimize away the insanely huge loads).

Marc Mutz (5 September 2022 19:15) wrote:
> Experience shows that we'll have many, many, many things to consider
> come Qt 7. And as Qt 6 has shown, such trivialities will be left by
> the wayside.

See above; indeed, two years ago, I discovered many things, some of them
by no means trivial, that had been punted to the major version and
forgotten about.  That was in addition to all the things I knew about
that needed to happen at the major version change.

This can, however, be at least party addressed by judicious improvements
to process: we could, for example, require every ### Qt 7 comment to
mention a Jira ticket describing the work that needs to be done for Qt
7, of which it's a part, marked suitably in Jira (Fix version 7.0,
perhaps a tag), so that we can search effectively for these tickets when
the time comes.

> So, playing the devil's advocate here: if this work is too much for Qt
> 6.x, what makes us think we'll get it done in the frenzy leading up to
> Qt 7.0?

We can be better prepared than we were for Qt 6.  We can do quite a lot
of preparation now to reduce that frenzy: simple mindless #if-ery on
QT_VERSION can do some of that, the QT[67]_ONLY macros some more.

> 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 debt until 7.0. From a C++ POV, we now only need major
> versions to break polymorphic inheritance (incl., but not limited to,
> virtuals), and signals and slots (the latter because of conflicting
> SC-solutions for new-style and old-style connects).

All of which also helps us reduce the amount of work we're forced to
leave pending until Qt 7; we can do it now and they'll happen naturally,
without any work during the mad frenzy.  We can then clean up after that
frenzy subsides, rearranging the code to take version >= 7 for granted,
starting after feature-freeze.

> That said, no actual user-visible size-mismatch bug has yet required
> the change of public interfaces.

This is good to hear; but see above.  I do think it's only a matter of
time before some class of client code does run into a need to manage
data-sets we would presently consider insanely huge; and we'll probably
be surprised by which application domain ends up needing it first.

For that matter, the further we progress towards 64-bit usage, the more
"specialized" categories of software there shall be, that presently have
to use custom software to handle their vast 

Re: [Development] results of July flaky tests fixing

[Edward Welbourne]

Volker Hilsheimer (1 September 2022 11:28) wrote (inter alia):
> * hardcoded waiting times is an anti-pattern.

A good way to avoid them is to use the QTRY_*() family of macros, as
long as you can find something that shall become true by the time the
waiting is no longer needed.

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

Re: [Development] How to do deprecation

[Edward Welbourne]

I wrote:
>> TL;DR: there's a new [[Deprecation]] wiki page, please review.

Friedemann Kleint (1 August 2022 09:49) replied:
> It misses an important part, IMO:

> Try to get an idea of the impact of your planned deprecation by building
> all of Qt and ideally Qt Creator (producing patches fixing the
> deprecation warnings).
>
> If that turns into an huge exercise taking several days, it becomes
> clear that the deprecation is not feasible.

Fair point.  I have expanded the last paragraph of the introduction
(which touched on this, at least) - please review,

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

Re: [Development] Code Review of Build File Changes

[Edward Welbourne]

On Wednesday, 20 July 2022 11:29:57 PDT Mattie Nejati wrote:
>> I’m Mattie, a Ph.D. student at the University of Waterloo and I’ve
>> been studying the code review process of build files in Qt. For
>> example, I’ve found that changes to build files are 2 to 4 times less
>> likely to be discussed during code review than changes to source code
>> or test files.

Thiago Macieira (21 July 2022 00:30) replied
> I dispute the hypothesis. You haven't proven it, and you're now
> proceeding to find out why something is before ascertaining that it is
> so.

You also need to control for complexity of changes.  I will hazard a
guess that a significant subset of changes to build files are simple
changes such as adding a new source file to a list of source files; a
second significant subset will be adding a new sub-directory to some
project, with a fairly straightforward build config that's a copy of
some other sub-directory with trivial details changed.  It is no
surprise that these get no comment in review.

So you need to distinguish trivial changes to build configuration (to be
compared with trivial changes to source code, of which there are also
several categories) from Real Work on the build system, which defines
new CMake functions or reworks existing CMake functions to fix bugs or
extend their capabilities.  These last are then comparable to the Real
Work changes to source code (that, if they touch the build system at
all, typically do so in trivial ways).

In short, when comparing how likely different categories of change are
to be discussed in review, the first question to ask is how complex the
change is; and you'll need to control for that when comparing changes in
different categories.  In particular, a commit that mixes changes of
different categories may be complex in one but trivial in the others.

> There are two people who can review build system changes. You should
> find other code areas that only have one or two people who can ever
> review them (or, worse, zero) and there's a similar symptom there.

and you'll likely find those two people do most of the non-trivial
change to the build system, and review each other's work, at which point
Volker's observation that they share an office may be relevant.  In
contrast, the two people who do most (and review each other's)
non-trivial changes to date-time code sit on opposite sides of the
Atlantic, so you'll see in review discussions the build team would have
had across their desk.

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

Re: [Development] Fw: How to do deprecation

[Edward Welbourne]

Lars wrote:
>> So instead of
>>
>> #if QT_DEPRECATED_SINCE(6, 4)
>> QT_DEPRECATED_VERSION_X_6_4("Use size() or length() instead.")
>> inline qsizetype count() const { return d.size; }
>> #endif
>>
>> You’d have:
>>
>> QT_DEPRECATED_METHOD(qsizetype count(), 6, 4, "Use size() or length() 
>> instead.”)

Jaroslaw Kobus (21 July 2022 09:51) replied:
> it would be really cool to have it like this. However, just joining
> QT_DEPRECATED_SINCE with QT_DEPRECATED_VERSION_X_Y_Z would also be a
> small and simple step forward.

The thing is, the only way to do that is indeed to do it in the form of
a macro such as Lars described, since the results of preprocessing must
be capable of producing:
* No declaration at all
* The declaration with a [[deprecated]] marker
* The plain declaration

and the C preprocessor is very simple in its capabilities.  In
particular, you can't cause the #if-ery round some code to define a
scope in which all declarations are automagically preceded with a
deprecation marker, so you can't get away from needing a macro applied
to each of the declarations; and that can't vanish entirely unless every
part of the declaration is packaged in its parameters (since anything
outside its parameter list will still be seen by the compiler), unless
you separately wrap it in #if-ery.  So what Lars proposes is the only
way to unify the two present intrusions into code.

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

Re: [Development] How to do deprecation

[Edward Welbourne]

On 20 Jul 2022, at 16:50, Edward Welbourne wrote:
>> We noticed recently that some APIs had been wrapped in #if-ery on
>> QT_DEPRECATED_SINCE(major, minor) without having QT_DEPRECATED or one
>> of the QT_DEPRECATED_VERSION* macros prepended to the actual
>> declarations within that #if-ery.  This meant that when you build
>> with QT_DISABLE_DEPRECATED_BEFORE set to a recent enough version, the
>> declarations vanished but code that was still using it never got a
>> deprecation warning from the compiler, no matter how
>> QT_DEPRECATED_WARNINGS_SINCE was set.  So no-one had been warned to
>> fix their uses of deprecated API and the code that did so duly broke
>> the build.  Hopefully we can all agree that this is bad.

Lars Knoll (21 July 2022 09:31) replied:
> Agreed. I think part of the problem is that you currently need to do
> several things to properly deprecate a method.
>
> * You need to wrap the method in QT_DEPRECATED since #ifdefs
> * You need to add a QT_DEPRECATED_VERSION_X_maj_min macro before the 
> declaration
> * You need to document the method as deprecated using the \deprecated tag
>
> It’s way too easy to make mistakes here. One solution could be to
> reduce this down to one way of deprecating:
>
> QT_DEPRECATED_METHOD(method, major, minor, reason)
>
> So instead of
>
> #if QT_DEPRECATED_SINCE(6, 4)
> QT_DEPRECATED_VERSION_X_6_4("Use size() or length() instead.")
> inline qsizetype count() const { return d.size; }
> #endif
>
> You’d have:
>
> QT_DEPRECATED_METHOD(qsizetype count(), 6, 4, "Use size() or length() 
> instead.”)
>
> It should be possible to make this work using some macro magic, so
> that it’ll expand to the right declaration (with or without warning or
> removed) depending on Qt version and the QT_DISABLE_DEPRECATED_BEFORE
> setting.

That's all well and good for the declaration - albeit you lost the
"const" after count() - but notice that the body just got lost; and
wherever the definition of the method now happens, it needs to be
wrapped in some #if-ery so that the compiler doesn't see it if it hasn't
seen the delcaration.  Likewise for any test code that remains to test
it as long as it's still there.

Also the machinery of QT_DEPRECATED_METHOD(method, major, minor, reason)
expanding to nothing for some settings, and possibly different things
for other settings, of QT_DEPRECATED_WARNINGS_SINCE and
QT_DISABLE_DEPRECATED_BEFORE entails (thanks to the limitations of the C
preprocessor) there being a family of macros (or possibly several
families) of form QT_DEPRECATED_METHOD_M_m(method, reason) analogous to
the existing QT_DEPRECATED_VERSION_M_m, its _X_ variant and the whole
new family of similar things that Ivan's in the process of introducing
[0].  These families are in danger of becoming a maintenance burden, so
adding more of them should be approached with care.  We can probably
automate the generation of those using some CMake magic, though,
although the configuration for that may end up somewhat runic.
See [1] for recent discussion related to this.

[0] https://codereview.qt-project.org/c/qt/qtbase/+/422121
[0] 
https://codereview.qt-project.org/c/qt/qtbase/+/422121/comment/f158a91c_42c24503/

And we'd need a similar macro for enum members, with matching #if-ery
round the case statements for them, and another for the (rarer) case of
deprecating a whole class.  Along with associated families of _M_m
variants to implement them.  Pretty it won't be.

All of which is as much as to say: it's complicated.  I can believe it
can be done - but show me working code and a few sample symbols (of each
kind) deprecated using it, then I'll be more confident.  In any case, in
the mean time, we need to be clear about how we use the existing
machinery.

> Oh, and qdoc should of course pick up those things automatically, so
> you don’t need to add the qdoc tag in the docs :)

That, at least, I can agree with - although I'd need to hear from Topi
whether it's feasible.  My guess is that it should be, since QDoc is now
based on clang, which surely does know about macros - unless what QDoc
sees is on the wrong end of the macros having been expanded; but then it
should be able to just look for the [[deprecated]] or whatever tag the
macro expanded to (and QDoc would need suitable settings of
QT_DEPRECATED_WARNINGS_SINCE and QT_DISABLE_DEPRECATED_BEFORE); but this
would lose the information about the version at which it was deprecated,
so my hope is that we can get the macro form.

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

[Development] How to do deprecation

[Edward Welbourne]

Hi all,

TL;DR: there's a new [[Deprecation]] wiki page, please review.

We noticed recently that some APIs had been wrapped in #if-ery on
QT_DEPRECATED_SINCE(major, minor) without having QT_DEPRECATED or one of
the QT_DEPRECATED_VERSION* macros prepended to the actual declarations
within that #if-ery.  This meant that when you build with
QT_DISABLE_DEPRECATED_BEFORE set to a recent enough version, the
declarations vanished but code that was still using it never got a
deprecation warning from the compiler, no matter how
QT_DEPRECATED_WARNINGS_SINCE was set.  So no-one had been warned to fix
their uses of deprecated API and the code that did so duly broke the
build.  Hopefully we can all agree that this is bad.

So I went looking for where we document how to do this properly and was
mildly surprised to find no such documentation.  If anyone happens to
know where it's documented, please do let me know.  I managed to find
docs for QT_DISABLE_DEPRECATED_BEFORE, QT_VERSION_CHECK and QDoc's
\deprecated, but none for various other related macros (despite some
search results, leading to pages in which the word DEPRECATED did not
appear) and certainly nothing covering how all the pieces fit together.

So I wrote a wiki page [0] about the process, as I understand it, and
managed to get some others to look it over and point out the more
obvious deficiencies of the first draft.  I think it is now ready for a
wider review and perhaps now would be a good moment for us to discuss
whether the process described (to the best of my ability) there is in
fact fit for purpose and whether there are caveats, restrictions or
further complications that should be documented, or further advice that
should be included there for those contemplating a deprecation.

* [0] https://wiki.qt.io/Deprecation

What I have described is merely what I understand to be current best (or
at least somewhat standard) practice; obviously, if better practice can
be devised, I'd love to know what it is.

In particular, one thing caught my attention when documenting the
defaults - if you predefine QT_DISABLE_DEPRECATED_BEFORE, then it is
used as the default for QT_DEPRECATED_WARNINGS_SINCE, which leads to no
deprecation warnings being given, because all the API that would be
warned about is simply omitted.  So you get compiler errors.  These are
usually less helpful than warnings, at least when the _X_ variants of
various macros are used, with even a half-way helpful message.  So
perhaps we should change the default values here.

When QT_DISABLE_DEPRECATED_BEFORE isn't predefined, it gets defined to
something suitably ancient and QT_DEPRECATED_WARNINGS_SINCE defaults to
the current version.  Perhaps that should remain the default, even when
QT_DISABLE_DEPRECATED_BEFORE is predefined.


I have also added a related section to Fabian's new page [1], covering
its application to deprecations.  Feedback on that page would, no doubt,
be generally appreciated.  Or, of course, you could just improve it
right there in the wiki; same for [[Deprecation]].  It's a wiki.

* [1] https://wiki.qt.io/Merging_breaking_changes_of_internal_API

If anyone feels enthusiastic about making a QUIP of either or both, I'd
be happy to help,

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

Re: [Development] Some OpenSSL auto tests fail to link with -DFEATURE_openssl_linked=ON

[Edward Welbourne]

Thiago Macieira (17 July 2022 00:34) wrote:
> Because they don't even try to link to the library.
>
> Since I'm not allowed to fix these tests, I'm just reporting. Those are the
> only auto tests in qtbase that fail to compile for me.

QTBUG-105046

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

Re: [Development] Proposal: move Qt provisioning scripts and 3rd party components into a dedicated repo

[Edward Welbourne]

Volker Hilsheimer (14 July 2022 11:23) wrote:
> Our 3rd party dependencies currently live in the submodules where they
> are used. For some 3rd party components, that means we have two,
> sometimes different copies (e.g. assimp in both Qt Quick 3D and Qt 3D,
> only one of them patched).

Having two checkouts of the same thing is not nice; having them not even
on the same version is positively nasty.

> And it makes it in general messy to maintain an overview of those 3rd
> party components. We have a responsibility to keep track of those,

That's supposed to be handled by qt_attribution.json files; do you have
any evidence that we're failing at it ?

> and to keep things up-to-date.

That, indeed, is a chore; but I don't see how moving them to another
module would help.  Indeed, when we do updates to a 3rdparty component,
sometimes it requires parallel changes to the code that calls it.  That
is easy to synchronise if they're in the same module.  Our dependency
tracking system does provide a way to do it with them in separate
modules, but it's one more complication to have to struggle with.

> I think that would be easier if we move them into a single repo with
> all 3rd party libraries.

Aside from the case of duplicated 3rdparty components, I don't really
see how this would make it easier.  Those who maintain the code that
exercises the 3rdparty component would still need to take care of its
updates, along with any needed changes to their code using it, but this
work would now be split across two modules, with a dependency gate in
between, instead of being localised to one module.

Indeed, even for a third-party component that's presently used by two Qt
git modules, if one of those is actively maintained and the other is in
maintenance mode (particularly if its maintainer has quietly slipped out
of touch), an update to the third-party component driven by the former
may break the latter (if we switch to making them use the same
version). You'd either have to kick the latter out of Qt (in order to be
able to take in the update) or do the needed maintenance on it, and we
might not have anyone sufficiently familiar with it to do that robustly.

That might still be a good thing (forcing us to address our lack of
adequate cover for a module we still ship), but it'd be a new source of
pain.

> Our provisioning process in the CI system could then use the
> respective “native" build systems of each 3rd party component in that
> repo to install them as system libraries.

That's great as long as your builds are always in virtual machines, but
very very unwelcome for local native builds, unless I'm misunderstanding
what you mean by "as system libraries".  First, I do not want the
software I build to install random crap all over where my operating
system keeps libraries; second, I routinely build several versions of Qt
in parallel, from different source trees into different build trees.
That "might" lead to conflicts - and, if you're using the third-party
code's own build systems, you're opting to accept whatever bad policy
they have for where to install themselves as system libraries.
So I hope you meant something else by "as system libraries."

If we're going to use their native build systems, we should engineer
that they install into some part of Qt's build tree, that Qt's build
system then adds to the "system" library and header paths for builds in
that tree.  We need this, in any case, so that we can bundle those
libraries up with the resulting Qt binaries when we want to build
packages that can be installed.  (One exception to that is the 3rdparty
components only used in building, e.g. gradle.  The packaging scripts
don't want to pick those up.)

> This will speed up the build of Qt (and removes noise from those
> libraries, some of which are not exactly free of warnings),

That, indeed, would be welcome.
However, see note below on stray 3rdparty .c files.

> and it allows us to gradually stop shipping Qt binaries that use the
> bundled 3rd party stuff.

I fail to follow - how exactly does this let us do that ?  The only case
of it can think of is anywhere that we can defer to the system libraries
and, surely, all distributions that have those system libraries ship
their Qt with a dependency on the relevant system library already, so
build Qt without the internal 3rdparty dependency.

> That will be a big step towards reducing our security relevant body of
> code. It won’t be possible for all 3rd party components

Indeed, we have some third-party components that are just a stray .c
file without a build system; and more where we've extracted the subset
we need from a larger upstream, discarding the rest along with their
build system.  I think we're stuck with those as part of our source tree
(and their warnings as part of our build logs).

> and on all platforms, but at least it allows us to move into that
> direction.

If it lets us merely take the few duplicated third-party components out,
so that there's 

Re: [Development] Proposal to delete the "Maintainers" group in gerrit

[Edward Welbourne]

Volker Hilsheimer (1 July 2022 12:55) wrote:
> There might be value in having a better review process for
> modifications to the authoritative maintainer list (I believe anyone
> with a Qt account can edit the wiki).

I suppose our wiki is built on MediaWiki, which is capable of some forms
of access control and locking of pages; who sysadmins our wiki ?
Maybe there's a technical fix to this ...

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

Re: [Development] Chief Maintainer election

[Edward Welbourne]

Albert Astals Cid (2 June 2022 13:47)
> I don't want to argue with who can cast a vote or not, but there is a
> bit of discrepancy between
>   https://wiki.qt.io/Maintainers
> that is said to be the authoritative list of maintainers in
>   http://quips-qt-io.herokuapp.com/quip-0002.html
> and
>   
> https://codereview.qt-project.org/admin/groups/a60ed457f6e3833c81023c72743ba73c7e23fb09,members
> 
> It would be good if such discrepancy did not exist :)

Indeed - that sounds like more for the Ghost Maintainers discussion at
QtCS next week, for those that can make it.

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

Re: [Development] Default assignees in Jira (was: Jira tickets for Qt Print Support)

[Edward Welbourne]

Sze Howe Koh (01 June 2022 16:03) wrote:
> Changing the default of Qt Print Support to "Unassigned" sounds
> reasonable in this case. How does this occur?

I believe Jira admins do this on request.
I suggest Mike e-mail Alex Blasche about that.

> Also, Qt 3D tickets are auto-assigned to Sean Harmer who hasn't been
> active in ~1.5 years [1]. Mike Krus has been manually taking recent
> tickets [2] and has privately expressed willingness to take Sean's
> place -- I'd like to nominate Mike as default assignee for Qt 3D. As
> far as I'm aware, the formal procedure for this and the eligibility
> criteria are not specified in any QUIP -- does it make sense to add
> Jira default assignees to QUIP 2?

I think the default assignee situation is mostly a case if "is anyone
willing ?" with perhaps a side-order of whether the Maintainer of
relevant code considers them suitable.  So if Mike Krus is willing and
we have no objection from a the Maintainer of Qt 3D, it'd be better to
have the tickets assigned by default to someone willing and active.

I see Sean is in fact listed [0] as one of the Maintainers of Qt 3D
(alongside Laszlo Agocs, Svenn-Arne Dragly and Paul Lemire); if he is no
longer active, it's perhaps time for someone to politely contact him and
ask if he'd like to step down and, if so, in favour of whom.  The coming
virtual QtCS [1] has a session on the question of how we deal with Ghost
Maintainers, so this may be an example to take up there.

[0] https://wiki.qt.io/Maintainers
[1] https://wiki.qt.io/Qt_Contributors_Summit_2022_-_Program

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

Re: [Development] QtCS2022 - Sessions and Timeslots

[Edward Welbourne]

Aleix Pol (24 May 2022 18:20) wrote:
> I added a session in the wiki (about Qt and Wayland) and I got a
> message that it was in moderation and I still don't see it in there.
>
> Do you know what is happening? Has this happened to others?

Sounds like the wiki config's borked again.
Hopefully easy to fix once Pedro gets hold of IT support folk,

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

Re: [Development] Nominating Jonas Karlsson as maintainer for Qt Quick 3D Physics (and consequently for approver status)

[Edward Welbourne]

Paul Tvete (12 May 2022 10:12) wrote (inter alia):
> According to my interpretation of QUIP 2, this implies approver
> status, but to be on the safe side, I also explicitly nominate him as
> approver.

For reference, the relevant wording in [QUIP 2]

  Becoming Maintainer of anything in a main module of Qt implies
  becoming Approver throughout Qt, if one is not so yet.

[QUIP 2] 
http://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-a-maintainer

I believe it's fair to say Qt Quick 3D is a "main module of Qt" and that
the new Physics engine is "in" it.

So I concur with Paul's interpretation,

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

Re: [Development] Nominating Ievgenii Meshcheriakov for approver

[Edward Welbourne]

Alex Blasche (6 April 2022 14:05) wrote:
> I'd like to nominate Ievgenii Meshcheriakov as approver in the Qt Project.

+1

> Disclaimer: I am Ievgenii's line manager in TQtC and as such have a close 
> working relationship with him.

and I'm in the team he leads,

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

[Development] Cherry-picks lost and forgotten

[Edward Welbourne]

Hi all,

Today I noticed, when pushing a conflict-fix for a cherry-pick, that
Gerrit puts the Owner into the attention list, but no-one else.  As the
owner is the cherry-pick 'bot, this isn't very helpful.

I've subsequently been looking through the (hundreds of) open reviews
owned by the 'bot and finding the ones that have no attention set.
Aside from the ones that are due to the above, of which there are
plenty, I have found quite a few where the CI rejected a change but
no-one got added to the review.  We may be able to do something about
that, but that'll probably only catch future examples (albeit I restaged
the ones I noticed), so I encourage everyone to:
* manually add some reviewers to the attention set when you push a
  conflict-fix, and
* review [0] (self's open picks) and [1] (which Marc calls "Lost
  Treasures") regularly to see if anything of yours is dangling.

[0] 
https://codereview.qt-project.org/q/owner:cherrypick_bot%2540qt-project.org+status:open+author:self
[1] https://codereview.qt-project.org/q/attention:self+NOT+branch:dev

In particular, add someone to the attention set of anything in [0] that
has no-one and needs attention,

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

Re: [Development] 6.2.4 problems ?

[Edward Welbourne]

Le Tue, 22 Feb 2022 10:08:30 -0800, Thiago Macieira écrivait:
>> After 6.2.4, the 6.2 branch becomes irrelevant for me, so I don't
>> care what you do.

qt.dan...@free.fr (3 March 2022 18:13) replied:
> Coming back after a long interruption (cancer, chemo etc.).

Good to have you back - I hope the treatment has helped.

> That kind of message is quite worrisome, particularly when made by
> Thiago.
>
> What happens after 6.2.4 ?

By then 6.3.0 shall be out and 6.3.x releases shall be the live version
of Qt.  The 6.2.x branch shall close - yet live on, behind closed doors,
as a commercial-only LTS branch, that'll only show up in public after a
year's delay (as 5.15.4 has just done, this LTS policy having been
adopted at 5.15) but this is of limited interest to the Free Software
community.  So 6.2.4 shall be the last free 6.2 release.

> (Currently assessing options before starting a new open source Qt
> project to help cancer patients.)

Good luck - and rest assured that Qt shall remain available, with
regular fresh releases, as ever,

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

Re: [Development] Heads-UP: Proposal for Qt 6.4 milestones & schedules

[Edward Welbourne]

Jani Heikkinen (3 February 2022 09:10) wrote:
> - Let's stop releasing the official alpha release and move to the beta
>   phase immediately after branching from 'dev'. Originally we had
>   'alpha' as a milestone after feature freeze where it is possible to
>   build Qt by yourself, but binaries are not yet available.

Prompted by reviewing a script change [0] to update an entry in
.cmake.conf, QT_REPO_MODULE_PRERELEASE_VERSION_SEGMENT, I guess we
should change dev's version tag from "alpha1" to simply "alpha", since
there shall never be any other alpha state to need a numeric suffix.

[0] https://codereview.qt-project.org/c/qt/qtqa/+/394498
TL;DR: Conan uses the prerelease tag as a segment in its naming of
generated packages, so we need to keep it up to date.

When 6.4 branches from dev, it'll initially thus be in alpha state; but
we'll change its tag to beta1 shortly thereafter; and mayhap later betas
before we branch 6.4.0 off it.  At that point, 6.4.0 keeps whatever beta
number it's reached, but 6.4 should revert to alpha, since it's 6.4.1's
alpha state, I suppose.  Subsequent release branches would switch to
beta1 as they branch off from 6.4, leaving 6.4 on alpha for the rest of
its days.

Does that match what you intend, Jani ?

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

Re: [Development] Updating x86 SIMD support in Qt

[Edward Welbourne]

On Wednesday, 19 January 2022 00:13:32 PST Lars Knoll wrote:
>> AVX is only used by a couple of classes in Qt Core and the drawhelper
>> in Qt Gui. Qt Gui already does runtime detection, so it would be only
>> about adding that to the methods in Qt Core.

Thiago Macieira (19 January 2022 17:48) replied:
> That's a misconception. AVX and especially AVX2 introduce a lot of
> codegen opportunities for the compilers, which they've been able to
> use for years.

Is the difference here:
* We have code that overtly conditions on the availability of CPU
  features (for example in the places Lars mentioned) vs
* The compiler can achieve some optimizations, on which we currently
  miss out, if we pass a relevant command-line option telling it to do
  so (or omit one telling it not to) ?

(Hoping you'll educate me if I'm being dense.)

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

Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

[Edward Welbourne]

On 1/18/22 15:10, Cristián Maureira-Fredes wrote:
>> Due to her contributions in qtbase and other modules [3],
>> I firmly believe she will manage to maintain it.

Jörg Bornemann (18 January 2022 15:15) replied
> +1
>
> I share your belief. :)

That makes two of us ;^>
+1

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

Re: [Development] Importing a module build in creator

[Edward Welbourne]

Arno Rehn (9 January 2022 15:59) wrote:
> I'm skipping building the tests by default and would like
> to build only a subset (the ones of the module I'm working on).
> QtCreator doesn't seem to support EXCLUDE_FROM_ALL tests at all, so I
> usually have to resort to the command line for that.

I suspect combining

  -DQT_BUILD_TESTS=ON
  -DQT_BUILD_TESTS_BY_DEFAULT=OFF

would help here.  CMake would know how to build the tests, but would
only do so on request, so you could tell ninja to build $submodule/test
(or indeed $subdirectory/test; see ninja -t targets for a full list) so
as to only build the tests you care about, or build tst_component_check
to (build and) run a specific test.

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

Re: [Development] Qt Compilation Speed

[Edward Welbourne]

Thiago Macieira (3 January 2022 15:10) wrote
[Referring back to unity builds.]
> Anyway, while this is great for reducing the number of build files,
> it's not a complete solution. It does point to one simple thing we
> should all do: includemoc. I think I've kept QtCore this way: all .cpp
> #include their headers' moc output. This not only good for build time,
> it enables some extra warnings by Clang when it sees the entire
> implementation of a given class.

Presumably we have a tool - automoc ? - that scans our source to
determine which headers need to be moc'd and which resulting moc output
isn't already #include-ed, so needs separate compilation.  We can surely
adapt that tool to (when a suitable option is passed) produce a warning
when such separate compilation is needed, advising us to do the #include
instead.

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

Re: [Development] Documentation of new Qt features in qtdoc

[Edward Welbourne]

On Mon, Nov 22, 2021 at 10:43:45AM +, Edward Welbourne wrote:
>>> Documenting it while it's fresh in your mind generally leads to a
>>> better description, after all,

Oswald Buddenhagen (22 November 2021 12:47) replied:
>> i'm not so sure about that. as seen by the quality of the [ChangeLog]
>> entries (in as far as present at all), many people have problems
>> switching their perspective to the different audience. doing that
>> with some temporal distance might actually help (though the "spatial"
>> distance of it being in a different repository certainly also helps).

The other virtue of putting the comments into a repository, rather than
commit messages, is that it opens up the option of revising them later.
So the initial description of the new feature in qtdoc may well be given
from a perspective too close to the work; but Kai's plan is to have it
in a shared repo where others (who might not have been involved in the
original review, to suggest improvements to a ChangeLog) are going to
edit the same document to add their own new feature descriptions, so
might see the deficiencies of existing entries in the file and either
improve them or poke the (by now long closed) review that added them to
ask what was meant.  So there's scope for improvement between when the
work is first described in the communal document and when that document
is finally published - just as in the wiki, but with the benefit of
past reviews on which to ask the questions and point out the problems
with particular edits to the file.

Shawn Rutledge (22 November 2021 15:56) added:
> ChangeLog entries from the git log may often be badly-worded or be
> written badly for the audience that’s going to read them, but I think
> we should still start from those, for the sake of completeness.

I think the aim here is to make them (and all scripts with delusions of
collecting them into a useful release story) redundant in any case.

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

Re: [Development] Documentation of new Qt features in qtdoc

[Edward Welbourne]

On Fri, Nov 19, 2021 at 03:11:57PM +, Kai Koehne wrote:
>>> Can we agree to document new features in Qt 6.3 and following
>>> released directly in qtdoc.git?

On 20 Nov 2021, at 01:12, Oswald Buddenhagen  wrote:
>> won't this cause conflict hell during release finalization? the
>> turnaround time for submitting patches is still quite unreasonable for
>> contended areas.
>>
>> it might work better if the update is done through a single
>> collectively edited change. with gerrit's online editing
>> functionality, this wouldn't even be much more cumbersome than editing
>> the wiki.  that would mean that jani would have post a link to a
>> change he started instead of a wiki page as he did so far.

Volker Hilsheimer (20 November 2021 14:18) wrote:
> I’m in favour of having a single place for the What’s New
> documentation, and the documentation is the right place, so +1 for
> that.
>
> But I share Ossi’s concern. Knowing how many of those changes happen
> late in the process, ending up with lots of them causing constant
> merge conflicts for everyone is going to suck.
>
> So, having a change that everyone can edit using gerrit's web UI is a
> good proposal. +1 to that as well.

All of which is entirely compatible with *also* encouraging folk to
document their new features in qtdoc as part of finishing up the work
itself, to avoid the rush and the scope for collisions in the One Great
Edit shortly before the release.  Documenting it while it's fresh in
your mind generally leads to a better description, after all,

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

Re: [Development] Jira and issues left "In Progress"

[Edward Welbourne]

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

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

Indeed.

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

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

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

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

Re: [Development] Formal voting procedure for Qt Project

[Edward Welbourne]

Lars Knoll (6 October 2021 15:33) wrote:
> * voting will be open for 7 days to give everybody enough time to react
> * The voting database will be deleted 2 weeks after voting ended

Suggested revision for the second:

* The voting database will be deleted 2 weeks after voting ended, unless
  the outcome is contested, in which case it shall be retained for as
  long as is needed to resolve disputes that can be answered by that
  database.

Note that if the outcome is contested for reasons not related to the
contents of the database (who voted, how many for which outcome) this
lets the two week schedule stand.

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

Re: [Development] Qbs development

[Edward Welbourne]

On 17 Sep 2021, at 10:51, Edward Welbourne  wrote:
>> The Maintainer has the authority to ask the admins to remove it.
>> Indeed, a button - available only to the Maintainer(s) of the module
>> - would be a nice improvement to the process but, for the present at
>> least, that "button" is implemented by e-mail to the Gerrit admins.

Volker Hilsheimer (17 September 2021 11:03) replied:
> I don’t think this process should be made easy.
>
> The approver that gave the -2 not yielding to the maintainer giving a
> +2 should be (and is, in my experience) such an exceptional situation
> that it deserves explicitly notifying the chief maintainer and gerrit
> admins. And perhaps it even requires this kind of conversation to be
> had on the mailing list, because the problem really is not that there
> is no button.

Fair point.
For reference, relevant e-mail addresses can be found here:
https://wiki.qt.io/Maintainers#CI_Maintainers

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

Re: [Development] Qbs development

[Edward Welbourne]

Chris Adams (17 September 2021 03:45) wrote:
> My point being: maybe the "maintainers can override a -2" is a
> "conceptual power" rather than a physical button in Gerrit, which
> still requires the approver to take away their own -2 in that
> circumstance?  (Obviously Gerrit admins can do it, but not every
> maintainer is a Gerrit admin.)

The Maintainer has the authority to ask the admins to remove it.
Indeed, a button - available only to the Maintainer(s) of the module -
would be a nice improvement to the process but, for the present at
least, that "button" is implemented by e-mail to the Gerrit admins.

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

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

[Edward Welbourne]

On 2021 Sep 13, at 20:58, Elvis Stansvik 
mailto:elvst...@gmail.com>> wrote:
>> Yes, URLs are vital to QML I guess, but are they *that* vital? The
>> bar should be quite high IMO. In the apps I've worked on, URLs and
>> URL handling is really not central at all.

IIUC, the present work has to do with the fact that things you might not
be thinking of as URLs really are - at least under the QML bonnet - such
as references to assets you ship with your QML application; the images,
textures and so on, that you might think of as "file-names" are
apparently handled as URLs.  After all, relative path resolution and URL
resolution are essentially similar.

Shawn Rutledge (14 September 2021 09:12) replied:
> We’re talking about potentially a lot of Image items though, Loaders,
> anything else that has a source url and gets used in a component which
> is instantiated in multiple contexts.  If it looks like a path, it’s
> actually a URL.  If it’s relative and Qt gets the base wrong, you need
> to worry about it.  When 6.2 LTS comes out, we’re guessing a lot of
> apps will be ported, and this will come up a lot.  It might cause some
> noise in Jira with the same bug report being written repeatedly: image
> doesn’t load, no idea why, it worked in Qt 5, blah blah.  Even if they
> understand, they will be unhappy having to write this boilerplate
> Qt.resolvedUrl() all over, and still complain that Qt 5 worked better.
> But if we make a syntactic improvement: before you had to write
> Qt.resolvedUrl() and now you write something simpler, maybe that will
> ease the pain a bit?

If someone has to edit all the same lines, does it really make that big
a difference that the edit is a one-character insert or wrapping a
string literal or url-or-string-valued expression in a function call ?
Particularly given a half-way decent refactoring tool ...

>> I don't see what's inherently wrong with a plain function like
>> Qt.resolvedUrl. It's very obvious - it says what it does on the tin.
>> Names are good that way.
>>
>> @ on the other hand would be completely opaque to a newcomer.

I must confess I find those persuasive points.
And Qt makes plenty of other sacrifices of brevity for clarity.

> Yep.  But Qt.anything() is also weird IMO: there’s no reason why the
> object containing this function should be called Qt.

Let me give you a reason - Qt is the implementor of the JS engine.
Specifically, the ECMA 262 spec's section on its *very* limited support
for URI-related functions [0] says (inter alia):

  The ECMAScript language itself does not provide any support for using
  URIs except for functions that encode and decode URIs as described in
  19.2.6.2, 19.2.6.3, 19.2.6.4 and 19.2.6.5

  NOTE Many implementations of ECMAScript provide additional
  functions and methods that manipulate web pages; these functions
  are beyond the scope of this standard.

As Qt's V4 engine is QML's implementation of ECMAScript, the resolver
function is an extension to the standard and should therefore be
accessed by an overtly implementation-specific namespace.

[0] https://tc39.es/ecma262/#sec-uri-handling-functions

> So maybe we need a function with a short name, not in a namespace?

A function without the Qt prefix is implicitly a member of the ES global
object and, as such, a "departure from" ES 262.  Code written apparently
in JavaScript but exercising extensions provided by a particular
implementation *should* make those extensions overt, if only so that
someone trying to reuse that code in real JavaScript knows what they're
going to have to adapt to the differences between implementations.

That said, I do think there might be value to talking to the ES 262
committee about adding resolveURI() to the suite of URI-related
functions that they provide, since it is surely one of the things that
all the "implementations of ECMAScript" do provide, one way or another.
All the same, until ES 262 includes it, please let's *not* add it to the
global object of V4, if only to avoid being stuck with a compatibility
problem when ES 262 does grow such a function.

> Or in some object that actually makes sense?  Or the suffix solution,
> because if we add units later, that will start to look like the same
> sort of thing even if it’s actually a bit different.

Having syntax incompatible with ECMA 262 is a matter to approach with
great care.  It will seem weird to those coming from JavaScript to write
UIs using QML, which I understand to be A Major Goal of QML.

> Or a function on the string: Image { source: “my
> icon.png”.resolvedUrl() }.

Again, extending the String type's prototype is a "departure from" ES
262 and I would counsel against it.  Anything that's an extension to the
base language *should* be packaged in a way that makes clear that it
*is* an extension specific to QML.

> But I’m just brainstorming without the implementation perspective in
> mind.

and I'm admittedly being rather conservative ;^>

I worked on a web browser for a 

Re: [Development] Qbs development

[Edward Welbourne]

Jason McDonald (14 September 2021 08:04) replied:
> I must refrain from commenting on the specific code review that is in
> dispute, as I'm not familiar with that module, but I would like to
> offer some more general remarks that I hope both you and Oswald will
> find helpful.

Likewise - and thank you for stepping in.

On Tue, 14 Sept 2021 at 07:01, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
>> I would like to raise an issue about Oswald Buddenhagen abusing his
>> maintainer rights. He is constantly blocking the merge of the
>> patchset which implements a new feature in Qbs [0].

Just for the sake of clarity, who *is* the Maintainer of QBS ?
Our wiki's [[Maintainers]] page only mentions Christian Kandeler as
maintainer of Qt Creator's integration with it.  I gather Ivan is a/the
principal developer of QBS in practice.  Is Ossi co-Maintainer, or are
you really talking about his Approver rights (which, IIUC, suffice to
make a +2 significant) ?

Before we resort to [0] QUIP 2's "extreme circumstances" provisions,
please let's do what we can to work our way through the steps that come
before that - for which we first need to settle the question of who *is*
The Maintainer (or who are The Maintainers, if more than one) of QBS.

[0] http://quips-qt-io.herokuapp.com/quip-0002.html

>> I started working on this almost a year ago and the issue was
>> approved for the first time in October 2020 (!). Since then, Oswald
>> popped up more and more random topics, demanding answers to all
>> possible questions about the overall architecture and blocking the
>> merge. While I highly appreciate his input, I don’t think it’s
>> productive to postpone a relatively small feature for almost a year
>> based on the assumption that it may not fit in the overall
>> architecture. I prefer to move forward in small step, collect
>> use-cases from actual users’ needs and see how this feature shows
>> itself.

> This paragraph worries me a little bit.  I will try to explain...
[snip]
> It has also been my experience that architectural errors are almost
> always vastly more difficult and costly to repair than coding errors.

Indeed, always important to keep an eye on architecture.

> For Qt, the backwards compatibility promises we make for most modules
> make that problem even worse, because certain types of architectural
> problem can only be corrected in a major release (which only occur
> once every 5 - 8 years).

Just for the sake of clarity, I should point out that QBS isn't a Qt
module, it's a build system, that TQtC started but later decided not to
continue with; members of the community have now adopted it.  It is thus
not part of the same release process as Qt at large, so not tied to the
same major version schedule, and it's not a library.  I don't know what
its existing compatibility promises are, but I can believe it may have
more flexibility than a Qt core library !

That's not to say that architectural considerations are any less crucial
as a result, only that perhaps there is more scope for fixing later and
thus for letting one of the principal contributors to the project
exercise his own judgement on how to move forward and what compromises
are acceptable between short-term progress and long-term structure.

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

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

[Edward Welbourne]

On 2021 Sep 9, at 17:32, Ulf Hermann  wrote:
>> As Qt.resolvedUrl() is quite a mouthful, there should be a shorthand
>> for it: the '@' operator.

Shawn Rutledge (13 September 2021 08:24) wrote:
> I’m never quite sure to what extent QML is “our” language, or to what
> extent the rule is “just do what Javascript does”, and then we have to
> defer to ECMA standards, and common web-development practices (which I
> don’t know very much about).  But is there any precedent for this “@“
> operator, for what it’s worth?

For reference, the ECMA 262 spec uses @@ internally as a prefix on the
names of some "well-known symbols" [0] and, in its specification of
URI-handling functions, it mentions @ as a reserved character in URIs
(within the string, though, not in the ECMAScript syntax).
So it has no special meaning in ES syntax.

[0] https://tc39.es/ecma262/#sec-well-known-symbols
[1] https://tc39.es/ecma262/#sec-uri-syntax-and-semantics

The only other uses of @ in the spec are to tag the twitter links of the
authors in the preamble.

In python, on the other hand, @ is used to introduce decorators:

  @decor
  def fun(x): return x

is roughly synonymous with

  def fun(x): return x
  fun = decor(fun)

In particular, this is the basis of @property declarations.

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

Re: [Development] Do we need version tags in released src packages?

[Edward Welbourne]

El divendres, 13 d’agost de 2021, a les 9:17:16 (CEST), Jani Heikkinen va 
escriure:
 We are planning to simplify our packaging and releasing scripts and
 one thing which would simplify our scripts is removal of version tag
 parsing for src (and example) packages. So the question is if we can
 remove version tag (-alpha, -beta1 etc) from our src and exmple  packages?

Albert Astals Cid (13 August 2021 09:26) replied:
>>> Does this mean that alpha/beta packages would have exactly the same
>>> filename as the final packages?

Jani Heikkinen (13 August 2021 11:06) replied:
> That was my proposal

I had asked:
>> and, more generally, what would the practical consequences of your
>> proposed change be ?  What would Qt-users (or indeed anyone aside from
>> our packaging team) see changed ?

> Only release packages would change; no changes to files in git
>
> * Standalone src packages in
>   https://download.qt.io/development_releases/qt/6.3/6.3.0-beta1/single/
>   would be qt-everywhere-src-6.3.0.zip instead of
>   qt-everywhere-src-6.3.0-beta1.zip. And main folder in the archive
>   wouldn't contain 'beta1' either
>
> * Submodule specific src packages in
>   https://download.qt.io/development_releases/qt/6.3/6.3.0-beta1/submodules/
>   would be qt-everywhere-src-6.3.0.zip instead of
>   qt-everywhere-src-6.3.0-beta1.zip. And main folder in the
>   archive wouldn't contain 'beta1' either
>
> There is no effect to installation done by online installer; in the
> installation there isn't version tag shown at all currently either.

So only leaf file-names change, the directories they're found in retain
their release-process tags.  The only problem I can see is that someone
who downloads the leaf file to a local place and comes back a few weeks
later to look at it won't know where in the release process it came out,
so might not know which beta to report a bug against, or might need to
download the same file a second time just because they can't remember
which release-tag they already had.  Not deal-breakers, I guess.

They might also mistakenly think what they've got is a final release, if
only because they're used to all but that having a release tag in them,
which might be a more serious issue.

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

Re: [Development] Do we need version tags in released src packages?

[Edward Welbourne]

El divendres, 13 d’agost de 2021, a les 9:17:16 (CEST), Jani Heikkinen va 
escriure:
>> We are planning to simplify our packaging and releasing scripts and one
>> thing which would simplify our scripts is removal of version tag parsing
>> for src (and example) packages. So the question is if we can remove version
>> tag (-alpha, -beta1 etc) from our src and exmple packages?

Albert Astals Cid (13 August 2021 09:26) replied:
> Does this mean that alpha/beta packages would have exactly the same filename 
> as
> the final packages?

and, more generally, what would the practical consequences of your
proposed change be ?  What would Qt-users (or indeed anyone aside from
our packaging team) see changed ?

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

Re: [Development] Version-controlling the SVGs of built-in icons

[Edward Welbourne]

On 18/06/2021 13:28, Edward Welbourne wrote:
>> The very fact that we're generating PNGs at different resolutions from
>> SVGs, when decent support for SVG would make that mostly redundant, says
>> we should be fixing our SVG support (and making it efficient enough to
>> make it practical to use it).
>>
>>   Eddy, who illustrates geometry essays with hand-written inline SVGs.

Giuseppe D'Angelo (18 June 2021 15:22) replied:
> Just to be The Grumpy One, this is:
>
> 1) an immense task given QtSVG is fundamentally unmaintained;

Indeed - step one in fixing our SVG support would be finding someone
willing (nay, enthusiastic) and able to take over maintaining QtSVG.

> 2) possibly an artistic anti-goal, given that artists want
>
> * use of full SVG profile and not just tiny/basic profile (=
>   implementation nightmare)
>
> * full control over SVG rendering, something hard to guarantee;
>
> * (related) not to rebuild+run the application after changing a SVG see
> if there's something wrong in Qt's rasterized results;
>
> * control over *lower* resolutions where one typically retouches the
>   pre-rasterized results;
>
> 3) a performance hit unless a SVG icon cache is put in place. Do we
>already a working, cross-platform one?

All of which comes under the heading of what I'd call "decent support
for SVG".  As an author who routinely uses SVGs for illustrations, I've
had occasion to try QtSVG out on diagrams I've written - and found the
results embarrassingly underwhelming.  SVGTiny isn't really much use.
Fortunately for me, web browsers generally do better.

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

Re: [Development] Version-controlling the SVGs of built-in icons

[Edward Welbourne]

Volker Hilsheimer (18 June 2021 11:19) wrote:
> The majority of time spent on QTBUG-38776 is chasing down the various
> SVGs from which it’s then trivial to generate PNGs in different
> resolutions.

The very fact that we're generating PNGs at different resolutions from
SVGs, when decent support for SVG would make that mostly redundant, says
we should be fixing our SVG support (and making it efficient enough to
make it practical to use it).

Eddy, who illustrates geometry essays with hand-written inline SVGs.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Edward Welbourne]

Leaving aside the question of what to test when integrating changes to
each given module, I pause to consider how we could sensibly implement
the necessary information for telling automated systems to do that
testing.  That may place constraints on what we can do, that might bound
the discussion of what we want to do / what it makes sense to do.

Presumably we could add a new stanza to dependencies.yaml, a top level
peer of the dependencies stanza (which I'd rather call prerequisites,
but I guess it's too late for that), named dependants, with suitable
meta-data to say what version of it to test against and what to test -
build, test, example - in the dependant, as a prerequisite of accepting
a change in the upstream module in Coin.

PreCheck shall, naturally, test everything that integration shall test.
An option to consider is to have PreCheck perform a broader set of tests
of dependant modules - e.g. the new stanza could have a required:
option, as in the dependencies stanza, whose false means Coin doesn't
reject based on the dependant failing, where PreCheck maybe would.
Whether Coin runs those tests (reporting, but not failing on, any
failures) is a choice we can make based on practicalities like load.

The committer of the new version of the upstream module would then be
able to get changes to the downstream through integration, that prepare
it for the upstream change, and update the upstream commit that would
have broken the downstream's tests otherwise, to show the new sha1 of
the downstream module as the basis for the dependant-testing.

Relevant module owners can then haggle over how far upstream each module
gets protected by being identified as dependant.  That'll be a balancing
act between the upstream not wanting to be slowed too much in Coin by
the building and testing of dependants, vs the dependants wanting that
protection.  That haggling would surely happen in Gerrit changes to the
upstream's dependencies.yaml file, which seems like a suitable enough
forum in which to, at least, open such a discussion.

Which is all just a sketch, but hopefully gives some shape to what's
practically implementable.  Can anyone spot any obvious holes in this
approach ?  Or other constraints it'd impose on what we can do ?

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

Re: [Development] Moving IRC from Freenode to Libera.Chat, voting thread

[Edward Welbourne]

Giuseppe D'Angelo (22 May 2021 03:06) wrote:
> As detailed in the other thread, I'd like to gather lazy consensus for
> moving the official IRC presence from Freenode to Libera.Chat.

+1

> == VOTING SYSTEM ==
>
> Lazy consensus (simple majority), see QUIP-2.

Specifically:
http://quips-qt-io.herokuapp.com/quip-0002.html#decision-making-process
although this contains no provision for voting, only consensus-forming.
I believe we have a fairly solid consensus around this, but let's see if
anyone has any objections,

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

Re: [Development] Changes to Freenode's IRC

[Edward Welbourne]

On 20/05/2021 13:47, Alejandro Exojo wrote:
>> Also, I don't understand how not having to register can be a
>> requirement at all, given that one needs to register, sometimes
>> multiple times, to use some of the other official channels. E.g. to
>> participate in the mailing list I of course need to subscribe to it,
>> and to get an email account at all I would either need to register
>> with some provider or use a work email address (or self-host or...).

There is a world of difference between having to subscribe with a
service provide determined by the forum (freenode, the list-server) and
having to have an e-mail account, which is decoupled from the choice of
forum.  Those who value privacy highly do have the option of getting
their e-mail service from a provider that assures privacy - in extremis
by running their own mail server - while those less concerned about it
can just use gmail.

Users of the mailing list have no choice about the mailing-list hosting
(unless they can persuade the rest of us to change it) but have
extensive choice over who hosts their e-mail.  In particular, some
e-mail service providers support features that let one user have many
e-mail addresses (e.g. the +suffix notation some use) which can make it
easier to sort in-coming mail (by which address was used).

Giuseppe D'Angelo (20 May 2021 14:18) replied
> Or self-host, indeed. But nothing apart from your email is needed, and
> that email is NEVER used for any commercial or marketing or research
> purpose. Which is the same requirement for the mailing lists. It might
> not be the case for some 3rd party services.

Indeed - especially when their business model is to sell (data about)
their users to anyone who'll pay them for it.

>> If at all, not requiring registration makes me more concerned about
>> spam, trolling, harassment, etc.

That is fair, though there are mechanisms for combating it.  There is a
need for some level of balance in how much information users must give
at registration; but I think the real registration concern folk have is
not the information the Qt project needs to ensure respectful discourse
in our fora, so much as the chat-service providers tending to want all
manner of information about users, for all manner of purposes, that
won't all align with community priorities.

> Which you can easily ignore (see user mode +g, +R). None of this has
> been a major problem on Freenode so far.

Setting modes in IRC is something experienced users may take for
granted, but those who are less familiar with IRC are unlikely to know
about.  Hence this defence fails to get over Andy's objection that
bright young minds born this century aren't familiar with IRC: they
probably don't know about the user modes of this antiquated system.

The design of IRC dates back to when a significant proportion of the
participants in a discussion might be connecting to the internet via
rather precarious (metaphorical) pieces of salty string; consequently,
it did one thing robustly and didn't try to do much more.  Archiving and
searching can be done by other software after all.

Decades have passed and now most participants in most online discussions
have high-bandwidth permanent connections, making a service that
integrates more functionality advantageous; and many such services are
now available, with no single one standing out as a compelling choice
over all the others.  That leaves the world of chat fragmented; and many
of the chat services have a vested (if perhaps misguided) interest in
not being interoperable with their competitors; they want their captive
audiences.  For the user, it is tiresome to need several chat clients,
so we tend to get segregated into silos - each of us would rather limit
how many chat clients we need to run (preferably to one), but the
communities we want to participate in may be spread across different
services, with incompatible clients.  Which has left many projects
facing the same difficulty we do today: how do we chose one ?

The virtue of a service running open-source software is that - as long
as the service provider can be trusted to be running the published
version - it's a lot easier to be confident about the service not using
data about users in ways we don't approve of.  Likewise, having the
server under the community's control improves our capacity for trust -
although an allied and friendly community's control, such as KDE, can
work just as well.  Our ability to trust the service is more important
than the question of whether it requires registration, I think.

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