Reordering rows of QTableView with drag and drop
-
@Max-Paperno said in Reordering rows of QTableView with drag and drop:
For funsies, and to support my PoV that the item model is the proper interface to the data ;-), here's an option to toggle the drop behavior between move and overwrite using only the item model. It's @kshegunov 's solution but with a toggle switch to control the behavior. Items can still be dropped between lines to move them, in either mode. Most importantly, the QTableView::dragDropOverwriteMode remains false regardless (more on this below, after the code break).
Thanks for the code. However it doesn't address @Rodrigo-B's question (which we both missed in fact):
@Rodrigo-B said in Reordering rows of QTableView with drag and drop:
Would it be possible to obtain the same behavior but overriding view methods only?
So, I'd say yes, but you have to completely reimplement the
dropEventhandler in the view and not delegate to the model.@kshegunov said in Reordering rows of QTableView with drag and drop:
So, I'd say yes, but you have to reimplement the dropEvent handler in the view and not delegate to the model.
Agreed. Which wouldn't be so bad, except the part one really wants to re-use is private (
d->dropOn()) which further calls some other private utility methods and also updates a private member variable (dropIndicatorPosition). Everything except setting that private member could just be copied over (I think, and I"m not sure what the fallout would be from not settingdropIndicatorPositionproperly), but... blech. I get why stuff should stay private (ind), but something likedropOn()(and a few other utilities) could be protected members of the main class w/out much danger of breaking BC down the line.-Max
-
@kshegunov said in Reordering rows of QTableView with drag and drop:
So, I'd say yes, but you have to reimplement the dropEvent handler in the view and not delegate to the model.
Agreed. Which wouldn't be so bad, except the part one really wants to re-use is private (
d->dropOn()) which further calls some other private utility methods and also updates a private member variable (dropIndicatorPosition). Everything except setting that private member could just be copied over (I think, and I"m not sure what the fallout would be from not settingdropIndicatorPositionproperly), but... blech. I get why stuff should stay private (ind), but something likedropOn()(and a few other utilities) could be protected members of the main class w/out much danger of breaking BC down the line.-Max
Which gets me to my original position. I'd rather have this whole d&d ripped out of the model, and probably out of the view and put inside a delegate (i.e. one that's aggregated) which handles the logic and propagates down to the model how and what should be modified. But as said, such things aren't happening any time soon.
