Runtime-defined node types about nodeeditor HOT 10 CLOSED

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.

from nodeeditor.

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

from nodeeditor.

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.

from nodeeditor.

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

from nodeeditor.

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

from nodeeditor.

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

from nodeeditor.

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?

from nodeeditor.

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...

from nodeeditor.

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

from nodeeditor.

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

from nodeeditor.