Runtime-defined node types

[russelltg]

A useful feature (at least for me) would be runtime-defined types. As of right now, only subclasses of NodeDataModel (that must be defined at compile time) can be used as node types.

I am willing to form a PR for this with a little guidance on how this should be implemented.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[russelltg]

Acutally there is a hack around this.

static const char* typetocreate = "";

class RuntimeNodeType : public NodeDataModel {

QString type;

...

// this works because the map is based on the name
static QString name()
     if(strcmp(typetocreate, "hello") == 0) {
        type = typetocreate;

     }
};

// now in virtual functions just have conditional functionality based on name

Definitely a hack, it would be better to have real support for this.

[russelltg]

Actually, it won't work due to the name call in RegisteryItemImpl

[russelltg]

I think the best way to do this is instead of RegistryItems being stored in DataModelRegistry's _registeredModels, store a unique_ptr<NodeDataModel> which would allow for custom storage in node types. I'm writing it right now to see if it works.

[paceholder]

An instance of NodeDataModel represents a specific node, model with given state located in the memory. RegistryItem is a way of storing the class information without creating the class. We use factory method to create as many instances as required. I do not see any point in throwing away the RegistryItem

[russelltg]

Well my idea was to create the class so it can hold runtime metadata. I also had to add a clone virtual function to NodeDataModel so it can still represent one node.

I'm almost done implementing it, I'll show you

[russelltg]

This is what I mean (Here is the relevant commit)

[paceholder]

I see, but what is the benefit of this change? Shorter code? Maybe I did not get your idea with runtime metadata. Can I ask what kind of project you are working on?

[russelltg]

Okay let me see if I can explain my issue to you.

Instead of a specialized application just for manipulting a specific kind of graph (ie calculator), I'm making a general application for manipulating graphs that have node types that are defined in files.

With your current system, I have to know all possible node types at compile time, which is not ideal.

Let me explain the exact project I'm working on. It could be that I missed something here and what I'm trying to do is already possible. I'm working on a programming language (the repo is here) which is like UE4 blueprints in that instead of being text based, it's a flowgraph. that has what are called "modules". These modules define functions that cen be used from other modules that depend on them (if you've used golang, it's modeled after that). I'm using your library to create a module editor, where you can open up functions into the graph.

You see, at runtime I need to be able to create node types. This system allows metadata to be stored in the instance of the class instead of just in the type data, meaning that I can have hundreds of instances of the same class in a registry, and they can all be different types.

I have already implemented that in chigraph, here

I hope that helps clear it up...

[paceholder]

That's very interesting, thanks for explaining. I need to look at your code as it might be useful for my project as well. I planned to process lots of scientific data (1d, 2d, 3d arrays and scalars) by the graph of algorithms. Then I decided to write Node Editor first.

Now I see, you are doing tricks by returning different names for the same Type class depending on the context (metadata).

Besides, I like that we eliminate these ugly static functions:

String const name = ModelType::name();

Please, patch the pull request, squash everything in one commit and I will merge it

[russelltg]

Alright! I think it depends on my other PR right now, but I can fix that.