Connector Work

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Connector Work

doctormo
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

Tavmjong Bah

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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

doctormo
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 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.

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 natural
> to 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,


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

Tavmjong Bah
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 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.
>
> 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 natural
> > to 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

[1] https://en.wikipedia.org/wiki/NAND_gate




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

doctormo
On Mon, 2012-12-03 at 16:19 +0100, Tavmjong Bah wrote:
>
> [1] https://en.wikipedia.org/wiki/NAND_gate 

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,


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

Tavmjong Bah
On Mon, 2012-12-03 at 11:18 -0500, Martin Owens wrote:
> On Mon, 2012-12-03 at 16:19 +0100, Tavmjong Bah wrote:
> >
> > [1] https://en.wikipedia.org/wiki/NAND_gate 
>
> http://divajutta.com/doctormo/inkscape-as-visio.ogv

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




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

doctormo
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,


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

Johan Engelen-4
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

doctormo
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,


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

Johan Engelen-4
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

doctormo
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,


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

Johan Engelen-4
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
>
> 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.

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).

> 3) 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.

> 4) 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


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connector Work

doctormo
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,


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel