| Re: [mdt-papyrus.dev] Diagram-2-diagram drag drop requirements? |
|
Hi, Both bugs are Luna related. I pushed a small but significant modification on master (Only on mars) https://git.eclipse.org/r/#/c/31045/ Previously DiagramDnDPolicy weren’t using the same parent policy, now on mars we have only one policy to rule them all : org.eclipse.papyrus.uml.diagram.common.editpolicies.CommonDiagramDragDropEditPolicy.java These are the future steps for
common DnD policy(It was only intended for mars, to avoid risks and regressions, but it can be discussed):
-
Extract a common policy to the framework (remove the Uml specific part)
-
Report most of the specific implementation to the common one (here is the step you are talking about)
o
This step should also be an opportunity to define global specification for DnD (Patrick may probably help for formatting specification)
o
Also define specification for each level : global/ common-Uml/uml-diagram/uml-element (same with sysml after the generator migration)
-
Add tests to DnD
o
Define a test example
o
Extract an abstract class from this first example
o
Use Juan test generator to generate all tests for DnD
o
Add specific tests case for specific DnD
-
Allow definition of DnD policy with the viewpoints (Add elements to the MM implementing the specifications of steps 2)
Regards, Benoit Maggi De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de GERARD Sebastien 166342 Hi, For DnD, there is a dedicated framework within Papyrus and a related extension point that enable to define specific DnD policies as shown in the
preference page of Papyrus:
So a priori, every DnD actions should be go through this framework.
It is sometime necessary/useful to be able to show a model element on a diagram even if the model element owning the diagram is not the container
of the dropped model element. In that case, the user should be asked what to do: cancel, show the model element and operate the related semantics change (It may be an interesting feature to also enable the user to preview the change before accepting or declining
it), or only show the model element on the diagram. In that latter case, the figure of the dropped element is adorned with the symbol
The aforementioned behavior should be the same whatever the drag origin of the model element to drop (e.g., another diagram – DnD between two different
diagram - , the same diagram, the model explorer or even the property view). The aforementioned behavior should be the same whatever the drop location within a diagram (e.g., the compartment of package, the nested classifier compartment of Class or the background
of a diagram). Merry Christmas and happy new year, Best… Sébastien. ------------------------------------------------------------------------------------------------------------------------------------------ Sébastien Gérard Head of the LISE labs and leader of the Eclipse Papyrus project (www.eclipse.org/papyrus). +33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST DILS/Laboratoire
d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE), Point Courrier n°174
91 191 Gif sur Yvette CEDEX De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Michael Golubev Hello, I would like to invite everyone to comment on just created bugzilla's:
- [2] Bug 455910: Display of shortcut decoration inconsistent for different element types Both bugs claims some inconsistency of behavior -- some elements reacts to DnD differently comparing to another. Technically both bugs are easy to debug and fix one way or another, but I am not quite sure which
of the choices is "right". Looking at the code at different diagrams we can find plenty of exceptional cases around DnD code, so it is difficult to infer the generic logic from them. Bugzilla also gives you a lot of DnD-related bugs but again in case by case basis.
Thanks, Regards [1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=455940
Michael "Borlander" Golubev 1165/1 Dvorecka, 14700, Prague-4 Podoli tek: +420 602 483 463 |
