| Summary: | Python - Weird Zoom Bug | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | keyth_qcfx2 <keyth2363214> |
| Component: | Scripting | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | eishiya, takiro-kde, vitamorus.art |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.9 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
keyth_qcfx2
2021-05-14 02:45:29 UTC
Can confirm this is still happening in 4.4.5 (AppImage) on Linux and it was reported a few times already on Kirta-Artists.org https://krita-artists.org/t/canvas-class-what-does-zoomlevel-returns-compared-to-setzoomlevel-manual-link-inside/15702 https://krita-artists.org/t/weird-zoom-bug/23630 https://krita-artists.org/t/python-api-canvas-zoomlevel-returns-different-value-than-set-by-setzoomlevel/25829 Still happening in 5.2.6. My custom zoom script has the same workaround in it to OP's, but only works in native pixel mode and breaks in print mode, and even for the one mode where it does work, it relies on a magic number. Re-confirmed for 5.2.9. I agree with the reporter that it's weird for the getter and setter for the same value (zoomLevel) to use different units and not be consistent with what's shown in the software. It would be nice if the functions could at least take the dpi as an argument and sort out the relative scaling for the person writing the script. |