Bug 433278

Summary:	"Bounds" of the panning area seem to only exist visually, but not functionally
Product:	[Applications] krita	Reporter:	tomtomtomreportingin
Component:	General	Assignee:	Krita Bugs <krita-bugs-null>
Status:	CONFIRMED ---
Severity:	minor	CC:	ahab.greybeard, vitamorus.art
Priority:	NOR
Version First Reported In:	5.2.6
Target Milestone:	---
Platform:	Appimage
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description tomtomtomreportingin 2021-02-19 22:15:42 UTC

SUMMARY
When the user performs actions that would lead the view of the canvas outside of the "bounds" of the view, such as significantly resizing the canvas or adjusting the zoom in certain cases, this leaves the user in what might seem like a dead zone that prevents panning in a certain direction. Rather, the user must pan back into the actual visual "bounds" of the panning area.

STEPS TO REPRODUCE
1. Pan to the left until the bounds of the panning area appears to be reached.
2. Pan to the left a few more times.
3. Pan to the right.

OBSERVED RESULT
Nothing seems to happen besides the canvas shifting up and down until the user pans within the actual visual bounds. Same behavior often occurs when resetting the zoom levels to 100%, when the zoom level is low and the canvas is leaning to the far side of the view. Same applies to resizing the canvas in a similar situation.

EXPECTED RESULT
The panning bounds should not only be visually implied but also actually exist. A significant zoom or resize action should leave the view bordering these bounds instead of outside of the bounds.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
(available in About System)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.12.9 (Appimage)

Comment 1 Ahab Greybeard 2021-02-20 20:34:24 UTC

I can confirm this for appimages 4.3.0 to the Feb 20 5.0.0-preapha (git f26dbfe) for panning up/down and left/right as described.

There seems to be some kind of 'overun' on a movement demand counter whereas the effected movement is limited to a reasonable value.
After this has happened, the movement demand counter must be dragged back down to be equal to or less than the effected movement value before a change happens in the effected movement.

This problem also exists in the 4.4.2 Timeline docker zoom control for zooming out where the effected zoom out value is limited but the demanded zoom out can increase beyond the effected value.
It does not exist for zoom in because the effected zoom in is (strangely) not limited.

The problem with the Timeline docker zooming has been fixed in the 5.0.0-prealpha branch but not in the 4.4.3-alpha branch.
Whoever did that may be able to give advice.

Comment 2 Vitamorus 2024-11-12 20:20:06 UTC

Re-confirmed for 5.2.6. Indeed it seems like some coordinates aren't properly re-adjusted when panning outside the boundaries using Canvas Inputs (space bar).