Community
Participate
Working Groups
Build ID: I20090313-0100 Steps To Reproduce: I can reproduce the problem with ports containing labels sticking to nodes. It occurs when a new port containing some text needs to be laid-out. I guess the label is not the reason, but that's how I can reproduce it. 1. Create "New GMF Project" 2. Add My.ecore (attached): + MyRoot + MyNode + MyPort -> portName 3. Derive genmodel, generate model and edit sources 4. Derive gmftool (no tools required to reproduce) 5.1 Derive gmfgraph using MyRoot as Diagram Element (MyNode, MyPort as nodes, portName as attribute) 5.2 set Affixed Parent Side of child-Node MyPort to "NORTH" 6.2 Combine to gmfmap (generate MyNode as node) 6.2 add MyPort as Child Reference including Node Mapping to MyNode Node Mapping 6.3 add Feature Label Mapping to MyPort Node Mapping, displaying portName 7. Run (after generating sources) 8. Initialize my_diagram diagram file <?xml version="1.0" encoding="UTF-8"?> <test:MyRoot xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:test="test"> <myNode> <myPort portName="a"/> <myPort portName="b"/> <myPort portName="c"/> <myPort portName="ddddd"/> </myNode> </test:MyRoot> In case this does not work try to add more ports and increase length of portName-attribute. More information: The application seems to be looping forever in org.eclipse.gmf.runtime.diagram.ui.figures.BorderItemLocator locateBorder trying to getConflictingBorderItemFigure. It works with a decreased text-length of port "ddddd". I'm new to both Eclipse and GMF, so feel free to correct me.
Created attachment 134768 [details] My.ecore - model to reproduce
Looks like defect in org.eclipse.gmf.runtime.diagram.ui.figures.BorderItemLocator. REassiginig to runtime component.
I see that the last issue fixed in BorderItemLocator was the infinite loop in locateOnBorder method bug 243594. The fact that smaller labels make it work sounds familiar... similar to the problem fixed in 243594, when the size of the border item being laid out (located) is smaller then the size of the conflicting border item then problem manifests. Are you sure that your GMF version is 2.2 or 2.1.3? Well... anything after September 2008? If yes, can you attach your generated editor plug-ins please? So, I can debug/fix this for you.
Created attachment 136787 [details] generated model files + default.my to reproduce Yes, I can reproduce it with GMF 2.2.0 Just create a new GMF project called "bugzilla_275288", add the attached model-files, generated sources, run and try to "Initialize my_diagram diagram file" test/default.my. Please let me know if there is anything else I can provide...
Fixed for 2.2. The problem is that we can't use the bounds of the border item until it's laid out, so preferred size of the border item needs to be used. The new #getNextNonConflictingLocation(...) method was looking at the bounds of the border item regardless whether it was laid out or not. In this case it wasn't laid out, so bounds of the border item may not be valid (not included the width of the label in this case), while all other methods were including the size of the label. Henece the next conflicting location was always conflicting with the same border item and hence infinite loop. Anthony, perhaps we'd like to have this fix as 2.1.4 patch as well?
Created attachment 136825 [details] patch committed for 2.2 Trivial fix
Ok, I'd recommend this patch for 2.1.4 patch build. It's a silly mistake that I made and it leads to some serious bad consequences, which clients didn't have to deal with before (regression from 2.1). I think it's worth putting this in a 2.1.4 patch as well. What do you think, Anthony?
Committed the fix to maintenance too.
[target cleanup] 2.2 RC was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug
