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.

[zombieyang]

This is a great RFC, I implemented something similar to this in my custom node before. If this feature is merged, I will switch to this immediately.

But I wonder if this demand can be satisfied: 2 or more widget share 1 socket, when the socket is connected, all of them will grayed out.

I implemented this logic in my case (document and layer share 1 input), and I think the seed and control_after_generate in KSampler is something the same.

[kaalibro]

There is a bug that prevents you from resizing a node to the minimum size.

1.10.4.mp4

1.10.2.mp4

[Amorano]

I guess my comment, after using it now in 1.10.4, is why have any conversion logic and not just have all the widgets WITH an input and leave the field with defaults?

If someone plugs in an input, great, it gets the overrides. If not, then the defaults are passed through which are sitting there already set.

Is there a reason it has to be explicitly set to be an input or a widget and not just have the logic pass through the defaults as set if nothing is connected?

Why over-complicate =D

[Steudio]

The current visual representation of a connected widget is misleading. A grayed-out widget implies that the current value is "987841673473018" and cannot be altered because it is connected. However, the actual value being passed is "8"

To resolve this inconsistency, the widget should either:

Display a blank value when connected, or

Show the actual value being passed.

[gshawn3]

@Steudio: You are right that it would be confusing. Looks like this was merged in two weeks ago in Comfy-Org/ComfyUI_frontend#3326... @huchenlei now that this has shipped, should we keep providing feedback here or is it better to open new issues in the ComfyUI_frontend repo?

[christian-byrne]

If you have actionable request for change of this feature, it would make more sense to make the request on https://github.com/Comfy-Org/ComfyUI_frontend, since the commenting period has already ended for this RFC.