Refactoring Paste and Drag-n-drop event handling
Closed, ResolvedPublic

Description

Quoting from the kimageshop thread:

The current implementation of clipboard events (both Paste As, as well as dragging and dropping) is spread across five different classes, with potentially duplicate (or at the very least inconsistent) behaviour.

As far as @dkazakov can tell, the requirements for the new system should be something like this:

  1. All mimedata handling routines should use common code (or at least common policy/priorities)
    • D&D into the start page
    • D&D into KisView (that is, to an opened document)
    • D&D into Layers Docker
    • Paste from the clipboard
  2. If mimetype has multiple formats, then they should be tried in the order of (user customizable?) priority
    • all places should use the same priority (now the code is ad-hoc, so the requirement is not fulfilled)
    • if one format exists, but fails, Krita should add warning to the log and continue to a different format (now it stops on the first found supported format)
  3. The tests for D&D should be done for the matrix of configurations on Chrome/Firefox/Safari versus Windows/Linux/MacOS. The same browser provides different mimedata on different platforms.
lsegovia created this task.Jan 10 2022, 8:39 PM
lsegovia claimed this task.Jan 10 2022, 8:42 PM

Original version: this was the "consent flow".

Current mockup: I was thinking along these lines:

If the bitmap has no color info, this dialog (newly made, to have it fully Qt Design-able) will pop up:

Currently, the dialog always pops up, even though the user can set their desired value in Preferences / Colour management:

A refactor of that preference is also needed, because some paste attempts instead override the preference value temporarily.

Some stats:

  • 20 inclusions of kis_clipboard.h
  • ImageBuilder::createImageFromClipboardDelayed is the one overriding the user's paste preference
  • KisClipboard::instance()->clip() is called in 10 different places (including tests):
    • in the Image from Clipboard widget
    • in the infamous KisClipboardUtil::clipboardHasUrlsAction
    • in various paste factories
    • in the ImageBuilder QML (not sure where this one is invoked)
    • in libkis's Selection::paste (not sure where this one is invoked)

The proposal looks good to me :)

All instances of clip() now go through the consent flow, same as anyone calling getImageFrom<clipboard/metadata>.

I need to check on ImageBuilder::createImageFromClipboardDelayed.

See https://invent.kde.org/graphics/krita/-/merge_requests/1296 for the current state of the refactor.

I need to check on ImageBuilder::createImageFromClipboardDelayed.

That was the last instance of refactor, it's been completed. It should be ready for review @dkazakov.

lsegovia closed this task as Resolved.Aug 22 2022, 8:33 PM