On 07/21/2012 04:24 PM, Thomas Lübking wrote: > Am 21.07.2012, 15:51 Uhr, schrieb Thomas Gahr <[email protected]>: > >>> (And no, abusing and altering the shape for the LinkAction cursor >>> won't work in that case either ;-) >> Yeah, thinking about that idea makes shrug, though I give myself half a >> credit for creativity ;) > > There /is/ a "legal" way abusing the LinkAction to display a normal > arrow cursor from the drag source, that is setting a pixmap of the > cursor as pixmap cursor for that DropAction on the executing QDrag > instance. > > Issues: > a) you have to initiate the drag from the treeview yourself (c'n'p > treeview code) > b) you need to render the cursor into a pixmap - that's platform > dependent and /me only knows how to do that on X11 ;-) > Also i think it's not possible to have additional content (mime > icons) pixmaps this way (so you'd have to render them into the pixmap > as well) and... > c) you still abuse the DropAction OK. I assumed you were on IRC last night and read my suggestion, since you talked about abusing LinkAction and I was mentioning it there, as well :) My idea to abuse LinkAction was including a) - since the D&D action is initiated from MsgListView and I already reimplemented startDrag (largely c'n'p'ing QAbstractItemView code) there, it would be possible.
So this way LinkAction would correspond to our "AskUserAction". Given the fact that MailboxModel only provides the mimeType "application/x-trojita-message-list" I think it's safe to assume that D&D will only be trojita-internal and thus the link-action is safe to be abused - or does linking mails make sense in any way? What I don't like is the non-obviousness of the code. In (at least) three places Qt::LinkAction would be used with different meaning than what it was meant for - though a #define TROJITA_DND_ASKUSER_ACTION Qt::LinkAction could make it more clear. The definite show-stopper is b) I guess. Providing a cursor that indicates the fact that no action is decided upon (and I guess the default LinkAction-cursor does NOT do that) and is consistent with the system cursor was the actual intent of this patch. It looks like none of the approaches is a definite solution, at least not in my opinion. Thanks a lot for your feedback, Thomas! Cheers, Thomas
