crolando / plano Goto Github PK

The header text is forced to be the member:
plano::api::NodeDescription->Type
which is coupled with the prototype of the node.

This means every instance of a node type would display the same name.

In @adamsepp use case, the API was edited to provide nodes with a setNodeName() and getNodeName() callback.
This made other parts of the program be able to set the node name via the user, ultimately.

@adamsepp is designing a way to execute a program that is defined by the nodes. This user has created these forks to implement a scheme for program execution:
https://github.com/adamsepp/nodos_experimental
https://github.com/adamsepp/plano_experimental

@adamsepp I am not able to run your examples. The program dies in the way described here: thedmd/imgui-node-editor#191

I found that I could get it running by disabling the sidepanel. That is, in your plano_experimental frame.cpp file, I got it working by commenting out these lines:

    //Splitter(true, 4.0f, &leftPaneWidth, &rightPaneWidth, 50.0f, 50.0f);

    //ShowLeftPane(leftPaneWidth - 4.0f);

    //ImGui::SameLine(0.0f, 12.0f);

I must apologize, this is not something I understand. I hope in the bug above, we can get to the bottom of it. I can port whatever changes are made there into Plano.

Pulling in the discussion from Issue #1

@adamsepp is designing a way to execute a program that is defined by the nodes. This user has created these forks to implement a scheme for program execution:
https://github.com/adamsepp/nodos_experimental
https://github.com/adamsepp/plano_experimental

In this issue, we will talk about how the Plano API can be changed to support the host program in executing a program based on the flow graph.

At the moment, Nodes have a Properties object, which is typedef to attr_table. This in spirit is a userdata class, albeit inflexible and specialized.

In this task, we will formally add userdata fields to all the elemental graph objects: Nodes, Links and Pins.

While not wholly useful by themselves, they can be passed during event callbacks to the user, where they are very useful.

In the blueprint demo from @thedmd, you can drag out a link from a pin, and drop it onto the background. This lets the user spawn a node node, and hooks-up the link to an appropriate input. I broke it, and adamsepp fixed it here:
f9d7728#diff-a3f423ffb4be3d312343fd76e7263eb4d86dc70284ec2b9d2a63c9334c5e2ac0

In this task, I will port his fixes over

Hi, since I'm using the standard blueprint example up to now, I wanted to have a look at your implementation too.
But I'm not sure what else I need.
Seems like some file are missing? For example the "plano_properties.h" ?

Pin type customization should at least:

1. allow the user to specify what icon to use.
2. be seralized / deserialized automatically
3. interact with typesafe pin connection enforcement

From @adamsepp 's usecase, they needed to modify plano to learn when links were created. In this task, we will provide a callback that is fired when a new link is created. The callback should be passed enough information to know these facts:

• the donor node
• the recipient node
• Donor node's pin object
• recipient node's pin object
• the link object

See @adamsepp 's commit here:

include/internal/internal.h

The Plano API needs to expose node stylization rules, so style changes can be done without having to fork plano.

In this issue, we will

1. expose the existing imgui-node-editor style fields.
2. expose control over the fonts used for pins and node headers

Design concepts:
Host program should be able to
Nodes should be able to control their own stylization at construction and runtime. Implication: style information is accessible in node callbacks.

Plano currently forces acyclic graphs. In @adamsepp's usecase here, they had to go into the plano code and comment out the acyclic detection:
f9d7728#diff-a3f423ffb4be3d312343fd76e7263eb4d86dc70284ec2b9d2a63c9334c5e2ac0

In this issue, we'll allow the user the choice.