[Bf-committers] expectations about spline-handle type-toggle behavior...

David Jeske davidj at gmail.com
Wed Jul 3 04:24:15 CEST 2013

On Tue, Jul 2, 2013 at 3:41 PM, Bassam Kurdali <bassam at urchn.org> wrote:

> Personally I like this mode, but I could live without it I guess - for me
> it isn't a bug, I often combine vector/aligned or free/aligned. the former
> is more obviously useful, the second only marginally so ( you get one
> handle that keeps the tangent, and only slides in line, and the other
> handle is free to go (it's almost like one is parented to the


You're exactly the user I want to talk to then! Let's see if we can find a
no-compromise solution. I apologize in advance for the long email...

I do see the utility of the vector/aligned and free/aligned behavior. The
part that seems like a "bug" to me isn't the existence of those
combinations, but the reactions of the menu-options.

If I want to grab a handle and move it without affecting the other one, my
expectation, the docs, and the menu name "free" all suggest that I should
click that handle, choose "free", and be able to drag it independently from
the other. Today, this is not the case at all. In fact, I have to select
the OTHER handle (or the center-point), and tell that one to be free, even
though I don't want to move it at all. I found this rather non-intuitive..
in fact, I didn't really understand what was happening until I read the
code.  This is what my current patch changes.

Also, when a handle is "rotation locked" (i.e. the aligned side of
align/free), IMO getting it 'unlocked' is very non-intuitive. In fact you
have to pick the OTHER handle and set it to "align", which is very
confusing. Again, I didn't understand this behavior until I read the code.

Now, let's see if we can keep all the possible spline behaviors while
making the above a bit more intuitive!

One change which is sort-of like the current align/free, align/vector
behavior is adding the ability to scale just a single handle. Currently we
can only scale both handles together by selecting the midpoint. I plan to
add this regardless because I think it'll be useful. I understand this will
not prevent accidentally moving the handle with grab.

* Do you think just the ability to explicitly "scale only one handle" is
enough to remove the need for these align/free and align/vector states?

If we would like to preserve the "parent locking" like behavior of the
current align/free and align/vector, the smallest change I can think of is
to add an additional menu option called "constrain". This would be used to
create the align/free or align/vector state. With one handle selected,
"constrain" would rotation-lock that handle by creating the align/free or
align/vector states -- while the "free" and "align" menu items would create
free/free and align/align respectively. I don't like adding the complexity
of an additional menu item, but I think this would be a *much* simpler user

* Do you agree this will keep today's align/vector and align/free behavior?
Do you see how it's more direct and intuitive, because you choose a handle
and an "verb action" to take on that handle -- rather than having to select
the OTHER handle?

One wrinkle of causing "constrain" to work within the current handle-states
is that constraining both handles will not act as expected. In this case I
would expect both handles to be frozen (something you can't achieve today),
but in fact they will both be draggable as in align/align today.  This can
be fixed by also introducing an additional "constrained" state for each
handle.. this state is like align, except that align/align is movable,
while constrain/constrain is completely locked.

* Do you think it's worth-while to add the ability to lock both handles
with constrain/constrain? Would you use this?

If it is valuable to keep the constrain/free, constrain/vector, and
possibly constrain/constrain states.. I think it would be worth making this
a little clearer with some super-minimal visuals. My thought is to make the
constrained handle look like a small "T" instead of a dot. This would help
visually indicate that you can linearly drag but not rotate it.

* Do you think this visual would be helpful? Too busy?

More information about the Bf-committers mailing list