On Fri, Jun 2, 2017 at 1:50 AM, Nyall Dawson <nyall.daw...@gmail.com> wrote: > I think copy should definitely be the ONLY behavior here. Otherwise > there's data loss - user's styling and layer settings will be lost, > and dragging memory layers will lose all features (admittedly dragging > memory layers doesn't copy any features anyway, but that makes it > worse... the contents are irretrievably lost). > > I can't work this one out. I think > QgsDockBrowserTreeView::dragEnterEvent() should be calling > QTreeView::dragEnterEvent( e ) - without that it's not drawing the > drop indicators correctly. And in > QgsDockBrowserTreeView::dragMoveEvent if I reset the drop action to > CopyAction both before *and* after calling QTreeView::dragMoveEvent( e > ) then the visual appearance of the drag appears correct, and seems > ready to perform a copy action... but the actual action performed is > still a move action.
QTreeView::dragEnterEvent() and QTreeView::dropEvent() override the action calling acceptProposedAction(). No idea what Trolls intended. I have forced CopyAction before and after in both dragMoveEvent AND dropEvent and it seems to work. I have implemented DD for memory layers for postgis and spatialite. I don't have db2, mssql, if maintainers of them are interested, look into fb6f181. It should be probably all rewritten because there is a lot of similar code in providers' Qgs...Item::handleDrop(). The handleDrop() should be implemented in QgsDataCollectionItem and importLayer() added in items? Memory layer is identified by pid and layerId which are appended to uri only for this purpose. Not nice, I could not invent anything cleaner. Radim _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer