[Background for inkscape-devel readers: Ted found that when the connected-to object was a <rect>/SPRect, updates to the connector positions seemed to lag by one move.
I found that <text> behaved similarly, but that no other elements had that problem.
I also found that if the connected-to object was in a group, then moving the group doesn't emit a `transformed' signal.
In the case of clones (SPUse), it's unclear whether the clone should move in parallel with the move of the containing group. As a user I'd have expected the clone to move, but if I think about the SVG representation then the current behaviour makes sense, in that having the clone move in parallel with group moves would involve changing the transform on the clone.]
Ted's rectangle test case now works. Text also now works, but not through any work of mine. (I'd guess because someone recently made sp_text_set_transform essentially a no-op.)
I haven't yet addressed the case of connecting to something that's inside a group (that the other object isn't in).
It might be interesting if you posted these observations [about why <text> and <rect> had the problem and no other shapes] to the list -- I'd be curious if there was a good reason for this.
In the case of SPRect, the problem was that its bbox is calculated from its SPShape information, but sp_rect_set_transform modified only the SPRect-specific data, it didn't call sp_rect_set_shape to update the SPShape data.
The fix options were either
- Provide an SPRect-specific bbox method rather than inheriting SPShape's implementation.
- Add a call to sp_rect_set_shape from sp_rect_set_transform.
I decided to do the latter, in case there were any other users of the SPShape information that would otherwise lag.
pjrm.
So where's the test file itself? Is there anything we can try already?
On Mon, Aug 16, 2004 at 12:34:54AM -0300, bulia byak wrote:
So where's the test file itself? Is there anything we can try already?
Nothing we can announce to users, just enough for me to play about with graph layout using inkscape instead of dia.
Caveats:
- There is no UI at all, unless you count the XML editor. E.g. there's no tool for creating connectors, nor do connectors disconnect or reconnect when you move the end point of a connector away from or to an object.
- Currently, any edits to curves are lost when either object is moved. Maybe this will be the next thing I'll work on.
- The XML representation should probably change.
- Implemented by listening for SPItem->_transformed signal. Consequences:
- As noted in previous message, there is a bug if the connector is attached to something inside a group, and the group moves or is transformed: the connector won't be notified.
- Using the node-edit tool on an attached object doesn't cause the connector to update. However, interestingly, `Simplify curve' does cause an update. I'll have to look into this.
- When dragging an attached object with the mouse, the connector doesn't update until the mouse is released.
Connectors are represented in XML by a <path> element with attributes inkscape:connection-start and inkscape-connection-end, each with a value of e.g. "#rect1023".
There's no notion of attachment points/magnets as in Dia/Visio/Omnigraffle. We just connect to a point on the bounding box of the attached shape, the point that a line to the object centre would pass through.
(I don't claim that we wouldn't want to support attachment points / magnets, it's just that the current behaviour is better for what I'm using connectors for.)
Simple test case appended. Uses rectangles, so try to use CVS later than 2004-08-16 01:03 +0000.
pjrm.
<svg xmlns="http://www.w3.org/2000/svg" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" style="stroke: #000"> <rect id="rect1" x="20" y="20" width="120" height="80" fill="none" /> <rect id="rect2" x="210" y="25" width="100" height="70" fill="none" /> <path inkscape:connection-start="#rect1" inkscape:connection-end="#rect2" d="M 140,60 L 210,60" /> </svg>
On Mon, Aug 16, 2004 at 02:39:35PM +1000, I wrote:
However, interestingly, `Simplify curve' does cause an update. I'll have to look into this.
`Simplify curve' typically triggers sp_item_write_transform in sp_selected_path_simplify_withparams.
pjrm.
Today it crashes when I try to move a rect in the sample file.
at least it loads.
--- bulia byak <buliabyak@...400...> wrote:
Today it crashes when I try to move a rect in the sample file.
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
But yesterday, it did more than that :)
On Mon, 16 Aug 2004 13:41:10 -0700 (PDT), John Cliff <simarilius@...36...> wrote:
at least it loads.
--- bulia byak <buliabyak@...400...> wrote:
Today it crashes when I try to move a rect in the sample file.
Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
On Mon, Aug 16, 2004 at 05:22:38PM -0300, bulia byak wrote:
Today it crashes when I try to move a rect in the sample file.
Thanks for the info. *runs it* Ah, I've fixed that at home without committing. *edit* Now I've committed to CVS what I think I did at home. Still haven't tested much, but it doesn't crash.
The current code in CVS preserves the shape of the connector (modulo a form of rotation/scaling), but the calculation of which point on the bounding box to use doesn't take the curve shape into consideration. This is most noticeable a problem when the two attached objects are very close to each other (e.g. overlapping), in which case we'd like the connectors to be able to come from the "sides" of the two objects.
There are a number of ways of modifying a curve to have different end points (e.g. different distance or direction) while retaining the "same" curviness. Different transforms do the right or wrong thing for different cases.
An affine transform would be the first thing that comes to mind. E.g. rotate then scale. When stretching/squashing, it's not clear whether we should scale uniformly or scale just in the direction of the new angle. E.g. suppose that the end points lie on a horizontal line and the user's just dragging left & right. Should we scale just the x coordinates or scale x and y coordinates by the same amount? Just-x can be desirable when the new points are very far from each other, whereas both-equally can be better if the new x distance is less than the old y height of the curve.
The main thing to be careful of when using an affine transform is not to lose information if the new distance is zero. Perhaps use the path's transform= attribute, or make the path invisible if the new distance is zero.
The way I've implemented it is not an affine transform on the path. It's vaguely spring-like, in that the amount that each point of the curve is moved is proportional to how far along the curve that point is rather than what its position is. For bezier segments, I've used a simple approximation to that rather than try to refit a new curve to an exact transformation.
At some point in the future we may allow playing around with different choices for how the curve is transformed, but we can't make a fair comparison until we improve said calculation of where to attach to to take curve shape (end tangents) into consideration.
[Allowing choice of connector shapes would be good in future]
Most interesting for us is getting connectors to choose a good route that tries to avoid crossing other "objects". This requires that the software know what objects should be avoided, and what objects deliberately overlap or come close to the connector. Similarly, it is often desirable that certain objects not overlap each other. State charts are interesting, in that objects A1 & A2 mustn't overlap each other, while objects B1 & B2 are required to overlap (and be contained within) A1, while not overlapping each other.
pjrm.
There are a number of ways of modifying a curve to have different end points (e.g. different distance or direction) while retaining the "same" curviness. Different transforms do the right or wrong thing for different cases.
Here's the behavior I would love to see (not saying it's the best, but it's what I often do manually in diagrams):
1 Preserve the user-set position of the attachment points relative to the bboxes of the connected objects (in % of width/height of a connected object), allow it to be changed manually by dragging the endnode of the connector; make it at 50% (center of one of the four sides) by default. Rationale: connectors going to corners rarely look good, especially with rects.
2 Preserve the direction of the bezier handles at the connector's endnodes. That is, if an endnode runs into the object at 90 degrees, preserve that angle no matter how the object is moved.
3 Scale the length of the bezier handles at the connector's endnodes based on the distance between connected objects (more precisely their attachment points). That is, if objects become 2 times closer, the handles become 2 times shorter.
4 If the connector has midnodes, their positions and bezier handles must be simply scaled proportionally in both dimensions. E.g. if the startnode and endnode are on the same vertical, then the horizontal projection of all bezier handles of midnodes is zeroed.
Variation: when the relative position of the connected objects flips in one of the dimensions, you can flip the corresponding connector: that is, move it to the opposide side of the bbox and flip the bezier handles correspondingly.
This behavior could be implemented as one of the possible "styles" of connections, with a way for the user to switch styles as needed. Your current behavior could be another style. I attach a manual example of how the above described style could look in a diagram.
- As noted in previous message, there is a bug if the connector is attached to something inside a group, and the group moves or is transformed: the connector won't be notified.
I think _transformed should fire when the parent group is moved, too. It's intuitively expected.
- Using the node-edit tool on an attached objecgt doesn't cause the connector to update. However, interestingly, `Simplify curve' does cause an update. I'll have to look into this.
Simplify just replaces a path with another one with the same id, which causes everyone who references it to reattach and therefore update. If you want update on any change, you need to listed to the object's modified signal (it's not sigc yet, but old g_ stuff)
There's no notion of attachment points/magnets as in Dia/Visio/Omnigraffle. We just connect to a point on the bounding box of the attached shape, the point that a line to the object centre would pass through.
(I don't claim that we wouldn't want to support attachment points / magnets, it's just that the current behaviour is better for what I'm using connectors for.)
Would also be nice if it could use other connector styles besides the straight line.
participants (3)
-
bulia byak -
John Cliff -
Peter Moulder