Bug 506327

Summary: Floating toolbars do not render, rendering as a solid black box
Product: [Applications] krita Reporter: Kath <krazykath>
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: cromachina, halla, red.flames.1337
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

Description Kath 2025-06-28 22:00:46 UTC
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)
Comment 1 Halla Rempt 2025-07-08 08:55:29 UTC
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...
Comment 2 Kath 2025-07-08 18:42:31 UTC
This does also happen in the appimage, yes
Comment 3 Halla Rempt 2025-07-10 09:32:06 UTC
Hm.... And if you disable canvas acceleration in Krita's Display settings?
Comment 4 Kath 2025-07-10 21:39:12 UTC
Still happens with canvas acceleration disabled
Comment 5 cromachina 2025-10-23 15:28:01 UTC
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
Comment 6 cromachina 2025-11-13 02:20:53 UTC
I tested again on 5.3.0-prealpha (git f6a483e) and it seems to be resolved there.
Comment 7 red.flames.1337@googlemail.com 2026-02-04 23:20:39 UTC
Can confirm this bug still exists in 5.2.15 sadly

For a while I had been hoping the fix for this would get merged into 5.2 but it seems that won't happen. This bug got fixed in MR 2408 as best as I can tell (...I haven't tested any nightly builds or anything, I'm just on stable...)

https://invent.kde.org/graphics/krita/-/merge_requests/2408

...which happened back around May of 2025.

Searching the commits I can see the commit from the MR in master but not in any 5.2 branch or even in release/5.3.0-prealpha
https://invent.kde.org/graphics/krita/-/commits/master?ref_type=heads&search=fix+floating+toolbars

Personally I do always have the "Brushes and Stuff" toolbar floating, I have Krita in fullscreen with the menu bar and I kinda just float it over the top right of the window where not much is going on anyways.

I've been trying to write a python script to fix the toolbar but with no luck so far (like three times now I've been convinced that that things I did to the pyQt5 QToolBar object or with Krita instance actions were making it visible again, but nope.)

Best I've come up with is going into "Settings > Configure Toolbars..." and just... dragging the lowest item on the right side, which doesn't actually change any of the order there, but enables the "Apply" button that is otherwise disabled.
At that point I might as well go "Settings > Toolbars Shown > [...]" and toggle that toolbar off once and on again. 

Just kind of mildly annoying to have to do this at every launch :P

...Actually, after some hours I sort of _do_ have it fixable with scripting.


> from krita import *
> 
> app = Krita.instance() 
> currWin = app.activeWindow()
> qWin = currWin.qwindow()
> 
> for a in app.actions():
>   if "hide brushes and stuff" in a.text().lower():
>     a.trigger()
>        
> for a in app.actions():
>   if "show brushes and stuff" in a.text().lower():
>     a.trigger()
> 
> # optional stuff, I like making it undockable, not sure if any of the other settings are important here
> for tb in qWin.findChildren(QToolBar, "BrushesAndStuff"):
>   tb.setWindowFlags(QtCore.Qt.Tool | QtCore.Qt.FramelessWindowHint)
>   tb.setAllowedAreas(QtCore.Qt.NoToolBarArea)
>   tb.move(-1883, 1440)
>   tb.adjustSize()

Apologies if that looks mega scuffed, couldn't figure out of there's Markdown here for code blocks. But just throw that at the "Tools > Scripts > Scripter" and pray, maybe save it as a *.py file, set it as a "Tools > Scripts > Ten Scripts" shortcut and immediately hit Ctrl+Shift+1 after starting Krita. That's what's currently finally making this easier for me lol.
Comment 8 Halla Rempt 2026-02-05 08:49:30 UTC
I guess that fix didn't get backported to the 5.2 branch. We're releasing the first beta of 5.3 (and 6.0) today, so it's unlikely we'll make another 5.2 release. But since the fix is in a release, we can close the report.

I'm really sorry for this oversight and all the effort you had to go to find a workaround.