[Bf-funboard] node editor UI behavior questions

David Jeske davidj at gmail.com
Sun Jul 28 22:43:53 CEST 2013

On Sun, Jul 28, 2013 at 9:48 AM, Bassam Kurdali <bassam at urchn.org> wrote:

> I also find this one less useful - it might be a good idea to limit it
>  to specific situations where the inputs are equivalent? for instance,
> inputs for math nodes, or color mix nodes, or shader mix nodes, where
> the old and new wires are going into the same type of thing (values to
> be math'ed, colors or shaders to be mix) but remove the behavior in
> other situations.

Why not just only have this input-shifting behavior occur during a swap?
This allows the current visual metaphors to completely explain behavior...

If you swap two inputs they swap. If you drop a new input ontop, it always
overwrites (disconnecting the previous input). If you want to "push aside"
the existing input onto another input, you can either move it first then
connect the new, or you can drop the new onto the other input and swap them.

This is the behavior I intuitively expect out of the node editor. I don't
understand why it would ever "push down" an input into a random other slot
because I'm dropping something on top of it. It's very unpredictable
behavior, because it only happens when there actually is a free input to
push it onto.

> I **really** like the way I can drop a node directly onto a connection to
> > splice it in. And I **really** wish it did the opposite when removing
> > (closing the gap), at least if the deleted-node was a 1-video to 1-video
> > node. Thoughts?
> yeah, that exists, with a key modifier. a bit hard to remember for me!

I see that. I wonder if it would be better to have the "connect-through on
delete" be the default when there is an obvious single in/out path.

In the end this isn't that big of a deal, as it's easy to learn to create
the new node and "switch" things over to the new node before deleting the
old one... This also serves as a slightly more general way to handle it if
there are lots of inputs and/or outputs.

More information about the Bf-funboard mailing list