So we have three different things to do: * Remove QWindow::requestActivate() in autotests where it's (a) redundant, and the removal (b) fixes flakiness, and (c) without causing grief (ongoing, triggered by flakiness).
* Hunt down and fix the data race in our XCB implementation => https://bugreports.qt.io/browse/QTBUG-139133 * Add a test helper as proposed by @Giuseppe D'Angelo<mailto:giuseppe.dang...@kdab.com> and @Shawn Rutledge<mailto:shawn.rutle...@qt.io> => https://bugreports.qt.io/browse/QTBUG-139134 Confidential ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Shawn Rutledge via Development <development@qt-project.org> Sent: Wednesday, 13 August 2025 16:19 To: Qt Development <development@qt-project.org> Subject: Re: [Development] Calling QWindow::requestActivate after QWindow::show and before QTest::qWaitForWindowActive > On Aug 13, 2025, at 11:50, Giuseppe D'Angelo via Development > <development@qt-project.org> wrote: > > Il 13/08/25 11:40, Tor Arne Vestbø ha scritto: >>> On 13 Aug 2025, at 11:30, Giuseppe D'Angelo via >>> Development<development@qt-project.org> wrote: >>> >>> More on topic: if ultimately it is platform specific whether show() alone >>> is sufficient or one needs show()+requestAcivate() (+ QVERIFY), couldn't >>> this combination be packaged in some QtTest helper function, so that people >>> can simply call that function and it'll always do the right >> Yes. Though we should stive to use it only when the test actually requires >> focus. Running tests locally with windows that steal focus unnecessarily is >> a bit annoying. Of course these things are typically cargo-culled, which is >> how we probably ended up with the current state of every test requesting >> activation explicitly after show. > > A packaged function would actually allow for an easier way out of the cargo > cult, as one could centrally switch its implementation from > show()+requestActivate() to show() alone and start monitor exactly what > breaks after that, then investigate why. Exactly. Succinct tests that use standardized reusable functions are easier to maintain. (Or if they all break at once in the future, at least we have one place to fix the problem.) -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development