The idea I had here is to kind of simplify the dropping logic for the tree model. This could be extended to all of the other models as well, but this is just to demonstrate an alternative.
Rather than tracking the removed rows and updating the rows ourselves, I had the idea to use QPersistentModelIndex which the model will internally and automagically update as rows are being moved. It's possible this is a safer idea, could potentially prevent future contributors from shooting themselves in the foot if trying to later tweak the drag and drop logic.
There's kind of a few small caveats here in that I had to use fake/made up index for the insertion location because models don't like insertion row being equal to the row count when you drop at the end of the model. When I attempted to use index instead of createIndex for the insert index, it would crash when you dropped at the end of the tree. Also because we are actually doing a remove followed by insert, when moving within the same parent the persistent model index is not updated, so we are still manually offsetting the insert row in that case. This is something #147 could potentially resolve though.
Regardless, everything seems to work the same as master, including multiple discontiguous selection and drag and drop. It doesn't matter if the parents are different, you drag up, or you drag down, it all seems to work the same. I don't really care if we go with this but it's something to consider.
This is no longer necessary as of #201 being merged. We decided that it's better to just always serialize the drag and drop contents to be able to handle IPC drag and drop anyway.
The idea I had here is to kind of simplify the dropping logic for the tree model. This could be extended to all of the other models as well, but this is just to demonstrate an alternative.
Rather than tracking the removed rows and updating the rows ourselves, I had the idea to use QPersistentModelIndex which the model will internally and automagically update as rows are being moved. It's possible this is a safer idea, could potentially prevent future contributors from shooting themselves in the foot if trying to later tweak the drag and drop logic.
There's kind of a few small caveats here in that I had to use fake/made up index for the insertion location because models don't like insertion row being equal to the row count when you drop at the end of the model. When I attempted to use index instead of createIndex for the insert index, it would crash when you dropped at the end of the tree. Also because we are actually doing a remove followed by insert, when moving within the same parent the persistent model index is not updated, so we are still manually offsetting the insert row in that case. This is something #147 could potentially resolve though.
Regardless, everything seems to work the same as master, including multiple discontiguous selection and drag and drop. It doesn't matter if the parents are different, you drag up, or you drag down, it all seems to work the same. I don't really care if we go with this but it's something to consider.