<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Then, the problem is that you didn't implement the most important function for drop events in a model: dropMimeData().</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Ah, I thought that was required for external drops only.</div></div></div></blockquote><div><br></div><div>A Qt model doesn't really care about the source of the drag and drop: it's the view's responsibility to check if the dropped data should be managed by the model or not, then the model will act accordingly. In this case it's pretty straightforward that the source is the same, but models should always provide a generic interface no matter the source. For instance, you could drop an url from the browser, some text from an editor, or a document from the file manager.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Drag and drop always happens (or should happen) through QMimeData in Qt models. Qt views (and their models) use the "application/x-qabstractitemmodeldatalist" format to serialize data, which is created by calling QAbstractItemModel.mimeData (see <a href="https://doc.qt.io/qt-5/qabstractitemmodel.html#mimeData" target="_blank">https://doc.qt.io/qt-5/qabstractitemmodel.html#mimeData</a>), and the structure is the following:</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Now, where did you learn about this format specification? I did not see it anywhere in the Qt documentation.<br></div></div></div></blockquote><div><br></div><div>As far as I know, it's not clearly specified anywhere (there's a generic description here: <a href="https://doc.qt.io/qt-5/model-view-programming.html#mime-data">https://doc.qt.io/qt-5/model-view-programming.html#mime-data</a> ), but you can find it in the sources of QAbstractItemModel:mimeData, which creates a QDataStream with data encoded using :itemData() in the form:</div><div><br></div><div>stream << row << column << itemData(index)</div><div><br></div><div>(note that the above syntax is also available on PyQt, while unfortunately it's not possible with the opposite >> assignment, due to Python dynamic typing)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>I do have a question, though. Why do we need the condition 
itemRow < <span style="color:rgb(148,85,141)">self</span>.rowCount(QModelIndex()) <span style="color:rgb(0,51,179)">and </span>itemCol < <span style="color:rgb(148,85,141)">self</span>.columnCount(QModelIndex())

? For an internal drop, itemRow and itemCol should always satisfy it.</div></div></div></blockquote><div><br></div><div>Mmmh, I believe I just did that without even thinking (I've been working a lot with custom models lately). As long as the movement is internal, that's obviously not required.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Going a bit beyond this particular example, what happens if the method mimeData has a list with multiple types? Method mimeData is supposed to return a single QMimeData, so there will be a single encoding of the data, and if so, for which of the multiple mime types?</div></div></div></blockquote><div><br></div><div>In theory, you should always ensure that the format is application/x-qabstractitemmodeldatalist before going on with this implementation; according to your needs, you could always implement your own alternatives for other types of mime data.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Also, in case of multiple supported mime types, how can dropMimeData know the format in which 'data' is encoded? It does not seem QMimeData provides a method indicating its format.<br></div></div></div></blockquote><div><br></div><div>By default there is only one supported mime type (x-qabstractitemmodeldatalist) for models, but QMimeData can theoretically support any serializable content set using setData(), and you can add that support by implementing mimeData() (just override it, call the base implementation and then add more data formats): for instance, QStandardItemModel also creates application/x-qstandarditemmodeldatalist (which it uses for itself when dropping).</div></div><div><br></div><div>Cheers,</div><div>Maurizio</div>-- <br><div dir="ltr" class="gmail_signature">È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi<br><a href="http://www.jidesk.net" target="_blank">http://www.jidesk.net</a></div></div></div></div></div></div>