On Mon, 14 Mar 2005 09:43:36 -0500, Kevin Wixson <kevin@...738...> wrote:
I have a question about it though. When trying it out I discovered a peculiar behavior with the adjacent nodes to the one converted with the "make node smooth" command. In order to move it twice, you have to click off the object in between moves or you pull out a control handle.
Yeah, I knew you would notice that :) I'm aware of this problem but I'm not yet sure how to best fix it. Your proposal:
Cusp nodes will never have control handles, even when they're adjacent to smooth nodes.
is not possible because in SVG, each path fragment is either a line or a curve. If it's a line, none of its ends have control handles, otherwise both have. We can't have it midway, and actually I don't think we need. It's not a problem; the problem is just the user interface to this.
I cannot fix it simply by making a node always selectable in preference over its handles (if the handles are at the same point), because in that case you would never be able to drag out the handles even if you need them, which is bad.
A similar problem is in Selector where sometimes you start dragging a wrong object instead of the one you had selected. To fix it there, I added Alt+drag which always drags the selected object no matter where you start the drag. I think a similar approach can be used here: make Alt+drag always drag the selected node(s) no matter where you start the drag, or whether some handles are in the way. Will that work for you?
Or alternatively, I can make nodes always selectable and draggable in preference to handles, but also provide a way to drag _out_ a handle if it's retracted (e.g. by dragging with Shift, similar to un-merging merged gradient handles with Shift). Will this be better?
Then if they want one of those control handles to be in the node, they can use the Ctrl+click on the control handle feature (which is brilliant, by the way) to make that happen.
For the reasons above, ctrl+click does not actually remove the handle, it just retracts it back to the node.
By the way, I'm struggling with terminology. I take "cusp" to mean a node that doesn't have control handles and does not influence the direction of the line, as opposed to a "corner" node, which has control handles that can move in independent directions, and "smooth" which has control handles in the same plane but are different lengths, and "symmetric" which has control handles in the same plane and with the same length. Is this correct?
No, a cusp is a node whose handles can rotate independently. It's still cusp if any of its handles are retracted to the node itself. I think we don't have a name for a node that sits between two straight line segments and therefore has no handles at all; it may be called "corner". However we don't want this to be a separate node type that you can turn a node into, because (again, for reasons above) this would affect the other ends of its segments too, which is often not desirable. My latest change was to treat the "corner" node the same as cusp when converting type, i.e. add handles to it when making it smooth. Now you understand that this necessitated converting the neighboring "corner" nodes to cusps with retracted handles.
So, I think that if we will be able to drag a node with retracted handles, but ALSO some way to drag out a retracted handle (with Shift), then just regular cusp nodes with retracted handles can for all intents and purposes be undistinguishable from "corner", and we won't need "corner" as a separate type. Dragging out a handle with Shift can be made to work even for true corner nodes - it will just have to convert the adjacent fragment to curve first. I think this will be quite convenient, will keep the list of node types from unneeded growth, and will mostly eliminate the need to use the clumsy "convert segment to line/curve" buttons.