Re: [mdt-papyrus.dev] DnD framework rework

[Mathieu Velten <mathieu.velten@xxxxxxxxxxxxxx>]

 Hi,

We are working on the same common dnd file with Vincent Lorenzo and I 
was having some conflicts so what I did is :
- rename the current common to oldcommon et mark it deprecated, so we 
know that we should use the new common ASAP.
- add the new common and use it in the sequence.

Feel free to modify the new common, I have no strong opinion on the 
forbidding to drop several views.

Regards,

Mathieu

Le 27/10/2010 19:40, TANGUY Yann 176637 a écrit :
> Thanks Mathieu.
>
> These changes are interesting and would improve Papyrus DnD management in my opinion. Well, I don't agree with the default drop forbidding to drop several views of the same element per diagram, but this is a minor issue that you will easily solve by overriding the method in Activity and Sequence diagram anyway (also, considering your remarks why don't you also leave this choice to the edit policies?).
>
> Currently the main issue for us is that we are lacking time to work on this DnD refactoring right now. Moreover, I would like to release Papyrus V0.7.1 around mid November which implies that most of us spend time on testing and debugging tasks.
>
> For these reason, I prefer postponing the DnD refactoring after the 0.7.1 release. In the mean time, if it helps solving some issues in the Sequence or Activity Diagram you can add your alternate CommonDiagramDragDropEditPolicy class in oep.diagram.common and use it in Seq - Act diagrams. We'll plan the re-factoring task later.
>
> Does this sounds ok for you ?
>
> Best regards,
>
> Yann
>
> -----Message d'origine-----
> De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Mathieu Velten
> Envoyé : lundi 25 octobre 2010 18:21
> À : mdt-papyrus.dev@xxxxxxxxxxx
> Objet : [mdt-papyrus.dev] DnD framework rework
>
>    Hello all,
>
> I was working with the DnD common edit policy lately and I found some problems with it. I am bringing this here to discuss before submitting important modifications.
> (org.eclipse.papyrus.diagram.common.editpolicies.CommonDiagramDragDropEditPolicy)
>
>
>
> The biggest issue I found is that the current common class bypasses the gmf command framework, which leads to unwanted behavior because the policies are ignored.
>
> For example in getDefaultDropNodeCommand we are building a createcommand and a setbounds command instead of asking the edit part to give us a fully complete command using a request.
>
>
> An other problem is that we change the location of the request to a relative one before calling the abstract method.
> I agree it could be convenient to already have relative location in the sub classes but it is not correct regarding the framework which uses absolute location in its requests.
> A protected helper method to translate from absolute coordinates to relative should be sufficient.
>
> Since this problem affects the behavior of an overridden method, most implementations need to be corrected regarding this point.
>
> You can find attached an incomplete patch.
> It fixes the common class according to this remarks and the sequence subclass for giving an example.
> I am working on usecase and activity subclasses that will follow tomorrow.
>
> I don't have time to look at all the other subclasses, but here is the procedure to fix each one of them :
>
> - take care not to bypass the command framework. replace all new
> CreateCommand() by a call to getDefaultDropNodeCommand or dropBinaryLink, or at least use hostEditPart.getCommand if you need more control. And there is quite a lot of them :).
> - if you do really use location in your algo (ie not just passing it to getDefaultDropNodeCommand or dropBinaryLink) you should translate it to relative before so that your algo behaves the same way as before. You can use getTranslatedToRelative method for that. And don't forget to use the original absolute coordinates for calling getDefaultDropNodeCommand and dropBinaryLink, or for using a request.
> - in your methods (and method signatures) try to use absoluteLocation or relativeLocation variable names to keep track of which one is in use.
>
>
> Thank you for reacting if necessary.
>
> Best regards,
>
> Mathieu
> _______________________________________________
> mdt-papyrus.dev mailing list
> mdt-papyrus.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev