How to retrieve the nodes in sub-graph if the sub-graph(group node) is collapsed ?

[EssenOH]

Hi;

I am trying to retrieve all the nodes in graph including sub-graphs and current system can do only following cases :

[ Working Cases ]

1. basically, retrieving nodes within root-graph with calling self.all_nodes() API.

    for node in self.all_nodes():
        print(node)
   

2. Retrieving nodes within sub-graph with calling self.all_nodes() API or node.get_sub_graph().all_nodes() if the node is group node in case the sub-graph is expanded.

    # retrieving nodes in sub-graph via the group node
    for node in self.all_nodes():
        print(node)
        if node.type_ == 'nodes.group.MyGroupNode' :
            print('detected group node')
            print(node.get_sub_graph().all_nodes())
   
    # retrieving nodes in sub-graph via self.all_nodes() from root graph
    for node_id in self.sub_graphs: # returns dict: {<node_id>: <sub_graph>}
        for node in self.sub_graphs[node_id].all_nodes():
            print("\t", node)
   

[ No Working Case ]
What I want to implement is retrieving all the nodes at once even though the group nodes are not expanded.

3. currently, if the group node is not expanded, the self.all_nodes() API call doesn't return anything or even calling the group node API goes to crash.

Additionally, the group node sub-graph, is there any recommended way to register on_graph_node_created callback ?
If I can retrieve the sub-graph even though the group node is collapsed, I can always check the sub_graph and I can register the callback for each sub-graph and I can detect the node creation & delete inside the sub_graph, but currently it is hard to implement the functionality.

What I want to implement is to refresh system with detecting the node creation / delete event for any place regardless the nodes are in root graph or sub-graphs.

[EssenOH]

I could figure out it with expanding the group node.
current architecture can support only retrieving the nodes in case only the group node is expanded.

[jchanvfx]

Hi @EssenOH,

The group node is currently not fully developed. here's the related issue: #376

Cheers,
J

[EssenOH]

Thanks for the comment and I am eager to get it soon.

Actually, after analyzing the architecture, I realized that the group node supporting is too complicate because the nesting is unlimited.

For my project, I don't need the unlimited nesting architecture and then modified the source codes and allowed only one nesting, and then have modified a lot of places of sources because I have to prevent any group node creation within sub-groups, and doesn't allow cut/past, de-serialization and so on...including undo/redo operations as well.. with always on the sub-group tabs.

Then, if you can consider about architecture change about the nested depth control by system designer, it could be a very useful feature in order to traverse the objects in nested structure.

Additionally, I decided the sub-group tab is always-on to retrieve the objects within the sub-group and it could be more intuitive interface from UX perspective, then I eliminated the navigation class & the automatic hiding controls, then if you can consider about a new design for the controllability of group node creation decision in the nested sub-groups, I think the deepest( the last) level of sub-group doesn't need the navigator.

Hopefully, you can consider about the requirements for your new architecture design for next generation.