setzer22
commented
2 years ago The NodeTemplate in the example is a simple compile-time enum, but I was careful to never assume this when defining the traits. If there is something in the trait definitions that is forcing the templates to be compile-time only, this should be considered a bug.
The templates as they are right now can be completely dynamic. Maybe I should add a few notes about this in the example. Essentially, the contract is:
- You provide a list of templates to the library. Being immediate-mode, you can easily change this list of templates each frame as you see fit (this takes care of the use case of registering new node types).
- The template itself is just a data container with the necessary information required to create a node (that is, the parameters plus any user data you want to store).
1- I might want to implement the possibility for my user to select a bunch of nodes, group them, and create a "new template" that, to my application logic, is equivalent of all the grouped nodes.
This should be possible with the current template approach right now, as long as you have a way of representing the grouped objects as some sort of "compiled" thing (i.e. not a subgraph).
But perhaps more interestingly, I'm planning to add sub-graphs as a future feature to this library. With that, you'd be able to create a node containing a full node graph inside, and the UI would allow you to navigate inside the child graph. This is not possible right now, but I'm just mentioning it in case you'd also find this useful :+1:
2- I might want to have plugins for my application, and the plugin would register new node types.
As I mentined above, this is entirely possible with the current version of the code. You just need to pass in a different list of templates each frame, as new node templates are registered.
When combined with our discussion in #6, I would say the best approach here is to tie the template mechanism to the optional "add node" menu. We should provide a way for users to sidestep this altogether if the mechanism is not useful to them, but not remove it entirely.
walksanatora
Having a compile-time list of possible node types can be limiting for some use cases, because one might need "dynamic types" of nodes. A few use cases that come to my mind: 1- I might want to implement the possibility for my user to select a bunch of nodes, group them, and create a "new template" that, to my application logic, is equivalent of all the grouped nodes. 2- I might want to have plugins for my application, and the plugin would register new node types.
Since any node always contains the user-provided NodeData generic, the application can use that struct/enum to differentiate between all the possible operations that a node represents.