A common pattern for graph based UIs it to constrain connections between different socket / node types. As a user, I really like that this library is focused just on UI logic, compared to something like https://github.com/setzer22/egui_node_graph which requires the user to structure their application in a particular way, namely as a series of enums which can be problematic for applications which might want to be open to allow users to define their own types.
The easier version of this is just node types where connections can only be made between nodes of the same type. But I'm wondering if this couldn't be decomposed into something that pushes the logic mostly to the user, i.e. some kind of callback on the snap-to and connection events that allow the user to determine entirely in their code whether sockets should be allowed to connect, rather than backing the concept of "types" into the graph ui itself. Just a thought!
A common pattern for graph based UIs it to constrain connections between different socket / node types. As a user, I really like that this library is focused just on UI logic, compared to something like https://github.com/setzer22/egui_node_graph which requires the user to structure their application in a particular way, namely as a series of enums which can be problematic for applications which might want to be open to allow users to define their own types.
The easier version of this is just node types where connections can only be made between nodes of the same type. But I'm wondering if this couldn't be decomposed into something that pushes the logic mostly to the user, i.e. some kind of callback on the snap-to and connection events that allow the user to determine entirely in their code whether sockets should be allowed to connect, rather than backing the concept of "types" into the graph ui itself. Just a thought!