Right Click Execute Single Node

[00-0o]

Hello everyone, here other partially implemented feature i would like nodezator to have.

To run a single node from right click menu might be handy, instead of affect the global state of the script.
(Like a "soft update" on selected nodes.)

I'm doing it from the terminal with main.APP_REFS.gm.node_map[node_id].main_callable()
It's ok, but a bit tedious to have to go to the console and manually write the command, knowing that is just one click away.

The functionality is already there, the right click context menu already tracks node id or type to display specific info for each node, therefore, the implementation might be fairly trivial.

It would be a minor change in the code side and a huge enhancement in flexibility and user experience.

[00-0o]

ok, little update here.
i managed to modify this file:
.venv/lib/python3.13/site-packages/nodezator/editing/objpopups/callablenode.py
{
"Run Node",
"python_viewing",
self.run_node, # link to run_node func
}
):
user_def_node_menu_list.insert(1, obj_data)

added a "Run node" label and a run_node method.

def run_node(self):
    
    node = self.obj_under_mouse  

    if node is not None:
        node.main_callable()

its a bit hacky, very case specific because you need to handle inputs and outputs (if needed) for each type of node.
Sure it can be done more gracefully but its working!

[KennedyRichard]

Thank you for sharing your idea and feature request.

Your solution is a clever and creative way of using what's already available. It also has the most important things a feature request must have: a good reason for the feature to exist and that the feature must fit the design/purpose of the app.

As the maintainer of the app, I approve the inclusion of the feature. I intend to include it asap, as soon as a new patch/version is uploaded.

However, despite the cleverness and creativity of your solution, in this particular case for the actual implementation I intend to employ a different solution. Here's the reason why:

You see, the feature you are requesting is actually already implemented in full. It just wasn't made available to all nodes. That's cause I only exposed it for viewer nodes, assuming users would only care for this feature in viewer nodes, since they'd use it in order to update the viewer nodes. It is represented by the Reload button on viewer nodes, and its usage is straightforward:

executing_just_part_of_graph.mp4

As seen in the video, only the viewer node whose Reload button was clicked was executed (along with the nodes that feed data to it).

Here's the .ndz file if you want to try it yourself:
executing_just_part_of_graph.ndz.zip

Prior to your request I didn't give much thought to the usefulness of executing a specific node which wasn't a viewer node, but you are completely right. People may indeed want/need to do that, specially since Nodezator executes arbitrary code provided by the user. Visualization isn't the only reason the user may want to execute a node. Maybe the user want a database to be updated elsewhere, or simply see the result of a "print", etc. Regardless of the reason, that feature must indeed be available to other nodes.

As I said, this feature is already implement and handles everything needed, including the collection and feeding of inputs. It is located in nodezator/graphman/execution.py, via the execute_node_after_upstream_ones method. To use it you just feed it an instance of the node you want to execute. Since it is stored in the graph manager instance within the APP_REFS namespace, you can use it like this: APP_REFS.gm.execute_node_after_upstream_ones(node).

If you don't mind, then, for the reasons specified, I'll use my own implementation for your feature request.

In addition to using the solution I just described though, exposing this feature will actually require a few extra non-trivial steps:

First, on top of updating the popup/context menus on user-defined ones like you did, we'd also need to update the popups for the app-defined nodes as well (the ones that are executable, that is, all minus data nodes).

The reason is that many of those nodes either represent useful operations on their own (like nodes that save files, for instance) or they represent operations that call other nodes indirectly, including other user-defined nodes (like the map node for instance, which may execute any arbitrary callable fed to it).

The operator nodes (another kind of app-defined node) also don't seem like they do much beyond performing simple operations, but don't forget that in Python operators can be overloaded, so those nodes may indeed have different behaviours at the user's discretion when an operand is a custom object.

Second, I might also need to create a custom popup menu for nodes that are in callable mode, so they don't contain the option. That's so because in the graph, when in that mode, they represent the callable itself, not a call to it, much like how a data node represents just that data, not a call.

Finally, regardless of all that, I'll also have to update the system test case 0001, because it uses the context menu to delete nodes and the new option to run the node will offset the delete option on the context menu. Here's a demonstration, it happens after I added the "Run node" option to app-defined nodes (didn't even add it to operator nodes yet at this point):

context_menu_deletion_failing.mp4

I still didn't expose all the functionality of automated system testing to users because the service isn't fully finished. So, despite being able to run the tests, adding/editing them is something that can only be easily/effectively done on my end.

And for all those reasons, if you don't mind, I intend to implement/expose this feature myself with my own solution rather than using your original solution. Of course, despite not attributing authorship to you, since I'll implement my own solution, you'll still be mentioned in the commit as the one who gave the idea and requested the feature.

Please, let me know if you agree or need anything else/any further clarification. Despite being the head/maintainer of the project I don't think it is cool to make decisions arbitrarily and without good, sensible reasons behind them. This is why I value and listen to all input and would love your perspective on my proposal/plan.

Have a nice weekend!

Peace

[00-0o]

Hey Kennedy, great!!
And great explanation, thanks for the examples too!!

"If you don't mind, then, for the reasons specified, I'll use my own implementation for your feature request."
SURE!!! MINE WAS REEEAALLY HACKY!!! :)

Yes i remember have seen this: nodezator/graphman/execution.py,
and this: APP_REFS.gm.execute_node_after_upstream_ones(node)
But had no clue on how or where to call it.
Of course one have to pass a node as argument!!.
I remember seeing it along with some kind of BFS or Djakstra like search, and thinking "this is going to be hard to read".
So yeah very good tips, thanks, to call a single node that AUTO handle inputs is a BIG Plus!!

Awesome, i am happy to know that the idea has sparked!!

I fully understand that are many nodes that might need refactoring, and other areas of the code-base need to mirror these changes as well, unfortunately yes, that can only be done effectively by you. I offer you my aid but i doubt to be of any use on revising code.

And for the credit i don't care, even dough it would be cool to be mentioned, i am in no way responsible for the code that was already there written by you. So don't worry about buddy!!

Thanks again for all the insights, if there's anything i can do i am glad to help, just reach out!
Have great week!

[KennedyRichard]

Thank you for the kind words! As I said, I'll include it the next time I upload a new version.

I'll mention you in the commit, no doubt. Even though you are not the author of the implementation you brought the idea to the table. I know the idea is just one small step in comparison to all the hard work that goes into implementing stuff, but sometimes that small step is all that is missing for a solution to take form, which is the case here.

For now, if you need the feature beforehand, you can use your own solution. You'd simply need to replace node.main_callable() by APP_REFS.gm.execute_node_after_upstream_ones(node) in the body of your run_node method.