Community
Participate
Working Groups
Build Identifier: Build id: 20100506-2000 When a port is moved, it becomes invisible after de-selecting the owning class. Changing the position of the owning class, makes it visible again. (Maybe a Linux only problem?) Reproducible: Always Steps to Reproduce: 1. Open a composite structure diagram 2. Add a class 3. Add a port 4. Change position of port
Could not reproduce in windows (tested against Composite Structure Diagram r1821).
I manage to reproduce something quite similar since 3.6RC3 + Papyrus N201006100643 1. Create Composite 2. Create Class + Port 3. Place Port label outside the Class 4. Click on the Diagram background to deselect the Port label -> The PortLabel disappear and comes back after moving the Port. The issue is not reproductible on 3.6M7.
(In reply to comment #2) > I manage to reproduce something quite similar since 3.6RC3 + Papyrus > N201006100643 > 1. Create Composite > 2. Create Class + Port > 3. Place Port label outside the Class > 4. Click on the Diagram background to deselect the Port label > > -> The PortLabel disappear and comes back after moving the Port. > > The issue is not reproductible on 3.6M7. I can no longer reproduce the bug on Linux with the build id I20100527-1700, Papyrus N201006090630. I guess, this is a GMF/GEF issue that has been fixed. I will set Lamine on copy to try on his machine (Linux as well, but different distribution) and propose to set to resolved, if not reproducable for him.
I have try and i can't reproduce the bug on Ubuntu 10.04 and Papyrus N201006090630.
(In reply to comment #2) > I manage to reproduce something quite similar since 3.6RC3 + Papyrus > N201006100643 > 1. Create Composite > 2. Create Class + Port > 3. Place Port label outside the Class > 4. Click on the Diagram background to deselect the Port label > > -> The PortLabel disappear and comes back after moving the Port. > > The issue is not reproductible on 3.6M7. Could reproduce this problem with 3.6M7 + N201006090630. So, it does not seem to be related to 3.6RC3 only but to the papyrus version?
(In reply to comment #5) > (In reply to comment #2) > > I manage to reproduce something quite similar since 3.6RC3 + Papyrus > > N201006100643 > > 1. Create Composite > > 2. Create Class + Port > > 3. Place Port label outside the Class > > 4. Click on the Diagram background to deselect the Port label > > > > -> The PortLabel disappear and comes back after moving the Port. > > > > The issue is not reproductible on 3.6M7. > > Could reproduce this problem with 3.6M7 + N201006090630. So, it does not seem > to be related to 3.6RC3 only but to the papyrus version? Could reproduce label problem with 3.6RC3 + N201006110631 as well. Should we open a new error or treat it in the context of this error, since it might have a similar technical reason?
draw2d issue -> need to check if the issue still exist in Helios release
I have try and i can't reproduce the bug on Ubuntu 10.04 and Papyrus 0.7.0.V201006241830. eclipse Version: Helios Release Build id: 20100618-0524
Related to change of the clipping strategy introduced between Draw2D V20100511 (~M7) and V20100517. The clipping strategy has to be modify to include not only the figure but also the possible affixed child nodes and external node label.
The problem is caused by the fact that the DiagramEditPart does not use a suitable clipping strategy. The paintChildren method of the draw2d.Figure class examines the clipping strategy of a figure: if it is set to null (which is the case of the figure created by the DiagramEditPart), it simple takes the "normal" getBounds of its children. if a clipping strategy is set, it applies this function to get a custom bounds value. The bounds rectangle is used to detect whether something needs to be redrawn. In case of a class owning a port with a label, the diagram (on the Figure level) contains a BorderedNodeFigure which contains two childs: the ClassNodeFigure and a BorderItemContainerFigure which in turn contains the port and the label. If no clipping strategy is used, the BorderedNodeFigure returns its bounds which correspond to the area of the class only. The suggested modification below of the PackageEditPart constructor below adds a suitable constructor which adds a clipping strategy returning the extended bounds. Please test (seems to work on Linux) (in package org.eclipse.papyrus.diagram.composite.edit.parts) h public PackageEditPart(View view) { super(view); getFigure().setClippingStrategy (new IClippingStrategy () { public Rectangle[] getClip(IFigure childFigure) { if (childFigure instanceof BorderedNodeFigure) { return new Rectangle [] { ((BorderedNodeFigure) childFigure).getExtendedBounds () }; } else { return new Rectangle [] { childFigure.getBounds ) }; } } }); }
Created attachment 173624 [details] Suggested patch for the bug
Unfortunately, the error still occurs (with the patch) in case of a composite class that has a part with a port (and the port label is placed outside the part). The solution is likely to be very similar to the existing patch, the clipping strategy needs to be applied to the composite class.
Created attachment 173703 [details] Alternative patch This is an alternative patch which is inefficient (yet probably without noticeable impact). It handles additional cases, in which ports are nested within composite structures.
Integration of https://bugs.eclipse.org/bugs/attachment.cgi?id=173703 for the coming release, we'll try to find a better solution later. Code generation templates modified (related changes manually applied). (Done in r2325)
Related bug posted on GEF / Draw2D : https://bugs.eclipse.org/bugs/show_bug.cgi?id=319348 Product/Component: GEF / draw2d
The bug is caused by GMF bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=319191 The patch above should be removed, once the corrected GMF version (2.3.1) is integrated.
Patches provide workaround for a GMF bug which is corrected in version 2.3.1. Should remove patch, once 2.3.1 is in use.
Sorry for closing this bug some minutes ago. We should keep it open, since there is work to do once we switch to GMF 2.3.1: remove work-around and test if the problem is still fixed.
In r4544 - Previous patch removed from generation template (fixed in GMF). In r4545 - Manual change in Composite Structure Diagram. No need to re-generate diagram especially for this, current implementation should not cause any trouble.
