make node handle "selectable"

[ScislaC]

If the node handles could be selectable like the
gradient handles, that would be extremely helpful.
Essentially, you can click on it to select it, not just
to only directly manipulate it.

A couple immediate benefits I can think of would be
moving via arrow keys and alignment of handles.

[Buliabyak-users (buliabyak-users)]

This would make the node tool interface extremely messy. And
in fact you can already scale/rotate handles without
selecting them - try the <>[] keys with a node selected.

[ScislaC (scislac)]

If it is an option in preferences, it doesn't make it
extremely messy unless you choose for it to be... unless you
are talking about code that is.

The scaling and rotating handles isn't at all what I'm
referencing either (that's a little more uniform and less
flexible than what I'm talking about). What I'm looking for
is much more precise control of the specific handles which
just doesn't exist currently.

The ability to move node handles by arrow keys, just as you
can move gradient handles, would make our node controls
significantly more powerful. Also, the ability to use
alignment on the node handles (which would have to be pretty
basic of course) would also add much more control.

I just know that keyboard positioning is much more precise
than mouse positioning when not workin with the grid on.

An example of the level of precision I'm looking for is that
if I have two nodes, and take the inside handles (closer one
to the other node on the same path) and have the ability to
move the handles 3 arrow presses and 1 shift+arrow towards
each other and then 4 key presses downward. I know that the
respective handles will be precisely the same
distance/position in relation to their nodes. Unfotunately,
you can't achieve that with the current key commands for the
nodes because they rotate the whole node as well as
increase/decrease length of both node handles (when
applicable), not just the chosen handle.

I can ramble off many other benefits as well, but it's
something that other vector editors don't have and it adds a
level of precision and control that we'd be the first to
have. At the very least if we had some UI to numerically
modify the handle locations in relation to the "parent"
node, other than the XML editor, it would be a step in the
right direction.

[Buliabyak-users (buliabyak-users)]

> If it is an option in preferences, it doesn't make it
extremely messy unless you choose for it to be...

It's a very basic thing, and you should not normally make
basic things configurable. It WILL be a mess if only because
it will make documenting it much harder - way too many "If
you have this option set do this, otherwise do that" clauses.

> The scaling and rotating handles isn't at all what I'm
referencing either (that's a little more uniform and less
flexible than what I'm talking about). What I'm looking for
is much more precise control of the specific handles which
just doesn't exist currently.

You can control them with pixel precision now (with Alt).
What can be more precise than that?

> The ability to move node handles by arrow keys, just as you
can move gradient handles, would make our node controls
significantly more powerful.

Not really more powerful than now, and besides the
rotation/scaling metaphor makes much more sense for handles
than x/y moving.

> Also, the ability to use
alignment on the node handles (which would have to be pretty
basic of course) would also add much more control.

You can achieve alignment now, at least as well as you would
with arrow key movements.

> I just know that keyboard positioning is much more precise
than mouse positioning when not workin with the grid on.

Of course, that's why I added []<> keys for handles.

>An example of the level of precision I'm looking for is that
if I have two nodes, and take the inside handles (closer one
to the other node on the same path) and have the ability to
move the handles 3 arrow presses and 1 shift+arrow towards
each other and then 4 key presses downward. I know that the
respective handles will be precisely the same
distance/position in relation to their nodes. Unfotunately,
you can't achieve that with the current key commands for the
nodes because they rotate the whole node as well as
increase/decrease length of both node handles (when
applicable), not just the chosen handle.

No. You can rotate/scale either each handle separately, or
both, depending on which modifiers you use. Look it up in
the keys&mouse reference. In this specific case, you can
achieve the same symmetry by pressing e.g. ] twice and the >
three times on each node, with corresponding Ctrls (left or
right) for each one.

> I can ramble off many other benefits as well, but it's
something that other vector editors don't have and it adds a
level of precision and control that we'd be the first to
have.

Exactly, this is why I added the scale/rotate keys for
handles, and Inkscape is indeed the first to have it :)

> At the very least if we had some UI to numerically
modify the handle locations in relation to the "parent"
node, other than the XML editor, it would be a step in the
right direction.

This is true, and it has always been in my plans to add
numeric fields for nodes and handles to the node tool controls.

[ScislaC (scislac)]

>You can control them with pixel precision now (with Alt).
What can be more precise than that?

But I see it as adding a modifier key to something that
doesn't really need it... if I select a node handle and can
nudge it around with 1 finger via arrow keys, sweet...
having to hold Alt and then toggle between functions of
rotate/scale just seems more cumbersome than necessary (not
invalidating it's usefulness though).

>Not really more powerful than now, and besides the
rotation/scaling metaphor makes much more sense for handles
than x/y moving.

As with most things, I think that needs/workflow/process/use
dictate what makes more sense... I do soooo much tweaking of
nodes (and everything else) via the arrow keys and would do
the same to the handles if the ability was there. I don't
see why gradient handles (specifically for radial gradients)
are so different in your mind than node handles... they're
control handles anchored at some other point. Why does X,Y
not make sense for one, but it does for the other? I know
that with gradient handles specifically it has a locked
rotation, but it's really pretty similar as it's a control
handle of sorts.

>You can achieve alignment now, at least as well as you would
with arrow key movements.

I'm sorry, I wasn't too clear... the alignment I was
referencing would be through the align palette/dialog, not
via keys... if by keys, you are correct. But if you could
select node handles that weren't moved with precision to
begin with, it would be nice to be able to align them like
you can with objects & nodes (perhaps the distribution
function could even be used as a percentage based on
distance from nodes and the other available control handles).

>Of course, that's why I added []<> keys for handles.

I know those work well, but to be able to bump around via
arrows makes for much easier movement. It takes much less
thought for me to click on a handle and bump a couple times
one way and a couple in another (because the arrows point
the direction it would move), as opposed to having to think
about which Alt or Ctrl key to hold with using <>[].. which
aren't as straight forward unless you them frequently and
have already looked it up in the appropriate reference material.

>No. You can rotate/scale either each handle separately, or
both, depending on which modifiers you use. Look it up in
the keys&mouse reference. In this specific case, you can
achieve the same symmetry by pressing e.g. ] twice and the >
three times on each node, with corresponding Ctrls (left or
right) for each one.

You can do that on Linux, but not Win32... ; ) I'll go file
a bug report on it tonight... but if this can't be achieved
on win32, my solution would work perfectly in it's place.

>Exactly, this is why I added the scale/rotate keys for
handles, and Inkscape is indeed the first to have it :)

But having X,Y control on top of rotation/distance would
make it even better...

>This is true, and it has always been in my plans to add
numeric fields for nodes and handles to the node tool controls.

Perhaps I'll go file an RFE for it then if one doesn't
already exist so it doesn't have to only remain in your head.

I just think that if you ca...

[Buliabyak-users (buliabyak-users)]

> having to hold Alt and then toggle between functions of
rotate/scale just seems more cumbersome than necessary

Not really, most of the time I need to adjust EITHER length
OR angle, not both. It's just more natural. Hence the
different keys.

> I don't
see why gradient handles (specifically for radial gradients)
are so different in your mind than node handles...

Because in gradients, there's no such thing as nodes and
node handles. There are only nodes, and they all are equally
selectable. In node tool, traditionally only nodes are
selectable, not node handles. Changing that will break A LOT
of things.

To be specific: I'm not against using arrow keys on node
handles (even though I think scale/rotate make more sense
for them, but I would be happy to provide BOTH), but I'm
stronly against _making them selectable_. This will be a
disaster both in the code and in usability. The node
selecting interface will become so complex and unpredictable
that we'll be buried in bug reports and complaints.

So, if you can think up a way to apply arrow keys to node
handles _without selecting_ them in any way, please submit a
separate RFE on that.

> I'm sorry, I wasn't too clear... the alignment I was
referencing would be through the align palette/dialog

To me it does not make much sense to apply Align or
Distribute to node handles. Can you construct a persuasive
use case?

> as opposed to having to think
about which Alt or Ctrl key to hold with using <>[]

I just made this easier (was always going to fix this, you
gave me the incentive :). Now e.g. left Ctrl always moves
the handle which is towards the VISUALLY left neighbor node,
not "previous" node as before.

> You can do that on Linux, but not Win32... ; ) I'll go file
a bug report on it tonight...

Please do.

> but if this can't be achieved
on win32, my solution would work perfectly in it's place.

I don't think it's a good idea to change such fundamental
aspect as selection in response to a minor bug.

>This is true, and it has always been in my plans to add
numeric fields for nodes and handles to the node tool controls.

> Perhaps I'll go file an RFE for it then if one doesn't
already exist

I think there's such an RFE.

If you close this again, I guess I'll drop it, but I really
feel this does have a place in Inkscape...

As I wrote, if you can invent a way to achieve what you need
without selecting node handles, please submit it. Otherwise
I remain opposed.

[jahvascriptmaniac (jahvascriptmaniac)]

Hi !
I don't think having the ability to select handles would be a mess at all :

Look at Blender.

Just make any random bezier curve, and look at what you have :
Nodes & handles.

(right-)Click on a node, you have the node & both handles selected, so you know you have the whole node.
You can move it, resize it (which actually resizes both hadles distance), rotate it (rotates the handles) etc.
Just like what we have in inkscape.

Now (right-)click on a handle, you have the handle selected, so you know you have only the handle (the node itself & the other handle are non-highlighted).
You can move it, resize it, etc.

Now select both handles from a node : the whole node is highlighted, just like in case 1. It's logical : having both handles selected actually selects the whole node, it feels actually quite intuitive.

Now make a circle and select the handle that folows each node going clockwise (so if you were inside the circle, you could say that the right handles of each node is selected, but not the left ones.
Then you can transform this group of nodes quite intuitively. If you resize them, they'll get further away from the center of the 4 handles (that is, the center of the circle here), which gives a blob aspect to your circle.

All this is quite intuitive and when I got to discover this in blender, I wasn't surprized at all to be able to edit my handles separately from their nodes with the usual tools (grab, rotate, size, etc.)

There's one problem in blender's implementation : it's that a right-click (the usual selection tool) selects the closest handle / node so you can't select a segment in one click like you can in inkscape, but this could be easily fixed by selecting a handle / node only when you click ON IT, not the closest one. This way we would keep the cool "select a segment feature"

But there's also one very cool feature, it's that you have a pointer, which isn't a "physical" object, it's just a purely virtual point that you can place at the center of you selection, on the grid, etc. and then place an object on it.
You can set a handle's position to be on the pointer, which allows you to recopy handle positions from other objects, for example. I used this a lot when working with blender.

As inkscape implements that wonderfull "show node handles" button, the handle-selecting facility would be available only when handles are shown, so this would be even better - in no-handles mode, you'd be sure to allways select the whole node.

Just play a few minutes with blender, and you'll see that it's quite nice and not a mess at all.

Hope I convinced you :-) otherwise I'll have to learn CPP or edit my curves under blender and re-import under inkscape (yuck).

[bbyak (buliabyak)]

I still don't see what's the value in having a handle selected if in Inkscape you can just as well scale and rotate handles by selecting their node. And you can easily do that blob thing by selecting all nodes and using <> keys. As for pasting position, for that we now have toolbar editable fields for node coordinates, and Max wanted to add the same for handles too.