[QScintilla] force copy-action when drag&dropping between two QScintilla widgets

[Baz Walter]

On 18/09/14 08:36, Marc Gronle wrote:
> Ok, the way proposed by Baz Walter works for me as well. If I change the
> default drop action before calling the base-class dropEvent, the default
> will be replaced by the previous default (set in QSciScintillaQt::StartDrag
> in the call qdrag->exec(...)) since the drop action is not accepted using
> *accept()* but using *acceptProposedAction()*.

I believe Qscintilla works in effectively the same way as QTextEdit. 
That is, if the drop is permitted, QTextEdit will end up calling 
acceptProposedAction() rather than accept().

> In my case it is more the source widget that should control whether its
> content can be moved, copied or both and not the receiver. In the case
> described above (the case which works now), the implementation is done in
> the dropEvent of the receiver, that needs to check if the action should be
> switched to a copy action depending on the type of source widget. Maybe it
> would also be nice to being able to change the default action in the
> startDrag method.

But how could you know at the start of the drag where the data will be 
dropped? It could be on itself, another editor, some other widget, in a 
different application, or just invalidated for some unknown reason. The 
drag has to wait to see what happened to the drop before it can decide 
what to do next. This is why it is necessary (I think) to reset the drop 
action *after* processing the drop in the receiver.

> For instance, if the source widget is read-only and text is dragged into
> another widget, a move action is used as default and the dropped text is
> finally deleted from the source widget. I think this is not desired. So
> maybe there is a good solution to control this.

What you're describing here is already the current behaviour: i.e. the 
text doesn't get deleted in the source if it is read-only (this applies 
to both Qscintilla and QTextEdit). And resetting the drop action in the 
receiver's dropEvent would not have any bearing on this.

-- 
Regards
Baz Walter