Thank you for this information.
I did not know links. Is that a new functionality you are implementing?realthunder wrote: ↑Wed Jun 06, 2018 10:54 amIt is best suited as a context menu action in Part workbench if you want to use compound. However, IMO a draft clone is better suited for the job. And if my changes are accepted, Link is the ultimate solution, which I do have a command implemented as context menu action, called "Replace with link".
A draft clone can be the solution for basic parts. But when the part is complex (fusions, intersections, extrusions, …) you do not want to duplicate the part. A clone is independent of the original. Changing the size of the original does not change the size of the clone, what is one of the dependences you may want to keep in your model.
It therefore depends on the type of part, and on the users’ wish.
I will change this OK.
I do not agree on that position. Drag and Drop is a Gui concept. That is why I think canDrag and canDrop should be renamed in allowRemove and allowAdd or something equivalent. The object is not to know the reason why this operation is done and how it is done (by gui, scripting, …).
It is to the Gui to interrogate the parent object of the dragged object to know if it allows removing its son object, and only propose the actions to the user that respect this constraint.
It is also to the gui to interrogate the object destination object to know if adding an object is possible and restrict the possible actions to respect this constraint. This may end to no action is possible.
The user chooses between the different actions left by using the alteration keys.
That is what I implemented!
There should no interpretation. It is to the user to user to choose the operation among the possible operations.realthunder wrote: ↑Wed Jun 06, 2018 10:54 amMy Link object interpret the dropping action as setting the link path, which obviously should not remove the object from its parent. Besides, there are lots of other complications when dragging and dropping involves context, determined by dragging object's parent, and grandparents. But that's only in my branch, and doesn't concern you at the moment.
Is everything is properly controlled, the action passed to the dropEvent function is clear:
Move (remove and add), Copy (only add), Link (make a link).
I used Qt::LinkAction to replace the target instead of adding to the target. May be should I extend the Qt::QTreeWidget to add the replace feature, so link will still be available for your purpose. It seems quite obvious that both or features cannot be implemented with the Qt::QTreeWidget as it is.
I do not know the effort needed for that, and there are decisions to be made on images added to cursor, keys to be used, possible combinations.
I changed core.autocrlf to true. I hope this will solve the problem.
Let me know.