Improve RelationshipView

[Matthias Schoettle]

Currently, RelationshipView contains dependencies to views that use it for their relationships. In updateLines() there are different cases depending on the views the relationship is connected between. This should be removed. Furthermore, getting the position of the views cannot always be performed with the current approach (call to getLocalVecToParentRelativeSpace(view, getBounds().getVectorsLocal()[0])).

I suggest the following:

• updateLines() is responsible for figuring out the position of the ends and calls setPosition() on the ends
• sub-classes can define (if necessary) how to get the position of a view, override a method getViewPosition().
• the view of an end must implement an interface with methods to handle position changes etc.
  • moveRelationshipEnd
  • updatePosition (former setCorrectPosition, I think this takes care of positioning the ends on one side correctly)
• updateLines() can then call the appropriate methods of the views depending on whether the position has changed or not

[Matthias Schoettle]

It used to be global, but was changed in commit 1753aca. Not sure why. It should be fine to use the global position for comparing the locations of views between each other.

[Matthias Schoettle]

To draw "self relationships" drawAllLines() checks whether the views of both ends are the same. Maybe this could be delegated to a method isSelfRelationship() which by default performs this check.

For messages the views of the ends are different, but the lifelines are the same (or simply isSelfMessage() returns true).

[Matthias Schoettle]

References issue #109: Revert back changes from commit 1753aca to use global position. This should work for all relationships independent of what their containment hierarchy is, because their position compared to each other is relevant.

→ <<cset dc6ed8801b1d>>

[Matthias Schoettle]

References issue #109: Added a new interface that should be implemented by all views representing a relationship end.

This is a preparation step for this issue as more changes are required. For example, views need to extend RamRectangleComponent and implement IRelationshipEndView.

→ <<cset 07c93bd76e01>>

[Matthias Schoettle]

As pointed out by Romain, the removeRelationshipEnd method in the IRelationshipEndView interface should be removed. It is the responsibility of the view containing the end to remove it, not the end itself.