Bug 446120 - Paste At Position doesn't paste at the cursor
Summary: Paste At Position doesn't paste at the cursor
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: Tools (show other bugs)
Version: 5.0.0-beta2
Platform: Compiled Sources Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: amyspark
URL:
Keywords: regression, release_blocker
Depends on:
Blocks:
 
Reported: 2021-11-26 15:06 UTC by amyspark
Modified: 2021-11-27 13:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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