Drag-and-Drop Behaviour
As per a conversation on Matrix, GTK4 has made drag and drop (dnd) easier for application developers and there remains a few open questions/problems about the expectations of its behaviour.
To note, the mechanism of the action is app => gtk => compositor => gtk => app
where gtk stores the data from the drag, be it text or image data and it is ready to be dropped into an application (it can also convert data in this step).
Problem 1: drag and drop is accident prone
One can accidentally drop the contents of the drag into the incorrect application/destination
- discerning between what is an intended drop and an accidental one is not obvious all looks the same
- some applications can automatically process the automatically dropped content, e.g. a chat app automatically sending text (this is not ideal)
Problem 2: how to cancel a drag is unintuitive
Cancelling a drag is not an intuitive process.
- people make up for this shortcoming by using non-droppable areas, e.g. the top bar, to cancel
- any method to cancel a drag, e.g. pressing Escape, would not be discoverable
- an intuitive out is to return the content to its source, however that may not be easily navigable to
Problem 3: what is the expectation for files?
What should be the expectation for dropping material into the file browser or file chooser.
- should we autoconvert to files and is this auto conversion the ideal behaviour for all things? (people used to only dnd text)
- when autoconverting to files, dnding to a chat application, for example, should attach the file to send
- it will generate a file from text/image data when dropped into Files
- gtk is agnostic to the original file type, e.g. dnd will convert an SVG to PNG even if that isn't intended
This sort of data transfer should be friendly and accessible--having a clipboard/stash for dnd could be a solution here, see also #whiteboards#23 that would/could be an intermediary place for dragged (or copied) content would help for a lot of situations above.
Problem 4: Applications Need to Advertise they're Drop Targets
No application/widget is flashy in their "this is a drop target" status.
- applications/windows are not aware that a drag is being initiated
- the limitations here are at the compositor level