Home » Modeling » Graphiti » Moving shapes and bendpoints
Moving shapes and bendpoints [message #1060858] |
Tue, 28 May 2013 16:54 |
Hernan Gonzalez Messages: 188 Registered: October 2010 Location: Buenos Aires, Argentina |
Senior Member |
|
|
In the current implementation DefaultMoveShapeFeature moves also the bendpoints of those FreeFormConnections that originate from the current moving shape and terminates in another selected shape (and hence is presumably part of the same movement).
This seems quite ugly to me, on several levels:
- it couples the DefaultMoveShapeFeature to a particular connections implementation
- it must resort to an ugly hack to guess if that connection is to be "moved", asking, (inside a MoveShapeFeature) the editor for its current selected shapes so as to guess the full set of shapes that are being moved
- the related utility methods are private, so it's difficult to alter the behaviour by overriding
- the bendpoints movement is done directly, not via the MoveBendpointsFeature - so, if (as it was my case) we have the connections with its bendpoints as part of the bussiness model, and relied on MoveBendpointsFeature to keep that in sync, we are rather screwed
I call the attention to this issue, in case the Graphiti developers (supposing they agree) can think on something better - I'm not sure if this has some simple solution. In retrospect, I think it would have been more convenient to specify BendPoints in relative coordinates, with respect to the connection start, but I guess it's too late to change this.
[Updated on: Tue, 28 May 2013 16:57] Report message to a moderator
|
|
|
Re: Moving shapes and bendpoints [message #1060863 is a reply to message #1060858] |
Tue, 28 May 2013 18:10 |
Hernan Gonzalez Messages: 188 Registered: October 2010 Location: Buenos Aires, Argentina |
Senior Member |
|
|
A related observation:
Both MOVE and RESIZE features are single oriented, they work one shape at a time. The upper/internal Graphiti layer is the only who knows if several shapes are being moved/resized (for example, canMove() is called for each shape separatedly, and when the upper layer get a "no" for one of the shapes, and only then, the movement is disabled). This is rather a limitation (and the above is an example), because sometimes one wants to change the behaviour (or the enablement-disablement) according to some "global" criteria: for example, allow only to resize one shape at a time.
Perhaps the ResizeShapeContext could add some "global" context info, eg the total list of shapes involved?
[Updated on: Tue, 28 May 2013 18:16] Report message to a moderator
|
|
| | |
Re: Moving shapes and bendpoints [message #1061262 is a reply to message #1060858] |
Thu, 30 May 2013 20:46 |
Hernan Gonzalez Messages: 188 Registered: October 2010 Location: Buenos Aires, Argentina |
Senior Member |
|
|
Thinking more about it, there seems to be a bunch of problems related to the "local" nature of Graphiti features: Move, Resize, Delete, etc, always deal with single PE, while actually the action involves a group of selected PEs. The makes too difficult to take actions that are related to the whole, be during, before ("canExecute") or after the action. See for example here, how difficult it gets to forbid a group movement that produces overlapping.
I wonder: Wouldn't it be convenient to add group corresponding features, for example a "MoveShapesFeature" which gets, in its context, all the affect PE, and that, in the default implementation, just calls a "MoveShapeFeature" one by one (same about its canExecute() method )? This seems to be backwards compatible, and could lead to a more clean implementation of the current "move bendpoints of FreeFormConnections if both ends correspond to moved shapes" function, and would allow for better extensibility.
[Updated on: Thu, 30 May 2013 20:48] Report message to a moderator
|
|
| | | | | | | |
Goto Forum:
Current Time: Wed Sep 25 07:21:40 GMT 2024
Powered by FUDForum. Page generated in 0.03686 seconds
|