| Summary: | Floating toolbars do not render, rendering as a solid black box | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Kath <krazykath> |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | cromachina, halla |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.9 | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Example of the floating toolbar rendering as a black box | ||
Does this also happen with the appimage? But it hardly can be a bug in Krita, since Krita doesn't draw toolbars, that's Qt. It's more likely a bug in Qt, an issue in the graphics driver or the window manager... This does also happen in the appimage, yes Hm.... And if you disable canvas acceleration in Krita's Display settings? Still happens with canvas acceleration disabled I encountered this as well, and it seems like the toolbar stops getting paint events and gets loaded into a weird state. You can still click on the buttons and get tooltips, however. I think this bug might occur because toolbars are in a strange half-way state when opening Krita, that is, you can see your custom toolbar docked at the top of the window in the home screen, and then when you open a document, the toolbar needs to be undocked and sent to its last floating position. If you undock the custom toolbar before opening a document, the buttons appear again, however, the move handles are gone and the toolbar cannot be moved again. If you undock and redock the custom toolbar before opening a document, the custom toolbar will get undocked to the last floating position after opening a document, and the rendering and move handles are broken again. My guess is that the "undock to last position" operation may be getting some erroneous parameters, or at least that's the first place I would look, because that's when the errors seem to start. Regardless, I think a better solution would be to make it so toolbars are "dockers" instead, that way you can dock a "toolbar" anywhere, not just on the absolute edges of the window (which is why users end up making toolbars floating in the first place, because they can't dock them where they want to). KRITA VERSION 5.2.13 SOFTWARE/OS VERSIONS Operating System: NixOS 25.11 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.17.1-zen1 (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 64 GiB of RAM (62.7 GiB usable) Graphics Processor: AMD Radeon RX 7900 XTX I tested again on 5.3.0-prealpha (git f6a483e) and it seems to be resolved there. |
Created attachment 182770 [details] Example of the floating toolbar rendering as a black box SUMMARY Floating toolbars do not render on program open, appearing as a solid black box. Despite this the buttons of the toolbar are fully functional STEPS TO REPRODUCE 1. On an empty document, move the File toolbar so it is floating over the canvas 2. Close Krita 3. Re-open Krita 4. Open a new document OBSERVED RESULT Where the file toolbar should be, is a solid black box EXPECTED RESULT The toolbar is visible and rendered correctly SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.14.11-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × Intel® Core™ i9-9900K CPU @ 3.60GHz Memory: 32 GiB of RAM (31.1 GiB usable) Graphics Processor: AMD Radeon RX 6800 ADDITIONAL INFORMATION If you cannot drag a toolbar as the handles are missing, configure and apply a change to any existing toolbar to make them show (Reported in 506326). This co-incidentally also "fixes" the black box toolbars and makes them appear as expected. Krita version: 5.2.9 This happens regardless of which toolbar may be floating (I first experienced this with the Edit toolbar)