Suggestion: right-click popup should not be this library's concern

[francesco-cattoglio]

Right now when the user right-clicks on the graph editor, the "add new node" popup appears. I think this is something that should be done in application code, instead of library code. I can see a few situations in which a programmer would want to have a specific context menu:
1- When clicking on a node, I might want a menu that allows me to delete, rename, or clone it, or do other fancy stuff.
2- When clicking on the background, I might want a menu that changes depending on the application state. i.e: I can start or stop an animation by having the animation controls in the popup menu, and what the controls show would change every frame.

To achieve this, the library should simply return a "right click event" and let the programmer decide what to do with it. Ofc we should add an example on how to use that event.

I will toy with the code today and see if I can achieve something.

[setzer22]

I think separating the right click menu from the core is reasonable 👍

But I'm also thinking we still want to be "batteries included" to some extent. I think a good compromise here would be to provide things like this as opt-in. The menu right now is a bit bare-bones, but I'm planning to keep improving it with a smarter search, categories and other features that may be appealing to other users, and are not so trivial to reimplement on each user's code.

[francesco-cattoglio]

Maybe we can provide a "util" or "extras" namespace for all the batteries that we might want to include. I will keep this in mind when tinkering around.

[philpax]

Hey there! Not sure if I should open a new issue for this or not, but I figured this would be a good place to mention it: I'm using egui_node_graph on the web, and while disabling right-clicking on the rendering element is fine, it'd still be nice to be able to customise the behaviour.

My immediate suggestion is to allow for changing/turning off the trigger condition for the NodeFinder. I believe it should be possible to design things such that NodeFinder opens up on right-click by default, but you should be able to change that entirely, including using your own finder menu.

I've not looked at the current implementation in any great detail, but my feeling is that it should be possible to offer the current experience as a default set of "application systems" atop the node-graph core, and let users build their own systems if necessary. I'm thinking about how, for example, you can compose behaviours using the same components and different systems in Bevy.

Anyway, not particularly pressing - disabling web right click works - but this library's already fantastic, it'd be great to make it even more versatile 😄

[setzer22]

Hi @philpax! Thanks for the kind words 😄

Indeed, I feel the right-click behavior should be customizable, and allowing customization for the NodeFinder menu also sounds like a good idea.

I think a good solution for this is to separate the two use cases. For node finder customization we can use the same event mechanism that is used in other parts of the code: Drawing the graph already returns a list of responses that are inspectable by the user. This could include a couple of NodeFinderShow and NodeFinderHide events which then the user can handle as they see fit (even ignore). The library will also provide a default handler that looks at these events and spawns the default node finder. The challenge here is that, unlike other event handlers, this requires drawing additional UI inside the graph. I need to think about the best mechanism for doing this.

As for the right click itself, this library needs a way to customize all input. Middle mouse click to pan is also another hard-coded choice that not all users may agree with. I think I have a good idea for creating a completely configurable input system with sane defaults.

I don't have a lot of time for open source stuff lately (hopefully this is going to improve soon 👍), but I'll keep this in mind, I've been meaning to take care of this for a while. In the meantime, anyone interested feel free to work on this! I'd be happy to elaborate more about the solutions I outlined above.