Bug 504728 - Overlapping lines
Summary: Overlapping lines
Status: NEW
Alias: None
Product: Ecoretools
Classification: Modeling
Component: General (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows NT
: P3 normal
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-10-06 10:44 EDT by Ed Willink CLA
Modified: 2016-11-07 11:44 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2016-10-06 10:44:39 EDT
In the Ecore Editor the layout seems to have an enthusiasm for overlapping lines. This is very confusing since relationships appear to be missing.

IMHO distinct relationships should NEVER overlap.

The overlap is doubly irritating given the difficulty of selecting one and then moving it rather than the selection migrating.
Comment 1 Cedric Brun CLA 2016-10-10 09:51:36 EDT
Hi Ed, 

We basically rely on GMF and GEF for the routing of the edges, I have not checked yet if "Eclipse Layout Kernel" could help in this area.

could you be more specific whether you experienced this on a specific type of relationships (like EReferences, or supertypes, or link to doc annotation) ?

Is this "enthousiasm" during arrange all ? when you are creating shapes and adding relationships ?
Comment 2 Ed Willink CLA 2016-10-10 10:24:31 EDT
I have variously started with a new 'add all' file, and subsequently with 'add related elements' I haven't used rearranges, just automated layouts.

I have seen both EReferences and inheritance colliding. Inheritance collision is of course intentional and quite desirable. However it seems to have the side effect that some inheritance edges cannot be moved by dragging the edge even though dragging the end does work.

My suspicion is that the 'add' that provokes multiple line additions ignores some snap to grid rules giving repetitive off-grid edges. These can only be moved by grid increments and so remain obstinately off-grid. If there are four connections on a side, a multi-snap is required to position all four ends distinctly but nonetheless on grid.

IIRC Papyrus that similarly relies on GMF and GEF manages to keep associations distinct but struggles to keep generalizations colliding; repositioning a superclass can require considerable cosmeric fixups.
Comment 3 Cedric Brun CLA 2016-11-07 11:44:46 EST
Setting this ticket as triaged for futher consideration.