Re: [Inkscape-devel] Inkscape style connectors - usability suggestion
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.
just as an idea, I would suggest to handle connections more generic. Instead of using default and configurable fixed connection points it would be better to attach directly to the objects outer shape using generic connection points. In this case no predefined connection points need to be shown as the shape is shown in any case. When a handle gets near the shape the shape itself might get highlighted to indicate it will catch the handle when dropped.
When the handle gets dropped near the shape it should connect to the shapes outer sub element (e.g. the nearest line of an rectangle) at an offset from its center calculated from the point of dropping the handle using a calculated normal. The Object would store the connection by adding an additional connection object to its connection list. Each connection object would at least need:
- a reference to the attached handle, - a reference to the shapes sub element, to which the handle is attached - a relative offset from the shapes sub elements center point. - the normal vector to be optionally used for connecting attached line with an angle normal to the outer shape ( eg. for round objects) - sharp edges and the center of an sub element could be made prefered relative positions to snap to
This could allow: * to delete connections when getting disconnected. * no need to handling additional default points * scaling of objects without disturbing the arrangement of the attached handles * allow attachments without code to display additional points/crosses/circles to show the user where he can attach the handle * no need decide in advance on the placement of the default connection point * individual placement by dropping the handle where it should stay * grabbing and moving the handle to a different location along the outer shape
I don't know anything of the code base nor do I have any time to work on this in any capacity but envision the idea could lead to better diagram layout and improved usability.
Hans
Hey Hans,
You've asked for pretty much where the direction of the discussion has gone. I've just taken a hatched to the code to remove the absolute user defined points as well as the code to add them, all the editor mode work and basically I've reverted back to just having a central handle with my additions of having group anchors it works well enough[1] for a system of manually creating your anchors with the xml editor could be.
I think that's what I'm going to call these single point path object is 'svg dots' or just dots for short. Because we've already really over used the term points in the code.
Research continues on the best way to move from a cleaner codebase into providing the adding/deleting functionality required.
Martin,
[1] Will a bug that handles once joined with an object aren't cleared away. oops.
On Sat, 2011-10-01 at 13:22 +0200, Hans-Jürgen Hay wrote:
I don't know anything of the code base nor do I have any time to work on this in any capacity but envision the idea could lead to better diagram layout and improved usability.
Hi Martin,
good to hear, I had suggested the same idea to Dia devs some years ago bud did not get through with it.
There are some nice generic features, that could be envisioned as future extensions, when the design allows for arbitrary placement of connections on the objects outline, like:
- defining layout/placement policies by object template to allow for fancy automatic placement behavior
- automatically sliding anchors (dots) along the object outline, while moving objects on the canvas
- automatically laying out connections equidistantly along a segment of the outline
- restricting placements to a subset of the outline
- storing hints for how lines should connect inside the generic outline anchor (eg. if to attache rectangular or at an angle normal to the shape or at a predefined angle, what arrow shape to default to, etc.).
Hans
You've asked for pretty much where the direction of the discussion has gone. I've just taken a hatched to the code to remove the absolute user defined points as well as the code to add them, all the editor mode work and basically I've reverted back to just having a central handle with my additions of having group anchors it works well enough[1] for a system of manually creating your anchors with the xml editor could be.
Martin,
În data de Sîm 01 Oct 2011 14:22:35 Hans-Jürgen Hay a scris:
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.
just as an idea, I would suggest to handle connections more generic. Instead of using default and configurable fixed connection points it would be better to attach directly to the objects outer shape using generic connection points. In this case no predefined connection points need to be shown as the shape is shown in any case. When a handle gets near the shape the shape itself might get highlighted to indicate it will catch the handle when dropped.
Actually, the idea of the default connection points was to address these „generic” connection points. The question of their visibility is only a secondary one. The main question was: how would these generic connection points be defined?
My idea was to compute a number (8) of points on the outer shape of the object that would correspond to vertices and midpoints for a rectangle, and to north, east, south, west along with north-east, east-south, south-west and west-north directions in the case of a circle or an ellipse.
For a more complex shape the idea was to compute the points which lie along these directions on the outer boundary of the shape. Another idea that appeared on the list was to place a number of equidistant points along the outer boundary of the shape.
These are some ideas to implement generic connection points (as opposed to user defined connection points) that wouldn't be fixed (as maybe you got the impression), any other ideas are welcome.
Regards, Arcadie
When the handle gets dropped near the shape it should connect to the shapes outer sub element (e.g. the nearest line of an rectangle) at an offset from its center calculated from the point of dropping the handle using a calculated normal. The Object would store the connection by adding an additional connection object to its connection list. Each connection object would at least need:
- a reference to the attached handle,
- a reference to the shapes sub element, to which the handle is attached
- a relative offset from the shapes sub elements center point.
- the normal vector to be optionally used for connecting attached line
with an angle normal to the outer shape ( eg. for round objects)
- sharp edges and the center of an sub element could be made prefered
relative positions to snap to
This could allow:
- to delete connections when getting disconnected.
- no need to handling additional default points
- scaling of objects without disturbing the arrangement of the attached
handles
- allow attachments without code to display additional
points/crosses/circles to show the user where he can attach the handle
- no need decide in advance on the placement of the default connection
point
- individual placement by dropping the handle where it should stay
- grabbing and moving the handle to a different location along the outer
shape
I don't know anything of the code base nor do I have any time to work on this in any capacity but envision the idea could lead to better diagram layout and improved usability.
Hans
Hey all,
Yes, I'm top posting... I need to speak up as it seems like Martin really likes his approach and there needs to be a consensus on what approach will be taken (I don't want anyone to possibly "waste" their time). Please let's not refine or "improve" anything quite yet. While I like some things about Martin's approach, I *hate* the group aspect of it. I really think that while the existing and disabled additional connection point interactivity needs some work, IMHO it's probably the better way to go.
Much more important though... perhaps it's most appropriate that we go about this in an *even more difficult* way. Come up with a solid solution that is svg appropriate, create and refine all of the semantics, pitch it to Tavmjong to get his feedback, and in the end submit it to the SVG WG for SVG 2.0. We can be a testing place (as Tav is doing in a branch currently for gradient meshes), namespace everything appropriately, etc.
The key thing is we can sell the idea of these generic connection points. The idea that we want to make animated flowcharts (which would rock imho) and have editing of any flowcharts more friendly. Case in point for it, what's a solid future for flow charts (especially spiffy animated ones)? The web.
But to have things reposition in an animation for instance, we need the ability to "glue" nodes from one path to another. As a path with glued points moves, anything stuck to it goes with it. Note, glue points are an old and well discussed aspect of the project, hopefully I'm not distorting the original intended functionality. I'm sure this will be complex given different connector type (in terms of orthogonal or smooth), but it's worth us investing in IMHO.
tl;dr Let's get well thought out connection/glue point spec submitted to hopefully be accepted into SVG 2.0 proper.
Cheers, Josh
On Sat, Oct 1, 2011 at 5:27 AM, Arcadie Cracan <acracan@...400...> wrote:
În data de Sîm 01 Oct 2011 14:22:35 Hans-Jürgen Hay a scris:
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.
just as an idea, I would suggest to handle connections more generic. Instead of using default and configurable fixed connection points it would be better to attach directly to the objects outer shape using generic connection points. In this case no predefined connection points need to be shown as the shape is shown in any case. When a handle gets near the shape the shape itself might get highlighted to indicate it will catch the handle when dropped.
Actually, the idea of the default connection points was to address these „generic” connection points. The question of their visibility is only a secondary one. The main question was: how would these generic connection points be defined?
My idea was to compute a number (8) of points on the outer shape of the object that would correspond to vertices and midpoints for a rectangle, and to north, east, south, west along with north-east, east-south, south-west and west-north directions in the case of a circle or an ellipse.
For a more complex shape the idea was to compute the points which lie along these directions on the outer boundary of the shape. Another idea that appeared on the list was to place a number of equidistant points along the outer boundary of the shape.
These are some ideas to implement generic connection points (as opposed to user defined connection points) that wouldn't be fixed (as maybe you got the impression), any other ideas are welcome.
Regards, Arcadie
When the handle gets dropped near the shape it should connect to the shapes outer sub element (e.g. the nearest line of an rectangle) at an offset from its center calculated from the point of dropping the handle using a calculated normal. The Object would store the connection by adding an additional connection object to its connection list. Each connection object would at least need:
- a reference to the attached handle,
- a reference to the shapes sub element, to which the handle is attached
- a relative offset from the shapes sub elements center point.
- the normal vector to be optionally used for connecting attached line
with an angle normal to the outer shape ( eg. for round objects)
- sharp edges and the center of an sub element could be made prefered
relative positions to snap to
This could allow:
- to delete connections when getting disconnected.
- no need to handling additional default points
- scaling of objects without disturbing the arrangement of the attached
handles
- allow attachments without code to display additional
points/crosses/circles to show the user where he can attach the handle
- no need decide in advance on the placement of the default connection
point
- individual placement by dropping the handle where it should stay
- grabbing and moving the handle to a different location along the outer
shape
I don't know anything of the code base nor do I have any time to work on this in any capacity but envision the idea could lead to better diagram layout and improved usability.
Hans
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 Josh,
I think the better way would be the SVG standardisation route. But I think we're both aware how long it can take to get standards even into draft. I live in hope.
While I'm not happy about using groups myself, it's certainly possible to use far less code and be consistent with a number of other functionalities. What I'm more unhappy about is creating a new data format which is inconsistent and wholly separate from what has gone before, this is going to lead to large amounts of code and maintenance headaches.
My proposal only requires that we make assumptions for editing. It follows existing rules which means that it invents nothing and doesn't add to the specification to be supported going forwards. It uses exactly what we'll have to support anyway, only the manner in which I've used it exotic.
Of course I'm happy to use what ever approach is best overall, I'd like a few more arguments against groups before I dismiss the concept completely.
Best Regards, Martin Owens
On Sat, 2011-10-01 at 06:07 -0700, Josh Andler wrote:
Much more important though... perhaps it's most appropriate that we go about this in an *even more difficult* way. Come up with a solid solution that is svg appropriate, create and refine all of the semantics, pitch it to Tavmjong to get his feedback, and in the end submit it to the SVG WG for SVG 2.0. We can be a testing place (as Tav is doing in a branch currently for gradient meshes), namespace everything appropriately, etc.
On Oct 1, 2011, at 12:45 PM, Martin Owens wrote:
While I'm not happy about using groups myself, it's certainly possible to use far less code and be consistent with a number of other functionalities. What I'm more unhappy about is creating a new data format which is inconsistent and wholly separate from what has gone before, this is going to lead to large amounts of code and maintenance headaches.
My proposal only requires that we make assumptions for editing. It follows existing rules which means that it invents nothing and doesn't add to the specification to be supported going forwards. It uses exactly what we'll have to support anyway, only the manner in which I've used it exotic.
I think the focus on editing is good here. We can leverage the same front-end code and glue it up to the back end of choice, perhaps flipping as needed.
Martin, Is there much code that can be shared that way, or is the UI hookup going to be dependent on group vs. point-on-path?
Of course I'm happy to use what ever approach is best overall, I'd like a few more arguments against groups before I dismiss the concept completely.
Groups are icky. At least in this case. :-)
On Sat, 2011-10-01 at 06:07 -0700, Josh Andler wrote:
Hey all,
Yes, I'm top posting... I need to speak up as it seems like Martin really likes his approach and there needs to be a consensus on what approach will be taken (I don't want anyone to possibly "waste" their time). Please let's not refine or "improve" anything quite yet. While I like some things about Martin's approach, I *hate* the group aspect of it. I really think that while the existing and disabled additional connection point interactivity needs some work, IMHO it's probably the better way to go.
Much more important though... perhaps it's most appropriate that we go about this in an *even more difficult* way. Come up with a solid solution that is svg appropriate, create and refine all of the semantics, pitch it to Tavmjong to get his feedback, and in the end submit it to the SVG WG for SVG 2.0. We can be a testing place (as Tav is doing in a branch currently for gradient meshes), namespace everything appropriately, etc.
Interest in connectors has been expressed by others in the SVG WG. It is already on the list of possible 2.0 additions. A well thought out proposal would help in getting connectors included, as would an example implementation.
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedba...
The key thing is we can sell the idea of these generic connection points. The idea that we want to make animated flowcharts (which would rock imho) and have editing of any flowcharts more friendly. Case in point for it, what's a solid future for flow charts (especially spiffy animated ones)? The web.
But to have things reposition in an animation for instance, we need the ability to "glue" nodes from one path to another. As a path with glued points moves, anything stuck to it goes with it. Note, glue points are an old and well discussed aspect of the project, hopefully I'm not distorting the original intended functionality. I'm sure this will be complex given different connector type (in terms of orthogonal or smooth), but it's worth us investing in IMHO.
tl;dr Let's get well thought out connection/glue point spec submitted to hopefully be accepted into SVG 2.0 proper.
Cheers, Josh
On Sat, Oct 1, 2011 at 5:27 AM, Arcadie Cracan <acracan@...400...> wrote:
În data de Sîm 01 Oct 2011 14:22:35 Hans-Jürgen Hay a scris:
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.
just as an idea, I would suggest to handle connections more generic. Instead of using default and configurable fixed connection points it would be better to attach directly to the objects outer shape using generic connection points. In this case no predefined connection points need to be shown as the shape is shown in any case. When a handle gets near the shape the shape itself might get highlighted to indicate it will catch the handle when dropped.
Actually, the idea of the default connection points was to address these „generic” connection points. The question of their visibility is only a secondary one. The main question was: how would these generic connection points be defined?
My idea was to compute a number (8) of points on the outer shape of the object that would correspond to vertices and midpoints for a rectangle, and to north, east, south, west along with north-east, east-south, south-west and west-north directions in the case of a circle or an ellipse.
For a more complex shape the idea was to compute the points which lie along these directions on the outer boundary of the shape. Another idea that appeared on the list was to place a number of equidistant points along the outer boundary of the shape.
These are some ideas to implement generic connection points (as opposed to user defined connection points) that wouldn't be fixed (as maybe you got the impression), any other ideas are welcome.
Regards, Arcadie
When the handle gets dropped near the shape it should connect to the shapes outer sub element (e.g. the nearest line of an rectangle) at an offset from its center calculated from the point of dropping the handle using a calculated normal. The Object would store the connection by adding an additional connection object to its connection list. Each connection object would at least need:
- a reference to the attached handle,
- a reference to the shapes sub element, to which the handle is attached
- a relative offset from the shapes sub elements center point.
- the normal vector to be optionally used for connecting attached line
with an angle normal to the outer shape ( eg. for round objects)
- sharp edges and the center of an sub element could be made prefered
relative positions to snap to
This could allow:
- to delete connections when getting disconnected.
- no need to handling additional default points
- scaling of objects without disturbing the arrangement of the attached
handles
- allow attachments without code to display additional
points/crosses/circles to show the user where he can attach the handle
- no need decide in advance on the placement of the default connection
point
- individual placement by dropping the handle where it should stay
- grabbing and moving the handle to a different location along the outer
shape
I don't know anything of the code base nor do I have any time to work on this in any capacity but envision the idea could lead to better diagram layout and improved usability.
Hans
On Sat, Oct 1, 2011 at 1:34 PM, Tavmjong Bah <tavmjong@...8...> wrote:
Interest in connectors has been expressed by others in the SVG WG. It is already on the list of possible 2.0 additions. A well thought out proposal would help in getting connectors included, as would an example implementation.
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedba...
Hey Tavmjong,
That is excellent to know! It now really does appear that coming up with a solid proposal and submitting to the SVG WG is the way to go. At this point my guess is it's all about "connection points" and how they're defined (attribute naming, coordinates/location, etc). Our implementation of how the UI suggests/offers placement is irrelevant for now. What are your thoughts on this Tavmjong, am I off base with the approach?
Cheers, Josh
On Sat, 2011-10-01 at 14:53 -0700, Josh Andler wrote:
On Sat, Oct 1, 2011 at 1:34 PM, Tavmjong Bah <tavmjong@...8...> wrote:
Interest in connectors has been expressed by others in the SVG WG. It is already on the list of possible 2.0 additions. A well thought out proposal would help in getting connectors included, as would an example implementation.
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedba...
Hey Tavmjong,
That is excellent to know! It now really does appear that coming up with a solid proposal and submitting to the SVG WG is the way to go. At this point my guess is it's all about "connection points" and how they're defined (attribute naming, coordinates/location, etc). Our implementation of how the UI suggests/offers placement is irrelevant for now. What are your thoughts on this Tavmjong, am I off base with the approach?
Cheers, Josh
Turns out there is already the start of a Connectors SVG spec. Check out:
http://dev.w3.org/SVG/modules/connector/SVGConnector.html
Despite the statement that the document is not ready for public comments, it would be useful for people to have a look at it and post comments on inkscape-devel. I can bring them up at an SVG Working Group meeting.
Tav
On Sat, 2011-10-01 at 14:53 -0700, Josh Andler wrote:
On Sat, Oct 1, 2011 at 1:34 PM, Tavmjong Bah <tavmjong@...8...> wrote:
Interest in connectors has been expressed by others in the SVG WG. It is already on the list of possible 2.0 additions. A well thought out proposal would help in getting connectors included, as would an example implementation.
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedba...
Hey Tavmjong,
That is excellent to know! It now really does appear that coming up with a solid proposal and submitting to the SVG WG is the way to go. At this point my guess is it's all about "connection points" and how they're defined (attribute naming, coordinates/location, etc). Our implementation of how the UI suggests/offers placement is irrelevant for now. What are your thoughts on this Tavmjong, am I off base with the approach?
I will have a chance to discuss connectors in person with the SVG working group at the SVG Open conference next week. It would help to have feedback from the proposal at:
http://dev.w3.org/SVG/modules/connector/SVGConnector.html
Tav
participants (6)
-
Arcadie Cracan -
Hans-Jürgen Hay -
Jon Cruz -
Josh Andler -
Martin Owens -
Tavmjong Bah