Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 319191

Summary:

LabelEditParts disappear after editing

Product:

[Modeling] GMF-Runtime

Reporter:

Johannes Michler <orgler>

Component:

General

Assignee:

Alex Boyko <aboyko>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

CC:

aboyko, ahunter.eclipse, ansgar.radermacher, liyu2709

Version:

1.4.0

Target Milestone:

1.4.1

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
patch	none
Patch according to fix-1	none

Description Johannes Michler

2010-07-07 16:39:41 EDT

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

Comment 1 Alex Boyko

2010-07-07 16:43:26 EDT

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.

Comment 2 Johannes Michler

2010-07-07 17:35:57 EDT

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?

Comment 3 Alex Boyko

2010-07-07 17:51:31 EDT

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.

Comment 4 Alex Boyko

2010-07-07 21:16:30 EDT

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?

Comment 5 Johannes Michler

2010-07-08 04:21:07 EDT

This patch fixes the bug for me

Comment 6 Alex Boyko

2010-07-08 12:41:19 EDT

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?

Comment 7 Anthony Hunter

2010-07-08 12:51:42 EDT

GMF Runtime release 1.4 for Helios, so the new maintenance branch is R1_4_maintenance.

Comment 8 Alex Boyko

2010-07-08 12:56:38 EDT

Thanks. 1.4 maintenance stream does show up. I delivered the fix there too. Hence, this is fixed now

Comment 9 Alex Boyko

2010-07-09 12:27:20 EDT

*** Bug 319348 has been marked as a duplicate of this bug. ***

Comment 10 Johannes Michler

2010-07-26 12:19:07 EDT

Created attachment 175237 [details]
Patch according to fix-1

Comment 11 Johannes Michler

2010-07-26 12:20:10 EDT

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.

Comment 12 Alex Boyko

2010-07-26 12:30:13 EDT

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?

Comment 13 Mickael Istria

2011-06-25 09:03:12 EDT

*** Bug 318710 has been marked as a duplicate of this bug. ***