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

t; > 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 l

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

t;, "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 i

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

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

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

Re: [Development] Duplicated test data tags

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 &

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*

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

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?

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

Re: [Development] qsizetype

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

Re: [Development] qsizetype

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,

Re: [Development] results of July flaky tests fixing

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.

Re: [Development] How to do deprecation

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

Re: [Development] Code Review of Build File Changes

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

Re: [Development] Fw: How to do deprecation

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

Re: [Development] How to do deprecation

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

[Development] How to do deprecation

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

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

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.

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

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

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

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

Re: [Development] Chief Maintainer election

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 >

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

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

Re: [Development] QtCS2022 - Sessions and Timeslots

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

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

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

Re: [Development] Nominating Ievgenii Meshcheriakov for approver

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] Cherry-picks lost and forgotten

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

Re: [Development] 6.2.4 problems ?

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

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

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

Re: [Development] Updating x86 SIMD support in Qt

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)

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

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.

Re: [Development] Importing a module build in creator

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

Re: [Development] Qt Compilation Speed

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 >

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

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 q

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

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

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

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

Re: [Development] Formal voting procedure for Qt Project

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

Re: [Development] Qbs development

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 >

Re: [Development] Qbs development

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

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

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

Re: [Development] Qbs development

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

Re: [Development] Changes to Freenode's IRC

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

  1   2   3   4   5   6   >