Hello, everyone.
Is it possible for krita’s canvas to not be automatically displaced?
As shown, when the panel is fixed to the edge of the software and stays displayed, the canvas is in one position
When the tab key is pressed, all fixed panels are hidden, but at this point the canvas undergoes a very large positional shift and runs directly into the left area of the software.
This feature creates a huge disturbance in the drawing process. I would like to make it so that the canvas does not shift as the panels are hidden.
I know that panels can avoid this problem if they are hovered, but hovered panels don’t get too close to the edge of the software or they will automatically tuck into the edge area. And the recognition of hovering in the edge area is too sensitive, too wide and too big, slightly moving the panel to the edge will trigger the recognition, can you at the same time turn down this recognition area a bit?
Thank you developer.
Hi, this is a good point about the TAB key, this is really distracting 
As for the issue with the dockers, you can suppress the docking behavior with CTRL key. It’s important you press it down before clicking the mouse or putting the pen down (manual link).
Dockers can be prevented from docking by pressing the Ctrl key before starting to drag the docker.
So this seemed relatively simple, and I almost managed to implement it, but there are still some bugs to figure out.
It’s tricky because there are quite a few interactions and it’s easy to miss some of them. For example, Krita can use windowed or tabbed views, the main window can be maximized or fullscreen, the canvas may be panned or in “Fit to Size” mode, the list goes on and on.
oh，this ctrl is a perfect way ！it works！
thank you man!really need this can be soon fixed，thanks！
OK, I managed to do this. It’s not perfect, in some cases the canvas jumps around a bit unexpectedly, but my hope is that it will work well enough for “the typical use case”. I still need to verify it on Linux. Below is a demo for Windows 11:
I noticed that switching to fullscreen is really messy on Windows (the transition is not smooth and takes a fraction of a second), and it’s better to either:
- work in full screen mode,
- disable the option to hide the window’s title bar (this disables the auto-fullscreen) and (optionally) maximize the window.
In both these cases the window will not change its full screen state, and the transition will be very smooth.
EDIT: Added the PR:
I have a dejavu feeling. I think something like this was already implemented. But maybe not merged¿? I remember discussing it with the author.
Here:
@KnowZero was the author. Maybe you both can get to an optimal solution.
From what I remember, the issues I had was that sometimes under rare occasions on some platforms it did random jumps when using the pan tool, and insuring that when someone happens to have their stylus down on it doesn’t make streaks
I think I managed to fix some of it but was adding the config for more control and at the time the config got redone, but never got around to updating that part
Hi @KnowZero , I’m not sure if that was the same bug, but @Deif_Lou fixed an issue where the canvas would jump vertically after switching the view and panning.
Do you plan on continuing the work on your patch?
The change I made is really simple, so I think we could merge it as something that’s already done and tested. If you recall these conditions/platforms where there was bad behavior, I could check if the same problem doesn’t happen again.
extremely grateful YRH，thank you！
Yes my friend, I have also noticed that krita has an occasional unpredictable jitter when using the panning tool. It seems to really happen when zooming the canvas. I’d like to reproduce the problem sometime to see exactly what’s going on.
Currently, I am too busy to work on anything :(, at least for the next few months.
If you want to merge your version go ahead, it isn’t like the flickering fixes and the like can’t be added later (as long as the devs are okay with that), sometimes feature creep insures nothing gets done
The jump issue was something that happened randomly, and I am not sure if it was fixed or not by fixes since then as I have not tested it for quite a while as a lot has changed in the code base. Overall, if there is an issue it could be found while people are alpha testing or beta testing
The only thing you should test is what happens when someone is holding down a brush on the canvas and presses tab to see if that comes out okay or causes the brush to streak
Got it, thanks, and I agree. It’s better to add changes incrementally if they are already providing some value. Who knows what happens tomorrow.
Thanks for the suggestion, I’ll check that!
UPDATE:
Hi. My simplistic patch has been merged, meaning it should become a part of the next major release (5.3). However, please note some limitations:
- For an optimal experience, you should either work in fullscreen mode, or disable the window title bar hiding in
Settings > Canvas-only. This makes the window transition much smoother.
- If the canvas is zoomed out (small) and moved close to the edge of the window, the document (the painting) can still jump around.
- If you keep some of the UI visible in Canvas Only mode (after pressing TAB) and resize your dockers (consequently changing the size of the canvas view), the document will also jump when going back to normal mode.
- If you use multiple views that are not maximized, then this feature (trying to maintain the fixed canvas position) will be disabled and the behavior will be just like in current 5.2.2 version.
OK, so, as you can see, that’s a pretty big errata. However, the hope is that it should work reasonably well most of the time. Doing this properly in all cases turned out to be challenging and we didn’t want to make the implementation overly complex. Lastly, there may be opportunities in the future to make it more robust.
Alright, that’s all, thank you for your attention. Over and out 
This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.