Custom GraphView hard to implement due to strong dependencies on CanvasView

[leissler]

The whole framework has a weakness in extensibility.
I tried to build upon the Execution Flow Example code to test how it would be possible to build an own visual scripting system on top of BlueGraph. This works ok for custom nodes and even custom node views.
However, when I wanted to extend on the possibilities of the CanvasView, it seems that the whole system relies on only using the CanvasView class and not allowing to, e.g., inherit from CanvasView or creating own GraphView classes.
Internally there are many dependencies on CanvasView.
I'd propose to re-arrange the system to allow for custom GraphView derived classes, probably allowing to extend CanvasView.

[McManning]

Do you have some use cases / examples on what you'd like to accomplish by extending off of CanvasView / GraphView? It'll help me get a better idea of what sort of refactoring might be useful here.

[leissler]

I guess the simplest case would be to style your own canvas with colors, grid, etc. and probably extending it with elements like minimaps, special menus, toolbars, etc.
In my particular case, I'm running experiments for extending Game Creator 2 with a node-based visual scripting extension.
This means that a NodeView draws a single instruction, the Graph must hold several InstructionList objects (in arrays, which are in the runtime SO graph) but the GraphView must also cache and hold some extra SerializedProperties that I need to draw the instructions, which the NodeViews, in turn, can access.
When I tried to derive from CanvasView it quickly became messy and turned out that I needed to customize lots of classes down the line, including EdgeConnectorListener and others.

I'm sure you are aware of the NodeGraphProcessor framework on GitHub, which is more flexible in that respect.