Restrict possible targets for Semantic Drag&Drop

[jessymallet]

Semantic Drag&Drop, i.e. from explorer view on diagram, could be improved.

Indeed, implemented tools authorize to semantic Drag&Drop every element on the background of the diagram (it is OK) and on every container node even if this is not its semantic parent.

For example, we can Drag&Drop a Package in its own representation and so on. There is no sense to have this kind of representation and it brings confusion. It should be forbidden.

Expected behavior :

It should be interesting to authorize semantic Drag&Drop on background of diagram and on their semantic/graphical parent only.

Actual screenshot behavior :

[stephanelacrampe]

I don't agree with "It should be interesting to authorize semantic Drag&Drop on background of diagram and on their semantic/graphical parent only.". It conflicts with the features that is moving a part under a package when drag&dropping it from a diagram. Let me explain: let's say a user wants to D&D a part from the explorer to a diagram on an existing package, but not the one in which the part is under: then it would prevent from doing it. But once it is on the diagram, then you can move the same part under the same package on the diagram (not from the explorer) and it would move the part semantically under this package. The user won't understand why it can do it on the diagram but not from the explorer. To me, the rules should be:

• (1) A User can drag & Drop an element from the explorer in the background of a diagram only if it is authorized to create the same type of element in the background of a diagram of the same type
• (2) A User can Drag & Drop an element A from the explorer to an existing element B in a diagram if A != B and if the same operation would be authorized if it was made from the same element A but from the diagram instead of the explorer, and producing the same results (for example, if a Part from the explorer is dropped on a Package, then this part should be moved to this package) By the way, I suppose that when we will have things like Portal views, it may become possible to D&D between views, and the same rules should probably apply.