Hey Devs,
I've got a plan for getting last year's connector work into use. I've updated the branch to the latest trunk (damn you changes!) so I'd like to get this merged in because it removes 1110 lines and replaces them with 91. So it's a big cleanup of code that was never in use:
https://code.launchpad.net/~doctormo/inkscape/knot-visio
This branch should maintain the same functionality as we currently have, plus a focus on the next steps to improve the functionality. Testing is required and advice for more experienced cpp developers about the use of std::map instead of a more appropriate std::list structure which I'm hoping can be picked up in merge review.
The next steps are the exciting parts. I thought the idea from last year about having a generic point anchor tool was really interesting. So the way the connector work will happen is, it'll simply use other non-connector functionality to achieve everything we want.
The anchor tool would insert a point path, which would be displayed on screen with either an knot-anchor which would just move along with it, or some other visual identifier which would not appear in renders. It would be selectable using the near-detection and then groupable, transformable etc because it's a real point element on the canvas.
The anchor tool would be useful for a few functionalities. For the connector work we would use the point to join connectors together on canvas, as custom points on shapes when grouped with them, act as flexible points where custom paths around objects are required.
This offers the best combination of features while not requiring any custom attributes or elements and doesn't require a exo-canvas def addition (which would suck IMO). It's also groovy because the amount of code will be small and use lots of existing code to achieve what we want.
Best Regards, Martin Owens
Note: Apologies to all the wonderful responses in the thread last year, a week after my daughter was born and I fell of the productive Internet and only now is my time freeing up a bit.
Hi Martin,
Good news that your back working on connectors and congrats on the birth of your daughter!
Doug Schepers has been actively working on an SVG connectors specification. He hasn't released a draft yet but maybe we can persuade him to. It would be good if you can look at it and comment on it.
Our implementation of connectors should be as compatible as possible with the draft (but in the Inkscape namespace to avoid a repeat of the flowed text debacle). As I understand it, the specification will include "anchor" points on objects to define where connectors attach. The points will be located in a coordinate system given by the bounding box of the object (prior to any transformations). Optionally, a path can be given to connect anchor points. If a path is not given, a very simple algorithm will be specified to determine how the connecting path will be drawn. More complex path layout will be left to the content creator (e.g. Inkscape).
As I've commented before, symbols and connectors are natural to use together. The new Symbols Dialog would be more useful if symbols included connector anchor points.
Tav
On Sun, 2012-12-02 at 23:57 -0500, Martin Owens wrote:
Hey Devs,
I've got a plan for getting last year's connector work into use. I've updated the branch to the latest trunk (damn you changes!) so I'd like to get this merged in because it removes 1110 lines and replaces them with 91. So it's a big cleanup of code that was never in use:
https://code.launchpad.net/~doctormo/inkscape/knot-visio
This branch should maintain the same functionality as we currently have, plus a focus on the next steps to improve the functionality. Testing is required and advice for more experienced cpp developers about the use of std::map instead of a more appropriate std::list structure which I'm hoping can be picked up in merge review.
The next steps are the exciting parts. I thought the idea from last year about having a generic point anchor tool was really interesting. So the way the connector work will happen is, it'll simply use other non-connector functionality to achieve everything we want.
The anchor tool would insert a point path, which would be displayed on screen with either an knot-anchor which would just move along with it, or some other visual identifier which would not appear in renders. It would be selectable using the near-detection and then groupable, transformable etc because it's a real point element on the canvas.
The anchor tool would be useful for a few functionalities. For the connector work we would use the point to join connectors together on canvas, as custom points on shapes when grouped with them, act as flexible points where custom paths around objects are required.
This offers the best combination of features while not requiring any custom attributes or elements and doesn't require a exo-canvas def addition (which would suck IMO). It's also groovy because the amount of code will be small and use lots of existing code to achieve what we want.
Best Regards, Martin Owens
Note: Apologies to all the wonderful responses in the thread last year, a week after my daughter was born and I fell of the productive Internet and only now is my time freeing up a bit.
Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2012-12-03 at 09:40 +0100, Tavmjong Bah wrote:
Doug Schepers has been actively working on an SVG connectors specification. He hasn't released a draft yet but maybe we can persuade him to. It would be good if you can look at it and comment on it.
Yes, do you have a link for this work?
Our implementation of connectors should be as compatible aspossible with the draft (but in the Inkscape namespace to avoid a repeat of the flowed text debacle). As I understand it, the specification will include "anchor" points on objects to define where connectors attach.
That thinking doesn't exist in the branch any more. The idea of specifying in particular custom points on objects as attributes is clumsy and will require vast amounts of code to make it work like we want. But I haven't seen the svg draft specification.
As I've commented before, symbols and connectors are naturalto use together. The new Symbols Dialog would be more useful if symbols included connector anchor points.
There would be no connector anchor point, there would only be anchor points which could be optionally used with the connector tool.
Martin,
On Mon, 2012-12-03 at 09:49 -0500, Martin Owens wrote:
On Mon, 2012-12-03 at 09:40 +0100, Tavmjong Bah wrote:
Doug Schepers has been actively working on an SVG connectors specification. He hasn't released a draft yet but maybe we can persuade him to. It would be good if you can look at it and comment on it.
Yes, do you have a link for this work?
In principle it is:
http://dev.w3.org/SVG/modules/connector/SVGConnector.html
But this is wildly out-of-date. I am hoping that Doug will provide a more recent version. He has said he is close to having something that he will make public. Maybe this will motivate him to get it out!
Our implementation of connectors should be as compatible aspossible with the draft (but in the Inkscape namespace to avoid a repeat of the flowed text debacle). As I understand it, the specification will include "anchor" points on objects to define where connectors attach.
That thinking doesn't exist in the branch any more. The idea of specifying in particular custom points on objects as attributes is clumsy and will require vast amounts of code to make it work like we want. But I haven't seen the svg draft specification.
I believe the idea is to have anchor points as elements that are children of the objects they are in. Doug can correct me.
Clearly the old (Inkscape) idea of having a few fixed, predetermined anchor points independent of the shape on the corners and sides is not a good one. But it is highly desirable that an object/symbol be able to have well defined anchor points that are part of the object/shape. Consider the logical symbol for a NAND gate[1], you would want to have anchor points at the two inputs and the one output. You definitely do not want to have to add anchor points every time you make a copy of the symbol.
As I've commented before, symbols and connectors are naturalto use together. The new Symbols Dialog would be more useful if symbols included connector anchor points.
There would be no connector anchor point, there would only be anchor points which could be optionally used with the connector tool.
Martin,
Tav
On Mon, 2012-12-03 at 16:19 +0100, Tavmjong Bah wrote:
http://divajutta.com/doctormo/inkscape-as-visio.ogv
This is the video from last year, I think the idea is the same. The element might be different but using point paths or some new element from the svg spec doesn't matter.
Martin,
On Mon, 2012-12-03 at 11:18 -0500, Martin Owens wrote:
On Mon, 2012-12-03 at 16:19 +0100, Tavmjong Bah wrote:
Looks good. How are the connecting points ('X's) determined?
This is the video from last year, I think the idea is the same. The element might be different but using point paths or some new element from the svg spec doesn't matter.
Martin,
Tav
On Mon, 2012-12-03 at 19:11 +0100, Tavmjong Bah wrote:
Looks good. How are the connecting points ('X's) determined?
In that example:
<g> <p d="m x,y z"/> ... other parts of the shape ... </g>
Simple test of path points count == 1. It's simple and quite flexible, I was able to control them even without near-detection.
Martin,
On 3-12-2012 19:29, Martin Owens wrote:
On Mon, 2012-12-03 at 19:11 +0100, Tavmjong Bah wrote:
Looks good. How are the connecting points ('X's) determined?
In that example:
<g> <p d="m x,y z"/> ... other parts of the shape ... </g>
Simple test of path points count == 1. It's simple and quite flexible, I was able to control them even without near-detection.
Hmm, this might bug. One example I can think of: paths with only one point do get markers rendered; does a path inherit style from its parent? Perhaps it is better to add an Inkscape-specific connector attribute?
Ciao, Johan
On Mon, 2012-12-03 at 20:52 +0100, Johan Engelen wrote:
Hmm, this might bug. One example I can think of: paths with only one point do get markers rendered; does a path inherit style from its parent? Perhaps it is better to add an Inkscape-specific connector attribute?
Interestingly the SVG draft spec says that markers are desirable; although direction was a concern.
Using a different element, like the point elements from the draft, wouldn't be a problem. It's the same solution with a distinctive name.
But using a connector attribute is not good. They break the distinction between on-canvas 'things' and the properties of those things. As well as being out of scope for transformations, styles and other desirable features such as canvas points.
Martin,
On 3-12-2012 21:11, Martin Owens wrote:
On Mon, 2012-12-03 at 20:52 +0100, Johan Engelen wrote:
Hmm, this might bug. One example I can think of: paths with only one point do get markers rendered; does a path inherit style from its parent? Perhaps it is better to add an Inkscape-specific connector attribute?
Interestingly the SVG draft spec says that markers are desirable; although direction was a concern.
Using a different element, like the point elements from the draft, wouldn't be a problem. It's the same solution with a distinctive name.
But using a connector attribute is not good. They break the distinction between on-canvas 'things' and the properties of those things. As well as being out of scope for transformations, styles and other desirable features such as canvas points.
I actually don't understand your last paragraph, but ok :) Somehow it seems problematic to use an svg path to store Inkscape-editor data. Why not change the "<p ..." into "<inkscape:conn_point...". True it is more verbose, and you will have to add code to handle transformations etc, but it results in a cleaner SVG I think.
I guess you can move the single-point paths with the nodetool. Is that a desired feature, or a nuisance?
-Johan
On Mon, 2012-12-03 at 22:28 +0100, Johan Engelen wrote:
I actually don't understand your last paragraph, but ok :) Somehow it seems problematic to use an svg path to store Inkscape-editor data.
Seems, can you specify problems with a any use of a canvas element?
Why not change the "<p ..." into "<inkscape:conn_point...". True it is more verbose, and you will have to add code to handle transformations etc, but it results in a cleaner SVG I think.
Because
1) these points are not connector points but anchor points. Generic single point canvas elements. Maybe <point or <inkscape:point 2) They're not just editor specific, if the draft spec goes in then we want to be in a good place for animation of these points later. 3) Custom tranformations. That'll result in a mess of code we need not make. A complexity... which isn't necessary. Avoid. 4) Messier svg thanks to inkscape specific elements (with underscores!) not cleaner svg.
I don't mind using a custom element of course, the old 'inkscape:conn-points' attribute design was a complete nightmare of design which I would not replicate.
So, a path with a single point is a point with no current use, we want points; There they are. My point was to use existing points for anchor points of all kinds. Changing that to a new element, so long as it's a canvas element like the path, I don't think is bad either.
I guess you can move the single-point paths with the nodetool. Is that a desired feature, or a nuisance?
Sounds like a feature to me. Although unions will kill the association so bugs over there maybe.
Martin,
On 3-12-2012 23:37, Martin Owens wrote:
On Mon, 2012-12-03 at 22:28 +0100, Johan Engelen wrote:
I actually don't understand your last paragraph, but ok :) Somehow it seems problematic to use an svg path to store Inkscape-editor data.
Seems, can you specify problems with a any use of a canvas element?
I don't know what you mean by a canvas element. A path is a rendered object in final output. An anchor point is something that should not be rendered (right?), and is more something like the rotation center of a group. The rotation center of a group is what I also call a canvas element, as is the flashing helper path, etc. The rotation center is not stored as an svg:path because that would make no sense.
Why not change the "<p ..." into "<inkscape:conn_point...". True it is more verbose, and you will have to add code to handle transformations etc, but it results in a cleaner SVG I think.
Because
- these points are not connector points but anchor points. Generic
single point canvas elements. Maybe <point or <inkscape:point 2) They're not just editor specific, if the draft spec goes in then we want to be in a good place for animation of these points later.
These are not reasons to use single point paths for anchor points; as you propose you could use <point..>. These two points are reasons supporting changing the "<p.." into something else. The spec will most certainly not use svg:path for the anchor points. If you want to be in good shape when the spec makes it, you want to already have the code for special anchor point SVG objects (/elements/leaves/whatever).
- Custom tranformations. That'll result in a mess of code we need not
make. A complexity... which isn't necessary. Avoid.
So what happens when I ungroup the group with your anchor-point-paths in it? Going to special-case that, or "neatly" add the anchor points to the parent group? What if someone fixes applying markers to a group of paths (does not work at the moment), going to special-case that too? Paths are selectable too, what if someone goes into the group, selects part of it by dragging a selection box and unavoidably selects an anchor point and runs some extension on it... ? Defining anchor points as paths is buggy... which isn't necessary. Avoid.
- Messier svg thanks to inkscape specific elements (with underscores!)
not cleaner svg.
Identifying a lack of imagination for a good name makes for a bad counter-argument. Surely it can't be messy if one calls an anchor point an "anchor point" in SVG?
I don't mind using a custom element of course, the old 'inkscape:conn-points' attribute design was a complete nightmare of design which I would not replicate.
So, a path with a single point is a point with no current use, we want points; There they are.
As I wrote earlier, single point paths do have a use.
My point was to use existing points for anchor points of all kinds.
Except that the "existing points" (paths, really) are rendered objects, and hence unsuitable for anchor points.
Changing that to a new element, so long as it's a canvas element like the path, I don't think is bad either.
I'm glad you agree with my suggestion of making special anchor point elements. I see we may have a misunderstanding about "connector points". I'm unfamiliar with the terminology of the connector tool code / works. When I wrote my earlier email, I thought of connector points as points to do with the connector tool. So re-read the mail replacing connector points by anchor points, and connector attribute by anchor point attribute/element/leaf/whatever you call svg thingies.
I guess you can move the single-point paths with the nodetool. Is that a desired feature, or a nuisance?
Sounds like a feature to me. Although unions will kill the association so bugs over there maybe.
Great that you found a resulting bug yourself. Yes it is a feature if the node tool can edit the anchor points, but it should not treat them as path points and there would not be a way to tell the difference if you define anchor points as single-point paths.
(editing single point paths with the node tool is broken at the moment btw, I thought we had that working but it doesn't in trunk).
-Johan
I know we're arguing for the same side. Just getting there from a different place.
On Tue, 2012-12-04 at 00:31 +0100, Johan Engelen wrote:
I don't know what you mean by a canvas element.
paths, circles, squares are all canvas elements. They are a) xml elements and b) on the canvas/page as things.
A path is a rendered object in final output. An anchor point is something that should not be rendered (right?),
Not really. Anchor points can be rendered, or not rendered. Much like a line can be visible... or not visible. I think that was the point of the markers in the spec.
and is more something like the rotation center of a group. The rotation center of a group is what I also call a canvas element, as is the flashing helper path, etc. The rotation center is not stored as an svg:path because that would make no sense.
Well yes, because a center is an attribute of an element, while a point is an element in and of itself. It's a different kind of shape which can be optionally grouped with other shapes to provide the needed concept.
These are not reasons to use single point paths for anchor points; as you propose you could use <point..>. These two points are reasons supporting changing the "<p.." into something else. The spec will most certainly not use svg:path for the anchor points.
Which is a shame ;-) but I'm just hoping the spec will be more generic than the draft published so far.
So what happens when I ungroup the group with your anchor-point-paths in it? Going to special-case that, or "neatly" add the anchor points to the parent group?
No, having free floating points is a feature. Points don't have to be in groups, part of their charm is that they could be free floating.
What if someone fixes applying markers to a group of paths (does not work at the moment), going to special-case that too?
No, that would be a feature... might possibly have to think about the spec with the direction though.
Paths are selectable too, what if someone goes into the group, selects part of it by dragging a selection box and unavoidably selects an anchor point and runs some extension on it... ?
Awesome things will happen. These point shapes are not meant to be hidden from the user, nor is their nature. Selecting them should be possible.
Defining anchor points as paths is buggy... which isn't necessary. Avoid.
It's not distinctive, but it isn't as buggy as it appears.
Surely it can't be messy if one calls an anchor point an "anchor point" in SVG?
Not at all; names is names. I'm more keenly interested in the idea the point should be a shape rather than any attribute.
As I wrote earlier, single point paths do have a use.
What use?
Except that the "existing points" (paths, really) are rendered objects, and hence unsuitable for anchor points.
Both are rendered objects, usefully so.
Great that you found a resulting bug yourself. Yes it is a feature if the node tool can edit the anchor points, but it should not treat them as path points and there would not be a way to tell the difference if you define anchor points as single-point paths.
That's a valid destinction point. Perhaps inheriting path code to produce the desired function with a new point element to avoid confusion in editing nodes.
Martin,
participants (3)
-
Johan Engelen -
Martin Owens -
Tavmjong Bah