What would be the best course of action to solve COLOR type collision?

[bmad4ever]

Hi, dear maintainer,

I'm currently also using an input type named COLOR in my extension.
When using your extension the COLOR slots turn to widgets, but can't be converted back to slots since the nodes don't follow the mtb naming convention.
I don't mind the widget and even find it to be a plus, but I need the slots in some workflows.
I initially thought to create a js script to solve this minor inconvenience; however, after giving it some thought, I'm not sure this is the best solution.

Currently, the color widget is applied across extensions, but the toInput/toWidget options are not.
Wouldn't it be preferable to have both following the same logic? that is, either both are applied, or none is.
I am not aware of all the implementation intricacies, but my immediate intuition is that:
If it is preferable to have mtb provide complementary functionalities to other extensions, then would be preferable to include both; otherwise, if it is preferable to keep each extension closed to not break some other extension, then neither should be applied.

I'd like to know what is your opinion on the aforementioned problem.

I can also solve the problem with a script in my extension, but I would like to avoid the creeping in of unwarranted entropy.
Imagine if many extensions were to use the COLOR type and had similar problems, they would have to repeat the fix not only for your extension but potentially also between each other. Such thought compelled me to seek an alternative solution instead of just fixing the problem with a script.

Best Regards

[melMass]

Hi @bmad4ever thanks for reaching out.

The ideal plan to me sounds like bugging Comfy to add it in core, IMO "color" is an important concept enough for an image processing framework. The same happened with BOOL, that I now do not redeclare in mtb since it was added in core.
In the shortcoming I guess the most practical would be that I change my init script just for the color type by checking for input slots rather than names. It should avoid the issue when mixing our extensions.
I will check that now, I'll let you know here in a few, can you link the extension if it's already published?

Thanks again

[bmad4ever]

Thanks for the quick reply.

The extension is the one listed as "Bmad Nodes" in the manager; here is the github link.
The affected nodes are the two ColorClip nodes in simple utilities.

Typically, I connect the FindComplementaryColor node to a ColorClipAdvanced; but in most other use cases, I actually prefer having the color widget instead of using an additional node.

[melMass]

Cool, thanks, I just tested it and my idea would work in theory, let me just check a bit further the implications but I should push it later today

[melMass]

As you can see by default they are all red though. I will check how you handle colors, I use HEX on the frontend and interpret it as an rbg tuple in python in mtb, so to set defaults I use their hex representation.

That said I will change it from red to black and make sure it supports forceInput which I'm not sure it does and you'd probably want to use it in your extension

[bmad4ever]

I just checked the updated mtb extension and the fork.

Now that it is possible to convert between widget and slot, not using forceInput is more convenient (+ flexibility), so I won't change the current inputs.
I also just learned in this interaction that there is a way to force an input into a slot in the python side of things; which will be useful for other nodes in my extension 😃.

Thank you for your diligent work!