Bug 446120

Summary:	Paste At Position doesn't paste at the cursor
Product:	[Applications] krita	Reporter:	amyspark <amy>
Component:	Tools	Assignee:	amyspark <amy>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ghevan
Priority:	NOR	Keywords:	regression, release_blocker
Version:	5.0.0-beta2
Target Milestone:	---
Platform:	Compiled Sources
OS:	Microsoft Windows
Latest Commit:	https://invent.kde.org/graphics/krita/commit/573a7622a2fbddef8379c2b84fe6eadfd24a46e6	Version Fixed In:
Sentry Crash Report:

Description amyspark 2021-11-26 15:06:13 UTC

SUMMARY

Invoking the feature and clicking on e.g. "Add as Reference Image" (or any other that uses QCursor::pos()) when the clipboard has an image bitmap (e.g. Firefox copy-paste, not a remote URL) inserts the image at the chosen option from the color space dialog, and not where the cursor was when the feature was invoked. If this dialog isn't invoked, but the menu was, it'll instead be inserted at the point of menu option click.

This regression was introduced in 47db9c0be50fc85f38ba6c86757a7b307f0bbbd4, because the refactoring didn't forward the cursor position at the drag-n-drop event to the clipboard handler.

STEPS TO REPRODUCE

See above.

OBSERVED RESULT

The image is inserted at the vicinity of wherever the cursor was between the tool invocation and the insertion op.

EXPECTED RESULT

Insert the image where the cursor was at the tool invocation.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
e650032da0 (upstream/krita/5.0) Make the ants 8 instead of 4 pixels

Comment 1 amyspark 2021-11-27 13:21:42 UTC

Git commit 30f7b1c9e966dca97f83f24da077df2789168aa8 by L. E. Segovia.
Committed on 27/11/2021 at 00:43.
Pushed by lsegovia into branch 'krita/5.0'.

Fix position inconsistency in Paste at Cursor

URL-backed images are handled by KisClipboardUtil::clipboardHasUrlsAction,
which sidesteps all positioning logic. Yet, KisClipboard::instance()->clip
also handles URL-backed images via KisClipboardUtil::fetchImageByURL.
Conversely, clipboard bitmaps are pasted into a paint device which is
then recentered.
This commit fixes the dissonance by dropping the specialization, and
ensuring that all clip() paths are centered.
Related: bug 443111

M  +0    -6    libs/ui/actions/KisPasteActionFactories.cpp
M  +7    -5    libs/ui/kis_clipboard.cc

https://invent.kde.org/graphics/krita/commit/30f7b1c9e966dca97f83f24da077df2789168aa8

Comment 2 amyspark 2021-11-27 13:21:50 UTC

Git commit be44b3f682e6e161dd122940236b2f580667d23d by L. E. Segovia.
Committed on 27/11/2021 at 00:43.
Pushed by lsegovia into branch 'krita/5.0'.

Fix regression in positioning of URL-based drag-and-drops

47db9c0be50fc85f38ba6c86757a7b307f0bbbd4 did not account for the
position of the drop event, and instead used the cursor position.
This means that, if the menu and/or the dialog popup were invoked, the
paste position would be taken from the interaction with those widgets
and not from the place where the action was triggered.

This doesn't fix the discrepancy in painting a remote and a local
image; that will be fixed in the next commit.

M  +20   -26   libs/ui/KisView.cpp
M  +4    -2    libs/ui/actions/KisPasteActionFactories.cpp
M  +3    -2    libs/ui/utils/KisClipboardUtil.cpp
M  +1    -1    libs/ui/utils/KisClipboardUtil.h

https://invent.kde.org/graphics/krita/commit/be44b3f682e6e161dd122940236b2f580667d23d

Comment 3 amyspark 2021-11-27 13:25:32 UTC

Git commit 689c86d924beb64ecd4f6b00cf254c004dea4c0f by L. E. Segovia.
Committed on 27/11/2021 at 13:24.
Pushed by lsegovia into branch 'master'.

Fix regression in positioning of URL-based drag-and-drops

47db9c0be50fc85f38ba6c86757a7b307f0bbbd4 did not account for the
position of the drop event, and instead used the cursor position.
This means that, if the menu and/or the dialog popup were invoked, the
paste position would be taken from the interaction with those widgets
and not from the place where the action was triggered.

This doesn't fix the discrepancy in painting a remote and a local
image; that will be fixed in the next commit.
(cherry picked from commit be44b3f682e6e161dd122940236b2f580667d23d)

M  +20   -26   libs/ui/KisView.cpp
M  +4    -2    libs/ui/actions/KisPasteActionFactories.cpp
M  +3    -2    libs/ui/utils/KisClipboardUtil.cpp
M  +1    -1    libs/ui/utils/KisClipboardUtil.h

https://invent.kde.org/graphics/krita/commit/689c86d924beb64ecd4f6b00cf254c004dea4c0f

Comment 4 amyspark 2021-11-27 13:25:40 UTC

Git commit 573a7622a2fbddef8379c2b84fe6eadfd24a46e6 by L. E. Segovia.
Committed on 27/11/2021 at 13:25.
Pushed by lsegovia into branch 'master'.

Fix position inconsistency in Paste at Cursor

URL-backed images are handled by KisClipboardUtil::clipboardHasUrlsAction,
which sidesteps all positioning logic. Yet, KisClipboard::instance()->clip
also handles URL-backed images via KisClipboardUtil::fetchImageByURL.
Conversely, clipboard bitmaps are pasted into a paint device which is
then recentered.
This commit fixes the dissonance by dropping the specialization, and
ensuring that all clip() paths are centered.
Related: bug 443111
(cherry picked from commit 30f7b1c9e966dca97f83f24da077df2789168aa8)

M  +0    -6    libs/ui/actions/KisPasteActionFactories.cpp
M  +7    -5    libs/ui/kis_clipboard.cc

https://invent.kde.org/graphics/krita/commit/573a7622a2fbddef8379c2b84fe6eadfd24a46e6