-
Notifications
You must be signed in to change notification settings - Fork 137
Port Snapping doesn't take InputParamKind::ConstantOnly into account #54
Comments
Addendum: This affects any output port, no matter the type as long as at least one input in the graph has the InputParamKind::ConstantOnly. Changing the InputParamKind to allow connections makes the crash disappear. As an aside, I have noticed that without the crash the UI will snap to ports that are not the same color even though it won't actually make a connection. I don't know if this behavior should be standard or if it might confuse users who may think the snap indicates the port is valid. |
The crashing issue has been corrected. I will PR it later.
Indeed, I had not thought of this. |
This was wrongly closed by GitHub when I merged #59, there is still the pending issue of only snapping to compatible ports with the same color. |
This takes care of the second half of #54, where ports snapped to incompatible colors even when the connection was not possible.
@kkngsm The current system will get reworked once #30 is merged (might take a while) to allow specifying compatibility between different kinds of ports using a custom function. Once we have that function, we'll be able to use it to indicate more complex logic for when two ports are compatible. For the time being, the semantics for this library is that a connection cannot be made between ports of different type. |
I made a node that has one input that is InputParamKind::ConstantOnly. If I try to click near an output port of the same type as the input port I crash with the following:
I can connect from an input back to the output without issues.So it appears that .find_map from line 188 does not exclude port_ids that do not have port_locations associated with them such as the InputParamKind::ConstantOnly, which should be filtered out prior to the mapping of existing locations.
The text was updated successfully, but these errors were encountered: