-
-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add list of acceptable types when hovering over node input #2069
Comments
Hey @adamgerhant Could I take this issue? |
Sure! Dont worry about the automatic type casting yet. I would focus on just getting the proto node hovering tooltips to work, then work on the network nodes. |
Hey @adamgerhant should it look something like this: |
Yes |
No, that is currently the correct display. This node would give a type error when being executed since an input of TaggedValue::None is being supplied to the encapsulating network, which gets fed into the Divide node, which expects a number. |
Ok so how should I approach to display the type accepted by the network node in this case |
When hovering over the input for the encapsulating network node (which is not currently visible since its in the document network), it should use the outward connections from the import (currently visible) and return the supported type of that Divide node input. |
As noted by Lerc, it would be helpful for the NodeInput tooltip to display all acceptable types that will not cause a node error. For protonodes, this would require accessing the list of implementations, which are defined in the node macro. The implementations would then be filtered based on the current type of all other inputs to return a list of all currently valid types for that input. Network nodes are a bit more complex, since the inputs will undergo automatic type casting (2042), and all usages need to be valid. This means the acceptable types will be the intersection of all types that implement From for the network input type, and all types that the import is connected to.
The text was updated successfully, but these errors were encountered: