Community
Participate
Working Groups
Build Identifier: 20100617-1415 LabelEditParts in GMF editor disappear when clicking on them and then in empty space. It seems that a label is not refreshed after its direct edit box is disposed. It re-appears again when the diagram is refreshed (e.g., after moving its owner node). This is new with eclipse 3.6 (GMF 2.3.0), the same code is still working fine with 3.5.2 (2.2.2). This bug renders the gmf-runtime unusable when using LabelEditParts. Reproducible: Always Steps to Reproduce: 1. Check out the mindmap example (org.eclipse.gmf.examples.mindmap, org.eclipse.gmf.examples.mindmap.edit, and org.eclipse.gmf.examples.mindmap.rcp.diagram) and run it 2. Create a diagram, then a resource node, and give a name for this node 3. Click on the name label and then in empty space
Think your label is ouside the shape - the floating label. A clipping strategy has been introduced in GEF and we still need to put more work adopting it in GMF.
Yes thats right, the LabelEditPart is outside a Shape. When I move the label so that it overlaps a little bit with the corresponding shape it is drawed fine. Is there a workaround for this problem? Can I have the "old" GEF clipping-behavior?
I thought i adopted the clipping strategy such that the old border items painting functionality is preserved, but i see that this is obviously not true. I'll investigate and fix for 2.3.1.
Created attachment 173730 [details] patch The change in GEF affecting GMF border items is calling Rectangle#intersects(Rectangle) instead of IFigure#intersects(Rectangle). I adopted clipping strategy in GMF's BorderItemsAwareFreeFormLayer - it seems to fix it for me. Can you please check if it fixes the issue for you too?
This patch fixes the bug for me
Delivered to HEAD (for 2.4, right?), so need to deliver to 2.3 maintenance. Anthony, I can see it in CVS Respository, but when trying to switch to another branch the 2.3 maintenance stream is not listed :-( Is it listed for you?
GMF Runtime release 1.4 for Helios, so the new maintenance branch is R1_4_maintenance.
Thanks. 1.4 maintenance stream does show up. I delivered the fix there too. Hence, this is fixed now
*** Bug 319348 has been marked as a duplicate of this bug. ***
Created attachment 175237 [details] Patch according to fix-1
The patch for this bug causes another Problem: In org.eclipse.gmf.runtime.diagram.ui.render.util.DiagramImageUtils.calculateImageRectangle(List<IGraphicalEditPart>, double, Dimension) there is the following code: if (figure instanceof IExpandableFigure) bounds = ((IExpandableFigure) figure).getExtendedBounds(); else bounds = figure.getBounds().getCopy(); translateTo(bounds, figure, printableLayer); For figure beeing a BorderedNodeFigure this goes through the first branch to get the bounds. After getting the bounds, it translates these bounds. during this method, the Rectangle gets modified. In the next call to the getClip(IFigure)-Method you provided this wrong rectangle is returned, resulting in an invisible figure. I think there are a few ways to fix this: 1) modify calculateImageRectange to bounds = ((IExpandableFigure) figure).getExtendedBounds().getCopy(); 2) Always return a copy in the getExtendedBounds()-Method of BorderedNodeFigure 3) Call validate() in your patched getClip()-Method before calling getExtendedBounds(). I think proposal 3 is kind of a ugly hack. I don't know what is the proposed semantic of the getExtendedBound()-Method: should it return a modifiable Rectangle or not. Depending on this, Fix 1 or 2 should be prefered. The getBounds()-Method specifies that the rectangle can be passed by reference and that callers may not modify this rectangle. the getExtendedBound() Method lacks such a comment. So I propose adding one and to modify calculateImageRectangle (see my Patch according to fix-1) I'm not absolutely sure if its right to handle this by reopening this bug (or if I should file a new Bug), but for me it is exactly the patch/fix here leads to bad behavior. Unfortunately I cannot give a sample for mindmap-sample how to reproduce this. For our rcp-editor, it happens when calling copy on a element in a compartment and afterwards clicking on the compartment. But I think this problem will always occur when calling calculateImageRectange.
This should have a been a problem regardless of this patch. Yes, we should of course call #getCopy() before translating. Can you please separate this into a separate defect?
*** Bug 318710 has been marked as a duplicate of this bug. ***
