Inkscape with Visio style connectors
Something that's been missing for a while is the ability to set arbitrary connection points on objects so we can use visio style workflows with connectors doing more work for us.
May I draw you collective attention to this demonstration video:
http://divajutta.com/doctormo/inkscape-as-visio.ogv
Here I show off a workflow hack (using nautilus as a stencil) and an genuine edmun scream style code hack to 0.48x branch mod'ing the connector-context code which you can find here:
https://code.launchpad.net/~doctormo/inkscape/knot-visio
It works by enabling rectangles inside groups to act as child center points. Each of the items you see me drag in the video is a group and each connector is a very tiny rectangle. I hacked it like this because now transforms also transform the new connector points and the amount of code I had to modify is quite small.
It also fixes a bug with connectors where connected elements when grouped would not be able to be updated. I added a parent group transform signal catch for 1 level deep which should help with that.
Anyway, as a proof of concept I humbly submit this idea to the rest of the developers here for review.
Best Regards, Martin Owens
Martin Owens <doctormo@...400...> writes:
Something that's been missing for a while is the ability to set arbitrary connection points on objects so we can use visio style workflows with connectors doing more work for us.
May I draw you collective attention to this demonstration video:
http://divajutta.com/doctormo/inkscape-as-visio.ogv
Here I show off a workflow hack (using nautilus as a stencil) and an genuine edmun scream style code hack to 0.48x branch mod'ing the connector-context code which you can find here:
https://code.launchpad.net/~doctormo/inkscape/knot-visio
It works by enabling rectangles inside groups to act as child center points. Each of the items you see me drag in the video is a group and each connector is a very tiny rectangle. I hacked it like this because now transforms also transform the new connector points and the amount of code I had to modify is quite small.
It also fixes a bug with connectors where connected elements when grouped would not be able to be updated. I added a parent group transform signal catch for 1 level deep which should help with that.
Very interesting! I've also tried to improve the existing connector code but your approach seems much farther along. Would any of this hit trunk soon?
Anyway, as a proof of concept I humbly submit this idea to the rest of the developers here for review.
Best Regards, Martin Owens
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1_________________________________________... Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
joakim@...1974... writes:
Martin Owens <doctormo@...400...> writes:
Something that's been missing for a while is the ability to set arbitrary connection points on objects so we can use visio style workflows with connectors doing more work for us.
May I draw you collective attention to this demonstration video:
http://divajutta.com/doctormo/inkscape-as-visio.ogv%3E Here I show off a workflow hack (using nautilus as a stencil) and an genuine edmun scream style code hack to 0.48x branch mod'ing the connector-context code which you can find here:
https://code.launchpad.net/~doctormo/inkscape/knot-visio%3E It works by enabling rectangles inside groups to act as child center points. Each of the items you see me drag in the video is a group and each connector is a very tiny rectangle. I hacked it like this because now transforms also transform the new connector points and the amount of code I had to modify is quite small.
It also fixes a bug with connectors where connected elements when grouped would not be able to be updated. I added a parent group transform signal catch for 1 level deep which should help with that.
Very interesting! I've also tried to improve the existing connector code but your approach seems much farther along. Would any of this hit trunk soon?
I wanted to try your hack. I checked out the code but can't seem to figure out how to enable it.
Also, I'm curious why the connector redrawing in your video seems to be done at the same time the connected object moves. In my case the connectors are only redrawn after the object move is finished.
Do you move the objects with keyboard?
Anyway, as a proof of concept I humbly submit this idea to the rest of the developers here for review.
Best Regards, Martin Owens
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1_________________________________________... Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hey Joakim,
My approach is... a combination of existing structures to create the desired function without actually writing anything new (as such). That's the the patch is about 40 lines and it took me 6 hours to write, even though I spent half my time learning more about the inkscape code base.
It might be that by reconsidering the problem of connector points, we can avoid writing clever code and just stick to simple mechanisms.
On Fri, 2011-09-30 at 15:49 +0200, joakim@...1974... wrote:
I wanted to try your hack. I checked out the code but can't seem to figure out how to enable it.
Also, I'm curious why the connector redrawing in your video seems to be done at the same time the connected object moves. In my case the connectors are only redrawn after the object move is finished.
Do you move the objects with keyboard?
I move objects with mouse and keyboard, the signals only redraw after the signal is finished. Just as your probably does.
You need to create a group of objects, and inside that group create some rectangles. Leave the group and try the connector again.
Martin,
On Sep 29, 2011, at 9:36 AM, Martin Owens wrote:
Something that's been missing for a while is the ability to set arbitrary connection points on objects so we can use visio style workflows with connectors doing more work for us.
One thing that was worked on a bit was specifying connector points as points some distance along a path. That basically leverages the calculations used for text on path starting points, etc.
When the connectors were being worked out, I was told that most of the could would be able to handle multiple potential connection points in general, but the code to get them in as source was not done.
It might be worth looking into, since it sounds like you're on track with at least some other of the connectors cleanup.
On Fri, 2011-09-30 at 01:55 -0700, Jon Cruz wrote:
When the connectors were being worked out, I was told that most of the could would be able to handle multiple potential connection points in general, but the code to get them in as source was not done.
The code had a few errors which prevented multiple connectors working, but on the whole that's to be expected when the logic was never tested. I can say however that it did appear to be leaning heavily towards multiple points, although there is a lot of code which didn't seem to do anything, or at least nothing I could activate.
It might be worth looking into, since it sounds like you're on track with at least some other of the connectors cleanup.
The text of a path stuff is interesting, but what the connector work needs is relative coords. So I cheated by using the center points in child objects of groups. At the moment I detect only rectangles inside a group, but I think a better solution would be to use an inkscape attribute on the object probably loaded in sp_item or sp_object.
The only difficulty is having groups where some of the child objects are deliberately invisible to the renderer but are used as connector points for functionality. Mixing on canvas elements and editor information is something I don't like, but this solution was too interesting not to try.
Not sure if the connector code can be cleaned up, it's hard to know what we have and what we want it to continue to do.
Martin.
On Fri, Sep 30, 2011 at 11:04 AM, Martin Owens <doctormo@...400...> wrote:
On Fri, 2011-09-30 at 01:55 -0700, Jon Cruz wrote:
When the connectors were being worked out, I was told that most of the could would be able to handle multiple potential connection points in general, but the code to get them in as source was not done.
The code had a few errors which prevented multiple connectors working, but on the whole that's to be expected when the logic was never tested. I can say however that it did appear to be leaning heavily towards multiple points, although there is a lot of code which didn't seem to do anything, or at least nothing I could activate.
It might be worth looking into, since it sounds like you're on track with at least some other of the connectors cleanup.
The text of a path stuff is interesting, but what the connector work needs is relative coords. So I cheated by using the center points in child objects of groups. At the moment I detect only rectangles inside a group, but I think a better solution would be to use an inkscape attribute on the object probably loaded in sp_item or sp_object.
The only difficulty is having groups where some of the child objects are deliberately invisible to the renderer but are used as connector points for functionality. Mixing on canvas elements and editor information is something I don't like, but this solution was too interesting not to try.
Not sure if the connector code can be cleaned up, it's hard to know what we have and what we want it to continue to do.
At one point we already had connector code to add/move/remove additional connector points. However, it ended up either getting commented out or removed because it didn't work how it should. Specifically, the student who created it did not follow how other tools work, when you clicked it would not set the point, if I recall correctly you had to hit the Enter key. So it was actually really straightforward stuff that just never fixed. I seem to recall telling them to disable it prior to a release on the sole basis that it was unintuitive and it didn't work like every other tool in Inkscape.
I'm not sure if resurrecting that code and fixing it up or a modified version of your new approach is the right way to go. Did you happen to notice a bunch of commented out code when browsing through the connector stuff? If it was deleted, it's still somewhere in the revision history at least to see which might be better.
Cheers, Josh
On Fri, Sep 30, 2011 at 12:01 PM, Josh Andler <scislac@...400...> wrote:
If it was deleted, it's still somewhere in the revision history at least to see which might be better.
And because ~suv is full of magic...
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/9104
Thanks ~suv for throwing that my way!
Cheers, Josh
În data de Vin 30 Sep 2011 22:18:19 Josh Andler a scris:
On Fri, Sep 30, 2011 at 12:01 PM, Josh Andler <scislac@...400...> wrote:
If it was deleted, it's still somewhere in the revision history at least to see which might be better.
And because ~suv is full of magic...
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/9104
Thanks ~suv for throwing that my way!
The three comments in the toolbox.cpp disable the UI for adding/removing connection points. Remove the comments to restore the (rather rudimentary) functionality.
Cheers, Josh
--- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2011-09-30 at 12:01 -0700, Josh Andler wrote:
Did you happen to notice a bunch of commented out code when browsing through the connector stuff? If it was deleted, it's still somewhere in the revision history at least to see which might be better.
I noticed lots of code that wasn't commented out, but which seemed to have no reason. possibly not switched on. In any case the file should probably be stripped of the old code once we've got general consensus on the approach.
Considering the code and the use of stencils, I propose using groups as specified. Feedback and critique is needed.
Additionally we should have a curved connector option, and some preset styles for markers and lines. And some better code to control the jagged connectors.
Martin,
În data de Vin 30 Sep 2011 23:11:31 Martin Owens a scris:
On Fri, 2011-09-30 at 12:01 -0700, Josh Andler wrote:
Did you happen to notice a bunch of commented out code when browsing through the connector stuff? If it was deleted, it's still somewhere in the revision history at least to see which might be better.
I noticed lots of code that wasn't commented out, but which seemed to have no reason. possibly not switched on. In any case the file should probably be stripped of the old code once we've got general consensus on the approach.
As in the reply to Josh's mail, you would have to uncomment the lines in toolbox.cpp (check the diffs from the link Josh (~suv, thank you) provided) to get the basic (unpolished) functionality.
Martin, thank you for all your work. It was me who initially coded the connection points code. It left in a rather unpolished state, although the core functionality was coded. I got really busy with my phd work (which I am soon to finish and would really much like to come back to properly fix connection points and connectors).
I watched the demo you made, it is really impressive and really close to what was intended. Still, I don't follow the reason of introducing the ConnPointChild type, but I guess it is my fault as the code is not that much verbose.
The main idea was to have two types of connection points: some default connection points (as currently only the center is) and user defined connection points. There would be 9 default connection points: the center (the only one available now) and other 8 connection points that you get when you draw 8 imaginary lines that connect the center to the corners of the object's bounding box and the midpoints of the edges of the object's bounding box and intersect these imaginary lines with the object's edge.
In the case of a rectangle (as in your video) the four connection points located at the middle of the rectangle's edges would be just default connection points (so the would be no need for ConnPointChild type?). The code that needs to be written to make this happen would be located in: src/conn-avoid-ref.cpp, in Geom::Point SPAvoidRef::getConnectionPointPos(const int type, const int id), where there should be a big switch for the default connection point type in which one would compute the intersections I mentioned above.
Then, in src/connector-context.cpp, in static void cc_set_active_shape(SPConnectorContext *cc, SPItem *item), next to cc_active_shape_add_knot(cc->desktop, item, cc->connpthandles, centre); (line 1707 in your branch) one should have to add the knots for the rest of the default connection points.
Sorry for being scarce with explanations, I hope some points about the code got cleared up.
Thank you again for the great work!
Arcadie
Considering the code and the use of stencils, I propose using groups as specified. Feedback and critique is needed.
Additionally we should have a curved connector option, and some preset styles for markers and lines. And some better code to control the jagged connectors.
Martin,
--- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hey Arcadie,
It's great to hear from you, thanks for the review, more below...
On Sat, 2011-10-01 at 00:48 +0300, Arcadie Cracan wrote:
I don't follow the reason of introducing the ConnPointChild type, but I guess it is my fault as the code is not that much verbose.
Your code uses ConnPointUserDefined and ConnPointDefault as a way of defining not only where the nodes would go but also how the lines would be drawn once you created a connector point.
I'm using ConnPointChild to tell the knot creator to draw an X rather than a square knot for the user to click on. That's all. I could be using it to switch on the parent group signal handle, but I figured it was just better to switch that on for all groups.
The main idea was to have two types of connection points: some default connection points (as currently only the center is) and user defined connection points.
I think there is a conceptual error in your design for this functionality. Your model has only two parties: programmers and users. Programmers make code which automatically computationally offers presets for generic objects i.e. center, users define arbitrary and use once creations which are specific to that creative work.
The third set of people missing are the templators. People who create objects similar to what you can see in the video, they don't want the computational stuff in their way as it's too ridged and they certainly don't want arbitrary and error prone mouse inputs. If templators have to edit the svg directly in order to produce the stencils and templates required for productive use in inkscape, they can and then ship them out to users.
with the concept of a third way safely understood we can see how simply having the ability to insert arbitrary points is insufficient, you also need to be able to move them in relation to the creation. I made a lot of use of align and distribute functionality to get my points into the correct locations and I imagine it would be a dis-pleasurable experience trying to click on a specific pixel or move it with the keyboard.
There would be 9 default connection points: the center (the only one available now) and other 8 connection points that you get when you draw 8 imaginary lines that connect the center to the corners of the object's bounding box and the midpoints of the edges of the object's bounding box and intersect these imaginary lines with the object's edge.
Some objects will not want those extra 8 points, the start/end flowchart objects for instance should not have them for fear of confusing new students in the art of flowcharting.
which one would compute the intersections I mentioned above.
It's possible that we should have computational points, but they should be defined by the shape's dynamics. Triangles should have 7 points, hexagons 13, etc. Moving the computational work out of detection of bounding boxes and into the shape code would make it cleaner and clearer how it works.
one should have to add the knots for the rest of the default connection points.
Fairly easy, but data should come from the item about which points to use.
Thank you again for the great work!
Let me know when you're finished with your PhD work, it'd be nice to work with you on this. also please do continue to talk with me about the idea. I'm on IRC if that helps.
Martin,
On Fri, Sep 30, 2011 at 3:28 PM, Martin Owens <doctormo@...400...> wrote:
Hey Arcadie,
It's great to hear from you, thanks for the review, more below...
I will also add, it's nice to you around again. :)
The third set of people missing are the templators. People who create objects similar to what you can see in the video, they don't want the computational stuff in their way as it's too ridged and they certainly don't want arbitrary and error prone mouse inputs. If templators have to edit the svg directly in order to produce the stencils and templates required for productive use in inkscape, they can and then ship them out to users.
with the concept of a third way safely understood we can see how simply having the ability to insert arbitrary points is insufficient, you also need to be able to move them in relation to the creation. I made a lot of use of align and distribute functionality to get my points into the correct locations and I imagine it would be a dis-pleasurable experience trying to click on a specific pixel or move it with the keyboard.
Just to get it on the list. Perhaps we can make mouse input less clumsy and error prone by coordinating with Diederik. If we have the ability for snapping to nodes and such when adding/moving connection points it could greatly speed up the creation process for these objects and would also bring about precision to the workflow.
Some objects will not want those extra 8 points, the start/end flowchart objects for instance should not have them for fear of confusing new students in the art of flowcharting.
which one would compute the intersections I mentioned above.
It's possible that we should have computational points, but they should be defined by the shape's dynamics. Triangles should have 7 points, hexagons 13, etc. Moving the computational work out of detection of bounding boxes and into the shape code would make it cleaner and clearer how it works.
This definitely sounds very useful. I'm curious how we go about this though given your comment above about some objects that should not have these additional points. Would we add a button to the tool controls bar to creating the computed points? Obviously we can't have it automatically create them because it would mess with the above scenario you want to avoid.
Let me know when you're finished with your PhD work, it'd be nice to work with you on this. also please do continue to talk with me about the idea. I'm on IRC if that helps.
Seconded, please do let us know. We may be able to coordinate a small hackfest for anyone who really wants to work on this (hopefully Michael Wybrow would take part) to really make the connector tool feel like a complete tool. Obviously we would need get board approval for travel funding and such, but it's generally something that the board has found favorable in the past.
Lastly, because it's somewhat related... http://libregraphicsworld.org/blog/entry/the-ultimate-quest-of-bringing-visi...
Cheers, Josh
On 10/01/2011 01:20 AM, Josh Andler wrote:
with the concept of a third way safely understood we can see how simply having the ability to insert arbitrary points is insufficient, you also need to be able to move them in relation to the creation. I made a lot of use of align and distribute functionality to get my points into the correct locations and I imagine it would be a dis-pleasurable experience trying to click on a specific pixel or move it with the keyboard.
Just to get it on the list. Perhaps we can make mouse input less clumsy and error prone by coordinating with Diederik. If we have the ability for snapping to nodes and such when adding/moving connection points it could greatly speed up the creation process for these objects and would also bring about precision to the workflow.
Ofcourse I will take care of the snapping. What's even more, we can use these custom points for snapping too, not just for attaching the connectors to. It's been requested a few times before to implement configurable snap points, see for example
https://bugs.launchpad.net/inkscape/+bug/667372 https://bugs.launchpad.net/inkscape/+bug/172093
Maybe we should call the connector points "anchor points" instead, if they're going to serve multiple purposes.
Diederik
Thanks to discussions I've pushed a small modification that changes my logic from any rectangle in a group to any single point path in a group being considered a connector point.
Testing indicated that this point can be selected using the bounding box, but not the click. It also transforms, has a center and does everything in a sane way.
If I tie the creation of user defined connection points to the creation of a single point path in the target group object, would anyone find it very objectionable?
Martin,
Hello Martin,
În data de Sîm 01 Oct 2011 11:54:58 Martin Owens a scris:
Thanks to discussions I've pushed a small modification that changes my logic from any rectangle in a group to any single point path in a group being considered a connector point.
Testing indicated that this point can be selected using the bounding box, but not the click. It also transforms, has a center and does everything in a sane way.
This is great!
If I tie the creation of user defined connection points to the creation of a single point path in the target group object, would anyone find it very objectionable?
I would still like that user defined connection points are added to this single point path at the moment of creation, so that they would still be „special” paths, given the additional attribute of connection points. In this way we would not need to treat these path in a special way (although they cannot be created from the UI), but rely on the user defined connection points.
In order to get the syntax for user defined connection points you can activate those buttons which are currently disabled and add some connection points to a shape, then inspect the shape's connection-points attribute.
Best regards, Arcadie
Martin,
--- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Oct 1, 2011, at 1:54 AM, Martin Owens wrote:
Thanks to discussions I've pushed a small modification that changes my logic from any rectangle in a group to any single point path in a group being considered a connector point.
Testing indicated that this point can be selected using the bounding box, but not the click. It also transforms, has a center and does everything in a sane way.
If I tie the creation of user defined connection points to the creation of a single point path in the target group object, would anyone find it very objectionable?
Might be time to take a peek at what the current Dia behavior is for shapes and connection points.
participants (6)
-
unknown＠example.com -
Arcadie Cracan -
Diederik van Lierop -
Jon Cruz -
Josh Andler -
Martin Owens