As you can see, it’s not full-screen, as I leave some space for chat and videos. There’s four rows of brushes, and everything is pretty compacted.
“Four?” you might ask. “There’s only three in the image”. That is quite literally the problem, and it only gets worse & worse over time.
The rightmost docker, usually upon either drawing on the canvas and/or (?) picking a brush, will expand. And it doesn’t stop. During that time, I can’t resize the docker to be smaller, leaving me with less & less screen space until it just magically can be resized again & is back to work. This happens extremely inconsistently & randomly. It was never a thing before, so I’d assume maybe an update broke something specifically on my end, but how do I even track this?..
Anyway, the usual:
Krita info: Krita 6.1.0 prealpha git fd2e3f5 AppImage Sys info: Artix 7.1.6 / KDE Plasma 6.7.4 / Frameworks 6.28.0 / Qt 6.11.1
Only notes so far:
This seems to happen mostly with brushes from bundles, and not my custom .kpp’s
The behavior resets itself without any of my input (it seems)
This seems to be most frequently replicated if I use a Pen/Touch input, and then specifically click a brush icon with my mouse
Fast addition: this is the widest I’ve gotten so far, before it just resets itself to being interactable again. Could this be just, some weird mouse-pen-touch input wizardry on 6.1??
Might seem crazy tiny, but after working in “small” UI on CSP’s iPad version of their desktop UI, this is my normal scale for touch operations ;_; any bigger feels extremely cramped.
Maybe something weird is happening that it decides you were dragging the docker resize handle, and then it cancels itself? Even though it’s the right-most dockers that resize, it could be the handle along the right side of the canvas being dragged, since the Brush Presets docker doesn’t seem prioritized to expand.
Is this Wayland or Qt6 specific? Or does it happen with XWayland or Qt5?
So far only tried on Krita 6 Qt6 + Wayland. I don’t really have a way to check natively under xorg, but I’ll see if the Qt version changes anything & report back!
On Krita 5.3.3, this also happens, but there’s also some other odd UI things going on that are much more minor & irrelevant to this ( I think. I’d have to triple-check all the plugins, but I mainly use Next builds over the stable ver. ). I have to assume that it’s wayland’s input then, as I’ve never had this much of a problem on my non-touch PC ( which, curiously, is also running KDE under wayland – I just don’t have touch input ). But also, the non-touch PC does not use a MPP Pen, but a display tablet, so I imagine this also might play a role?
I’ll see if I can catch anything else related to the touch-pen-mouse combo.
Did some more tries on the laptop today, and it’s really hard to narrow down the reason for this occurring… I’m quite sure this is just pen/pen hover + mouse, since when I tried touch, nothing much happened?.. Man this is complicated.
I’ll do some more test runs today/tomorrow on my PC too, and see how that performs. I’m a lil busy when it comes to my PC because I’m moving it to my houses workshop :“”" ) So sorry if new info comes in a bit later than that, I’m just in home renovation hell.
