Add ConnectionPolicy to NodeDataModel #44
Conversation
It was allowed before, but canConnect disallowed it. Maybe there should be a setting in the graph for connection policy because I know you don't want multiple input connections (doesn't really make sense for what you're trying to do...)
This reverts commit 459e053.
|
What is the purpose of merging two inputs? |
|
In chigraph, there are two types of connections: "exec" connections, that denote flow control and data connections, which are like your connections. Exec connections have to be able to have multiple inputs to allow for looping etc. |
|
I'll look through the code and merge this weekend |
|
The commit solves a particular problem but breaks the current concept of a "computational graph", which does not consider loops and "two-to-one" connections. I think I need to elaborate the structure of the framework and construct several layers:
|
|
Mmm that is true. Maybe the computational graph should be implemented by the client via signals etc. That would definitely be the most flexible approach, and would make the "headless mode" more feasable. |
|
The layer idea is quite good as well, maybe like a model-view like thing with the ability to define custom models, with the default being a computational graph. |
|
All the hardcoded biases towards one input have been removed, but we sill have to think about the architecture |
|
I am very interested to get this PR merged... any progress? |
|
If you have an idea on how to implement this in a clean way, absolutely. What do you think? |
|
My two cents... In terms of dataflow, it make no sense to allow a PortType::In to have multiple connections. This is exactly the use case I need, that is not currently covered by the main branch; I can prepare a PR with that. On the other hand... I would love NodeEditor to be usefull also for other applications like state machines, but actually the source code is heavily focused on dtaflow and would require a major change that probably we don't want to do right now. My pragmatic suggestion is to focus only on the NodeConnectionPolicy for PortType::Out. What do you think? |
|
I'm willing to write that (should only take a few minutes), @paceholder what do you think? Is this something you're interested in? |
|
Do I understand it right, you propose to have two policies -- one for just single connection for the "OUT" ports and another one for multiple possible connections? |
|
Correct. OUT can be either single or multi connection, while IN can only be single connection |
|
Yes, than it makes sense and still preserves the current strategy of having "computational graph". |
|
Alright I'll file a new PR for this (I'll keep this branch because im using it on my project) |
Currently, it's hardcoded that input connections can have 1 connection and input can have as many as they want.
This changes this, (keeping that as the default) but adds a
nodeConnectionPolicyvirtual function toNodeDataModelso
NodeDataModelinstances can choose that on a per-dock basis.I might have missed a few places that need to use this refactor.