Drop Actions

[MTK358]

Could someone help explain "Drop Actions"?

I don't want data to be automatically copied into items or for items to be added, I just want to the model to be notified that someone dragged something onto an item, and for the model to take acton.

[wysota]

Could someone help explain "Drop Actions"?

Drop action determines what should happen to the original data once the drop occurs. A copy action means a new instance of data is created in the target with no reference to the original data. Move action says the original data is transferred to the target and removed from the source. Link action says the data appears in the target and refers to the same entity as the original. For example, say you have some data model with each item having an identifier. Say you drag item with id=7. If you do a copy action, you will have to generate a new id for the target. If you do a move, the data in the target will retain the original id and a piece of data with this id will be removed from the source. If you do a link action, the data in the target gets the same id as the data in the source.

It is the source that suggests the drop action but it is ultimately the target that determines what the drop action is performed (it can override the hint from the source of the drag).

I don't want data to be automatically copied into items or for items to be added, I just want to the model to be notified that someone dragged something onto an item, and for the model to take acton.

That's most likely a copy action or a link action. What you actually do with the data is decided by how you implement dropMimeData() in the model (or the drop event in case of other objects).

[MTK358]

I'm still a bit confused. Is it the model that was dragged from that implements the actions? What if the references are only valid in the context of the model dragged from? What if there are no "references" but just data, like text?

[wysota]

Is it the model that was dragged from that implements the actions?

The source of the drag is notified what the final drop action was. Then it can modify its own data accordingly. Unfortunately Qt's QAbstractItemModel doesn't have API for this so if you really need it, you'd have to reimplement the whole dragging routine in the view. By default the view will remove the original rows from the model in case of MoveAction and do nothing for other actions.

What if the references are only valid in the context of the model dragged from?

Then obviously you ignore that in the target. Imagine you have a model containing some data and you perform a drag that is encoded in different mime formats. One of the formats is text/plain that contains the xml representation of the data. If you drop it onto a text editor, obviously it won't understand the structure of the xml and will ignore the id and treat everything as text (according to the mime-type) regardless of the drop action. But if the drop action was MoveAction then the original model should discard the original data.

In general once you do a drag and expect other applications to accept it, you lose control over it (as the drop is handled by the target and not by the source) so the data should be self-contained (i.e. not contain any pointers to the original data) - it should be a copy of all that is required to recreate the original data (technically speaking it is a serialized representation of the data). It is because even if you are certain that only your application will accept the data (i.e. by providing some custom mime-data), if you make a drop on another instance of the application it will accept the drop and will crash when trying to dereference a pointer in memory-space of a different process. Sorry if I overcomplicated things too much