Hi, very simple question please: I like to hide the UI when I’m drawing. I pushed ‘tab’ like in Sketchbook pro and luckily all the UI hid, which is great, but my canvas keeps jumping to the top left. How do I make it stay still like all the other drawing apps please?
What exactly do you mean by that? The canvas should fill your whole screen in canvas only mode (when you pressed tab). Is this not the case?
I want it to work like other drawing apps: Artflow, Sketchbook, etc…
When you push tab the canvas should not move. Should not pan or zoom - all that should happen is the UI should disappear. Currently it pans and zooms with whatever setting is the default 
So issue is basically that the canvas inputs still work and that it doesn’t stay in centered “fit screen” zoom mode all the time?
The reason the canvas seems to jump is that it moves to the space that was formerly occupied by the sidebars and menu bars. They are not floating in Krita, this is why the canvas window (or the view) repositions itself when the other UI elements disappear.
So there is no way to make it stop except maybe not having any UI on the top and left side of the screen, which is almost impossible.
Oh wow. ok thank you! I guess poor UX is just the downside of using free software.
IIRC this was on @AlansArtLog’s list of things to maybe look at one day if there’s time. Bugs me, too.
At least you didn’t waste any money then. The behavior is simply the default of Qt, the UI framework Krita uses.
I also hope that this will be fixed one day, the truth is it is a bit annoying.
Me too 
Also, when I enter Fullscreen Mode (View) and then leave the fullscreen mode, the toolbars, menu bars and sidebars don’t remember the previous positions/states and everything gets ‘smashed’ into the middle The only solution is to have a saved workspace and then click it to restore all the interface back.
The offset is the same on both though. Zoom is also the same.
These seems doable to calculate the offset.
1 Like
Personally, while I like the current behavior, but an additional press of the 2 key, which is now not that far from the Tab key, would do the job for me, but surely the desired behavior could be made selectable.
Michelist
One of the advantages is that we can improve it. May be we should report the bug about this behaviour.
It’s been reported already: 392225 – Preserve relative canvas position when switching from/into Canvas Only mode
4 Likes
Thanks for linking the issue.
The offset of the image is relative to the canvas widget I guess, so the image moves relative to the window or screen but not relative to the canvas widget.
So I think this should be implemented only when switching to/from canvas only mode, but also fullscreen mode or when the dockers are hidden.
Maybe it should be implemented whenever the position of the canvas changes. Although there are cases I don’t know if that would be usefull. For example when hiding the toolbars or when changing the size of the dockers on top or left of the canvas.
What do you think?
I can’t, off the top of my head, think of a situation where you would want the canvas’ onscreen position to move when adjusting the UI. So IMO it should be implemented in all cases if possible. If that’s difficult, then to me the most important thing would be to implement this for going to and from canvas only mode. All the rest is gravy, since in my workflow at least, I don’t adjust the UI that often.
That said, it does kind of feel like the “proper” solution to this would be to rework how the canvas position is defined, so it is relative to the screen, not to the widget. I don’t know how realistic that goal is.
Edit: I spoke too soon… I can actually imagine such a situation.
When changing the window size, I would want the canvas to stay fixed on-screen. But when moving the window, I would want the canvas to move with the window. Maybe there are other cases, and perhaps the best idea would be to just list the most critical actions that should not trigger a canvas move, and change the behaviour for those. Like @Deif_Lou’s list, pretty much.
2 Likes
Yes please, try to analyze the issue and the corner cases, and I’ll try to implement it after it gets fine tuned.
4 Likes
Two fixes would be helpful:
-
Krita should have a keystroke that centres the canvas and sets the zoom to 100%. Every other art app that I’ve seen has this. It’s fundamental.
-
Why oh why does Krita open a canvas zoomed to 103%? What’s wrong with 100%, the actual size of the work?
Sorry, I’ve been very busy and will probably still be for a few months. Am still down to try to fix this if it hasn’t been when I’m able to.
I’ve made some tests. It kind of works, but when going to/from fullscreen there is some flickering that I couldn’t remove for much that I tried (messing with the events and so on). That made me think that maybe it is a qt issue. It’s like when going fullscreen the window is drawn with the old contents (only a portion with the smaller window surface) as if it where at window manager level and inmediatelly it is drawn correctly with the resized widgets. Something weird. I guess the next step is to study the qt code for fullscreen and see if we can get to a solution.
When hiding the dockers only, it works as expected, without any flickering.
Note that I’m using linux with kde plasma. I don’t know how my tests would work in other OS or window managers.
1 Like