RFC Discussion: rfc-04: Widget Input Socket

[github-actions[bot]]

This is the discussion thread for RFC PR #9.

Please provide feedback and discuss the RFC here rather than in the PR comments.

PR Link: #9

[bezo97]

I have a few small remarks for this rfc:

• Regarding "enhanced accessibility - reduces fine motor control requirements compared to context menu usage": I would argue that in this case the drag&drop actually requires more fine-grained motor control than clicking, ie. a single precise drag vs. clicking some buttons (but I'm no expert in the topic). The proposed change would favor quick interactions over accessibilty.
• Aiming to align with Blender's editor is a great approach and I have a suggestion based on that. Instead of disabling the widget when the input is connected, it would be better to hide the widget completely. Firstly it further makes inputs and widgets similar to the user, secondly the user won't falsly believe that the value cannot be changed. See how it looks in Blender:
  
• And a small idea. While dragging the connection, we could highlight node inputs that accept the data type of the connection. The demo animation in the rfc clearly shows that this would help the user pick an input faster.

[huchenlei]

• Regarding "enhanced accessibility - reduces fine motor control requirements compared to context menu usage": I would argue that in this case the drag&drop actually requires more fine-grained motor control than clicking, ie. a single precise drag vs. clicking some buttons (but I'm no expert in the topic). The proposed change would favor quick interactions over accessibilty.

After the initial conversion using the context menu, the user still needs to perform the precise drag&drop with the converted socket.

• Aiming to align with Blender's editor is a great approach and I have a suggestion based on that. Instead of disabling the widget when the input is connected, it would be better to hide the widget completely. Firstly it further makes inputs and widgets similar to the user, secondly the user won't falsly believe that the value cannot be changed. See how it looks in Blender:

Thanks for the suggestion! How does blender handle the unconvertible input, i.e. input type that don't have a literal widget? Is there any visual indication?

• And a small idea. While dragging the connection, we could highlight node inputs that accept the data type of the connection. The demo animation in the rfc clearly shows that this would help the user pick an input faster.

Already mentioned in the RFC. I will make this clear in the basic example section.

[huchenlei]

Follow-up: How does blender handle the unconvertible input, i.e. input type that don't have a literal widget? Is there any visual indication?

[bezo97]

No, they just show up the same way as when they are connected:

[catboxanon]

Seconding that I prefer the behavior of how Blender handles widgets like this.
Another thing Blender does (or rather does not) is the widget remains in place, and does not shift to the top above widgets without an input if said widget has an input connected. The first screenshot shared by bezo97 shows what I mean (Roughness and Normal are not shifted above the widgets w/o an input). Litegraph shifting the order of widgets has never made sense to me.

[huchenlei]

Seconding that I prefer the behavior of how Blender handles widgets like this. Another thing Blender does (or rather does not) is the widget remains in place, and does not shift to the top above widgets without an input if said widget has an input connected. The first screenshot shared by bezo97 shows what I mean (Roughness and Normal are not shifted above the widgets w/o an input). Litegraph shifting the order of widgets has never made sense to me.

Litegraph currently does the shifting because input socket and widget are treated as distinct rendering regions. When this RFC is implemented, the location of input won't shift when switching from widget state to socket state.

[christian-byrne]

Removes the force_input configuration complexity from node definitions

Is the reasoning for removing options like force_input just to eliminate complexity? It seems that force_input (and the inverse of it) will still have value for certain nodes. See example of Blender node with combo that has a socket and combo that does not have socket:

[webfiltered]

I believe force_input still has value, but default_input I appears to be irrelevant. Made suggestion.