Add an extended number widget with support for annotations

[AustinMroz]

Frequently, number widgets will have values with special meaning, but these values are not always intuitive. For example, setting cfg to 1.0 disables it even though cfg can be set to less than 1.

This adds three additional options to FLOAT and INT inputs. If any of these is present, the widget is converted to an annotatedNumber on node creation, similar to how multiline string inputs function.

• reset adds a button to the side to the side of the node to reset it to some chosen value. This does not need to be the same as the default value.
• disable similarly, adds a button to set the widget to quickly select a value that disables the widgets associated action. If both disable and reset are assigned values, reset takes priority and disable is only shown when the value is already at the assigned reset value
• mappedValues is a map of potential widget values to strings. When the widget is assigned to the chosen value, the given string is displayed next to it.

While the implementation is currently functional, the design is tentative and feedback is appreciated.

[JorgeR81]

Great Idea ! 

This can be useful for so many nodes !

[JorgeR81]

this does not need to be the same as the default value.

This would be very useful. For instance, I would prefer to reset to a cfg of 7.0 instead of 8.0
Any ideas on how the user could set this up ?

Maybe a right click node option to set current values as default ?
And also restore node defaults ( to revert the changes ).

[JorgeR81]

I also like the GUI design.

The only downside is not having the option names aligned.
Have you thought about putting the icons on the right side?

[AustinMroz]

Button placement is my greatest undertainty. I was strongly considering moving it to be between the left arrow and the option name, but I quite like your suggestion.

I had not considered letting end users configure defaults, but I can see it being quite useful. I imagine it's better to have a user configured default be tied to node type instead of a node instance, so it would likely be implemented as part of user state. I'll look into it, but it's probably best pushed to a subsequent pull request.

[asagi4]

@AustinMroz if you're making things configurable, is there any chance you could implement #594 while there?

I don't really have the frontend skills to do it myself, but since litegraph already has a property system, it sounds like a possible place to store any user overrides for value widgets.

As for the button placement, I think you'll want to put them somewhere where they don't really move around depending on text lengths for example (so on the right should be fine); that'll make their position easier to predict.

[AustinMroz]

Hmmm. I need to ponder it more, but my initial thoughts is that it would be overly problematic

• Min/Max ARE enforced on the backend now unless a node opts out of it.
  • There isn't a way to determine if a node's VALIDATE_INPUTS is being used to opt out.
  • Inputs aren't validated when they're determined at runtime. Primitive -> converted input will fail validation, but most other int nodes -> converted inputs will skip validation.
    • Given these non-builtin primitive nodes are fairly common, There's already a pathway in place to ignore these numeric restrictions
• If a developer wants to make dynamic changes to their own nodes, they are already writing frontend code which makes it as simple as editing a widget's options.step
• If the support is for non-developers, it's a difficult needle to thread such that it
  • Doesn't produce issues for developers who have had their restrictions ignored
  • Is easier than just editing the actual python code and restarting ComfyUI
  • Has high enough visibility to actually be used without becoming a pitfall for inexperienced users.
• Having converted inputs be aware of deviations between a nodes initial def and current config is hard. I recently had to deal with this in Fix conversion of format widgets to inputs Kosinkadink/ComfyUI-VideoHelperSuite#327
  • Widget types change when created (both FLOAT/INT become Number). This makes it difficult to determine which changes are made by initialization vs dynamically

[JorgeR81]

@asagi4, you could try this extension: https://github.com/chrisgoringe/cg-controller

( It's from the same developer of https://github.com/chrisgoringe/cg-use-everywhere )

It allows you to mirror any node into dockable windows. 

It uses sliders for number widgets.
You can edit each slider. 

And once you edit a slider, the original widget will use the same parameters, in the node's graph.

---

[asagi4]

@asagi4, you could try this extension: https://github.com/chrisgoringe/cg-controller

I actually have that, but I had no idea editing steps was a feature. That solves my problem, though I think it would be a useful feature to have without extensions too.