Thanks Jukka,

that's probably not a bad idea considering how much time I have spent trying to get this to work via QT. I had been toying with the idea of just sending a dictionary of the relevant data, probably via a custom mime type, then re-creating the custom item upon drop in the receiving view. I will keep that in mind as my last resort, but it feels like the default implementation of the drop behaviour is soooo close, that it should be possible to drop a custom item in some QT-ish way without re-invening the wheel - or is that too optimistic?

Here is a simple test code, hopefully we can get some more input with that:

With this code, when dropping an item fro the left into the right view, the print statement shows that a QStandardItem is produced rather than the custom item.

Any more takers?


On 19/09/16 7:31 PM, Purma Jukka wrote:
since you asked any ideas... In my app I have had to re-invent drag&drop for 
some items (because I want to drag QGraphicsItems in scene while having all kinds 
of effects on the items they are connected while keeping the main event loop 
running etc. ) and learned a habit to give up when I didn’t find Qt-way of doing 
things and instead to choose the simplest pythonesque way.

So in your case at this point, I would have
1. 'start drag' store the dragged data, just the main payload, not the Q-item 
containing them, in some stable object (main window), just as 
2. when drag gets dropped to those problem recipients, in drop event, manually 
put the data from main window into recipient, without bothering with the 
Q-representations of the data.

In my app I have a multipurpose controller-object and ctrl.dragged is used to 
store the non-qt data of whatever is being dragged. It was my solution to 
struggle with QStandardItems and such.

In conclusion, since we are doing things with Python + Qt, I think we are 
justified to skip Qt when there is an easier (or more readable) pythonesque way 
of doing things.


Frank Rueter | OHUfx <> kirjoitti 19.9.2016 kello 9.56:

I'm still struggling with this. I went back to using a QStandardItem for a while 
which solved the dag&drop behaviour, but now I really need to use a custom item 
that inherits QStandardItem which breaks the drop behaviour again.

Any ideas or guidance would be greatly appreciated.


On 16/08/16 7:26 PM, Frank Rueter | OHUfx wrote:

I am trying to get drag&drop to work between two QListViews using a custom item.
I can't find the info I need online other than this document which helped a 
little bit but now I'm stuck.

Drag&drop from one QListView to another works fine when I use a QStandardItem 
to hold my data, but when I use a custom item I run into trouble, because the 
receiving model/view creates a QStandardItem when the incoming custom items are 

Ideally I could tell the receiving model to use my custom item as the default 
item and otherwise just do it's thing, but I suppose it won't be that easy?!
I have played around with the receiving model's dropMimeData() and insertRows() 
methods but can't work out how to read the incoming data to then insert a 
custom item into the receiving model manually.
In QAbstractItemModel.dropMimeData() I tried reading'application/x-qabstractitemmodeldatalist'), but that returns a 
byte stream that I don't know how to handle.

Do I have to re-implement the sender's drag data as well to send the custom 
item in the first place?

It seems that everything works out of the box except the creation of the 
QStandardItem upon drop, rather than my custom item, so I am hoping I don't have to 
re-invent the (drag&drop) wheel just to get that one part right?!

Any advise would be greatly appreciated.


<Sähköpostiliite.png>     vfx compositing | workflow customisation and 

PySide mailing list
PySide mailing list

PySide mailing list

Reply via email to