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