Re: [Development] Using string literals in autotests

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

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

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

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

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 -

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

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

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

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

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

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

Re: [Development] Buddy group to help new contributors

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia): >>>> Would it make a huge difference if we didn’t require perl (and IIRC >>>> we only need it for the init-repository script)? On Thu, Jan 04, 2024 at 11:35:45AM +0000, Edward Welbourne via Development wrote:

Re: [Development] Buddy group to help new contributors

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

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

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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 ?

Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers

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

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

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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 >

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

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

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

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

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

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

Re: [Development] Nominating Ahmad Samir for approver

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

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

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

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

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

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

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

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

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

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

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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

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

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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

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

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

Re: [Development] Nominating Tatiana Borisova as approver

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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]

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

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

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

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

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

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,

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

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

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

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

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

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

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

forms >>>> (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 Welbo

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

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.

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

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

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

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

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

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

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

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

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

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

Re: [Development] Nominating Mårten Nordheim and Timur Pocheptsov as new co-maintainers of Qt WebSocket

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

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

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

Re: [Development] Renaming quint128

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

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

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

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

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.

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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

Re: [Development] Duplicated test data tags

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

Re: [Development] Duplicated test data tags

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

Re: [Development] Duplicated test data tags

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

[Development] Duplicated test data tags

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"

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

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*