You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NodeEditor is one of the few open source flow graph QT libraries. I can understand the intent of QT's MVD pattern from simplegraph example.But the NodeDelegateModel concept confused me. I think it is not a "Delegate" or "Model" in "MVD". It is more like Data containing In/Out member and a compute function because nodedelegatemodel is stored directly in DataflowGraphModel. Maybe existing pattern and "NodeDelegateModel" obj can be given other names.
I've been thinking about it lately. If the nodeeditor is strictly designed as MVD in the future, how should it be desigened? A generic flow graph pattern is more valuable than more and more functional details.
The text was updated successfully, but these errors were encountered:
Thanks to nodeeditor for the inspiration.In my subsequent practice, I think this approach will be more versatile and reduce the amount of development: the data flow display framework does not bear the responsibility of propagating node data, but only provides logical APIs such as node connection. As for data flow propagation and dependency resolution, users need to implement feature-rich graph structures and related algorithms based on the basic model. It may be healthier to strengthen the functions at the view level while avoiding complex business requirements of the model.
NodeEditor is one of the few open source flow graph QT libraries. I can understand the intent of QT's MVD pattern from simplegraph example.But the NodeDelegateModel concept confused me. I think it is not a "Delegate" or "Model" in "MVD". It is more like Data containing In/Out member and a compute function because nodedelegatemodel is stored directly in DataflowGraphModel. Maybe existing pattern and "NodeDelegateModel" obj can be given other names.
I've been thinking about it lately. If the nodeeditor is strictly designed as MVD in the future, how should it be desigened? A generic flow graph pattern is more valuable than more and more functional details.
The text was updated successfully, but these errors were encountered: