Editor: In-Node Editor

[eri24816]

Enable a node to own an in-node editor, for defining composite functions or other purposes.

Expected behavior

When the (outer) node is double clicked, an inner editor opens and shows the containing graph. That can be nested. (不禁止套娃)

Notes

Grapycal should provide an interface to node developers to take use of this feature i.e. make a node to contain a graph.

[eri24816]

My opinion:

While it's natural to think that the in-node editor represents the definition of the outer node in the form of a composite function, the purpose of in-node editors should not be restricted to that. Instead, it can be one of:

• definition of a composite function: Just like the current function definition scheme, but the function is defined in an in-node Editor in a FuncDefNode.

• definition of a graph template: A graph template is defined inside a GraphTemplateNode, which has a name field and an in-node editor where the graph is defined. The user can type the template's name to create a copy of it on the current editor.

• anything that the node creator wants. (We'll find more use case in the future, I believe)

So the API should be general enough to enable all above. My proposal is to make the in-node Editor a control. That way, a node can own multiple in-node editors.

The SObject structure would be: Node - InNodeEditorControl - Editor - (Content of the in-node editor)

[secminhr]

About in-node edtitor

I think it would be more general if we see it as a sub-workspace. That way the full power of workspace can be leveraged and new features, including fixes, will be available automatically.

Providing this feature to node developers as a new component seems reasonable, as it follows our old practice to provide additional functionalities to node, but I suspect that it cannot be implemented as an ordinary component.

About multiple editors on a single node

Though we decided to provide it as a component, I think we should restrict the use of it to 1 editor a node for the following reasons:

1. Though it is achievable, since we provide it as a component, it complicates the user interaction. If there's at most 1 editor per node, opening the editor can be a single action. If there're many, however, users must identity which to open, which further indicates that user may need to give each editor (in a node) a unique name.
2. Multiple editors will be useful only when a node wants to have multiple workspaces for different tasks. However, such behaviour can be implemented with nesting, which sub-workspace already provides.

Desired functionalities

• Node developers can decide if they want to have in-node editor on certain node. (It becomes natural if we provide it as a component)
• Nesting. A node in an in-node editor can alao have its own editor.
• Subworkspace-specific nodes. Node developers can provide additional nodes that's only available inside the sub-workspace.
• Local namespace. A sub-workspace should have a local namespace from users' (not node developers!) perspective. Therefore local variables, local functions are available.
• In/out mapping. Node developers can somehow connect In/Out port into its sub-workspace, so the nodes inside sub-workspace can drive/be driven by ports on outer node. (This can be provided as subworkspace-specific nodes)
• No presumed semantics. Instead of restricting the usage to certain situation, we only provide the functionality to node developers. Developers should decide what it is used for and what the sub-workspace represents.

About implementation

I believe that figuring out the things that forms a workspace is important. So we should first ask: what are the essential components of a workspace? And how do they interact to provide what we have in a workspace?

[eri24816]

Agree about the idea.

Let's clarify the terminology of Workspace and Editor first. In the current implementation's logic,

• Workspace process (workspace.py) is the unit of Grapycal runtime, analog to a Python interpreter process. Its state can be saved to and loaded from a .grapycal file.

• Workspace SObject (workspaceObject.py/workspace.ts) is an SObject exists per workspace process, managing the states and communication that is global for the whole workspace process. In terms of the SObject tree, it is the only child of the "root", and is parent of a Settings, a WebcamStream, a Sidebar, an Editor (the main editor), a LocalFileView and a RemoteFileView. The Sidebar is where preview nodes locates. (The node list at the left of the UI)

  The WorkspaceObject.build() looks like:

  class WorkspaceObject(SObject):
    frontend_type = 'Workspace'
  
    def build(self):
      self.settings = self.add_child(Settings)
      self.webcam = self.add_child(WebcamStream)
      self.sidebar = self.add_child(Sidebar)
      self.main_editor = self.add_child(Editor)
      self.file_view = self.add_child(LocalFileView,name='Local Files 💻')
      self.add_child(RemoteFileView,url = data_yaml['examples_url'],name = 'Examples💡')
  

• Editor Sobject (editor.py/editor.ts) represents a plane for Nodes and Edges to be placed on. Adding, removing, copying, and pasting nodes and edges are done on the level of Editor.[*1] Currently, the Workspace SObject have only one Editor (main editor), and all the nodes (except preview nodes) and edges are direct children of the main editor.

Back to the question: What level of functionality do we want an "in-node editor" have? Should it be an Editor, a WorkspaceObject, or something between?

[*1]: The code for delete is incorrectly placed at Workspace instead of Editor currently. This is to be fixed.

[eri24816]

My first thought was it should be just an Editor (that's why I named the issue so). But maybe its nicer and more general to treat in-node editors as subgraphs and associate each of them to a .grapycal file, just like Workspace. We have to think up some use cases to decide the answer.

[secminhr]

What about the inspector at right? Is it a part of the main editor?

[eri24816]

No. It is pure frontend thing

[eri24816]

It's outside of the editor in the frontend. The editor is the central draggable area. I think the inspector should be global, one per webpage.