hi,
I put this here first and not bug tracker, because not sure if this is just a workflow only I use and maybe not event meant to be used like this..

so, how I have set up my workspace in Krita is that I removed most of the things in there by default, and just kept the things I really need while painting.
dockers are floating, and with [TAB] I hide/unhide them.
with [SHIFT]-[TAB] I toggle canvas-only mode, and I have set it to hide everything else except dockers.
so basicly, I paint mostly in canvas-only mode and hide/unhide the dockers...
but sometimes I need something from the menus or toolbar, then I hit shift-tab to bring them back.

so in canvas-only it looks more or less like this... toolbox is here mostly for showing the problem I have:


and when I exit canvas only, this happens:


so as you see, there is a slight overlapping going on

now if I fix this overlap by dragging the toolbox down, then when I hit canvas-only again I have to manually drag it back up...
there seems to be some sort of memory going on, sometimes in normal-mode if I hide the floaters and then unhide them they pop into different position.. but it doesn't work in canvas-only-mode.

sometimes with all this toggling going on I end up with this:


so it seems to forget that I had toolbar there.. the reason why I came back from canvas-only-mode is now gone, and I have to manually get it from menu. there has been times also the whole menu disappeared. that I thin was impossible to get back without restart.

soooo.. questions..
am I only one working like this?
is this wrong way of using Krita..?
would it be possible to have Krita remembering the positioning of floating dockers in canvas-only and normal-mode separately... ?
or would that mess up other peoples workflows?

also, why there is scrollbar on the preset docker, when there is nothing to scroll?

.b

"would it be possible to have Krita remembering the positioning of floating dockers in canvas-only and normal-mode separately... ?"

No. The way dockers work, and restoring the state of dockers work is dependent on the our development platform, Qt. Coming up with a custom way for handling panels is something we've tried three times before, and it just is too much work. It would not leave time for other development -- so, no.

"also, why there is scrollbar on the preset docker, when there is nothing to scroll?"

Same reason. It's the way Qt's listview widget works with fixed and non-fixed width, heights and icon sizes.

aww that's a real shame..

I thought it could be done since I saw there already was some memory for the positionings...

I hope when you have the scripting added, it also reaches UI, so you could perhaps do own dockers and change the already present ones.
Blender has this done very nicely. almost everything is python scriptable.
and I just love adjusting my interfaces


.b