creating nodes form whitin ryven

[BerneS-1849361]

I am working on a project where i need to combine some nodes into 1 bigger node to simplify the flow. But i couldn't realy find a good meghtod of doing so. I tried to dynamicly create new classes but these are not accepted by the export_nodes function (it said something like "source code not found"). Is this even possible or how should i best aproach this?

[isConic]

I completely agree with the need to make nodes groupable.
For a given project. I've run into needing to perform a sequence of compositions in series repeatedly.

And it's been taking up a bit of real estate.
Then I think to myself "surely this would be a simple thing to make a reality, just take all unallocated inputs, and put them on the left side, and the unbound outputs and put them on the right", but then I run into the issue of. "But what if it's a widget? how do those combine? Do I just... make the node very long on the bottom?"

I've found a few threads that might be relevant to this on github:

• project update - ryvencore #50
• Feature request: node groups #35

IDK what the future of this is going to be. How do you imagine overcoming the "how do nodes collapse exactly from a user's perspective?" problem?

What do you think?

[isConic]

Like... I would guess that it would look something like this:

Everything claimed/closed within the selection area would not be an accessible input OR output. You can also create the equivalent of named checkpoints or something to make a claimed output unclaimed.

All widgets would pool up at the bottom of the node.

Just a random shot in the dark at what this would look like. I'm not personally working on ryven. Just an enthusiast developing my own tools/widgets.

[leon-thomm]

Very nice, thank you for the input! This grouping of multiple nodes into one thing sounds like abstraction, which has a bit of a history here. In #84 I explained the reasoning behind removing those macros that Ryven once had. However, the issues addressed there mainly originate from reusage (i.e. grouping nodes together in a subgraph and then using this subgraph like a function in multiple places). However, if we don't need that kind of reusability, if it's only about the grouping, I don't see any conceptual issues right now. (of course, implementing this might not be trivial, but should be doable)

[BerneS-1849361]

Thanks for the replies but i still dont realy know how to solve my problem. I would like to create a class deriving from node dynamiclly and then add it to the available nodes.

an example code for such a class:

def constructor(self, arg):
    self.arg = arg


def update_event(self, inp=-1):
    self.set_output_val(0, "Test Node")


cls = type("Test", (Node,), {
    # constructor
    "__init__": constructor,

    # data members
    "init_inputs": [
        NodeInputBP(dtype=dtypes.Data(default=1), label='  '),
        NodeInputBP(dtype=dtypes.Data(default=1), label='  '),
    ],
    
    "init_outputs": [
        NodeOutputBP()
    ],

    # member functions
    "update_event": update_event,
})

how could i now add cls to the existing nodes?
Because if i just add it to export it says it cant find the source code

export_nodes(
    cls
)

OSError
:
could not find class definition

do you know how i can solve this issue or is there a complety different way i should approach this?

[sphh]

Looking at ryven/NENV.py:

def export_nodes(*args):
    """
    Exports/exposes the specified nodes to Ryven for use in flows.
    """

    if not isinstance(args, tuple):
        if issubclass(args, Node):
            nodes = tuple(args)
        else:
            return
    else:
        nodes = list(args)

    NodesRegistry.exported_nodes.append(nodes)

    # get sources
    node_sources = [inspect.getsource(n) for n in nodes]
    NodesRegistry.exported_node_sources.append(node_sources)

you might want to write you your own export_nodes_without_source() method:

def export_nodes_without_source(*args):
    """
    Exports/exposes the specified nodes to Ryven for use in flows.
    """

    if not isinstance(args, tuple):
        if issubclass(args, Node):
            nodes = tuple(args)
        else:
            return
    else:
        nodes = list(args)

    NodesRegistry.exported_nodes.append(nodes)

    # DO NOT get sources
    # node_sources = [inspect.getsource(n) for n in nodes]
    # NodesRegistry.exported_node_sources.append(node_sources)

Most likely it is just a stupid idea and I have absolutely no idea, what side-effects this has. Maybe build on it and supply some dummy code?

[leon-thomm]

Theoretically, you can dynamically build custom nodes, store them in the NodesRegistry, store their sources, and register in the ryvencore-qt session. However, I'd advise against it as it depends on non-API implementations, aka. it will break in future versions.

However, I'm pretty sure you can completely build your use case without dynamically building the classes. If you have dependencies between your nodes, e.g. you can store instances statically in your nodes module and the nodes can know each other, and share or exchange data when necessary. This statically-storing-nodes-approach is quite powerful, I suggest thinking in that direction.

[BerneS-1849361]

For my project i was thinking to combine all val nodes of a script to the inputs of the node and all the results as outputs. but i didn't need any widgets so i didn't think of how to handle these. But indeed these schetches would be exaclty what i need atm (nice names btw)

[isConic]

Lol. Thank you. I never knew I'd need more than Foo Bar and Baz at a time, so I had to improvise.

[isConic]

The alternative view... would be thinking of collapsed nodes as the engine in a car. It's a black box. The engine and all the dials,knobs and views of it are concealed. A user would only see the widgets, or settings, or everything if they chose to open up the hood.

This is probably easier to implement 🤔