https://bugs.kde.org/show_bug.cgi?id=515889
--- Comment #22 from john <[email protected]> --- Created attachment 196876 --> https://bugs.kde.org/attachment.cgi?id=196876&action=edit Proposed Qt 6 startup mitigation: initialize session D-Bus before temporary applications (Krita 6.0.4) Tested Krita-side mitigation: initialize the session bus before temporary startup applications Following the root-cause analysis in comment 21, we tested an alternative mitigation that does not set AT_SPI_BUS_ADDRESS or disable accessibility: initialize QDBusConnection::sessionBus() at main() entry, before Krita creates any temporary Q(Core/Gui)Application. The attached patch conditionally includes QDBusConnection and initializes the connection for Qt 6 builds with HAVE_DBUS. It also explicitly links the executable to Qt6::DBus under the same feature guard. It is based on Krita v6.0.4, commit e7e52a72ed37ecaf9ffaa2fab836b7c2f5539d1f, and changes only krita/main.cc and krita/CMakeLists.txt. Rationale: Qt 6.11.2's connection manager enables dispatch immediately when the first session connection is created without a current qApp. Creating it before the temporary startup applications avoids binding delayed dispatch activation to an application that never runs its event loop. This is a proposed Krita-side mitigation; the underlying Qt lifetime issue still warrants investigation. Test environment: - Garuda Linux (Arch-based), KDE Plasma 6.7.5 / KWin Wayland, with Krita using xcb/XWayland - Krita 6.0.4, Qt 6.11.2 - Patched executable compiled from the v6.0.4 source and tested with installed Krita 6.0.4 libraries, plugins, and resources Standalone regression results, using incoming calls from a separate Python/Gio process: - Unpatched temporary QGuiApplication + QWindow sequence: Peer.Ping replies; Introspect and AboutToShow time out at 1 second. - No temporary QWindow: all calls reply. - Accessibility override scoped to the probe: all calls reply. - Early session-bus initialization: all calls reply. - Early initialization with QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1: all calls reply; QAccessible::isActive() is true and the a11y bus connection is active, with AT_SPI_BUS_ADDRESS unset. Real Krita verification: - Started the patched executable with AT_SPI_BUS_ADDRESS unset and accessibility forced on for that test process. - /MenuBar/2 GetLayout returned File, Edit, View, and the other actual menus; AboutToShow replied. - Verified that the same Krita process had a live connection to the AT-SPI accessibility bus. - The affected user confirmed the global menu was visible and clicking File opened the menu. A companion regression archive will be attached with a standalone CMake/Qt reproducer, an asserting Python/Gio driver, and build/run instructions. It is not integrated into Krita's CTest suite. Qt 5 and other Qt 6 versions were not tested for this patch. The patch and test harness were prepared with Codex and verified locally as described above. Would this early session-bus initialization be an acceptable Krita-side mitigation, or would you prefer a scoped workaround in the OpenGL probe while the Qt issue is addressed? -- You are receiving this mail because: You are watching all bug changes.
