Enable the creation of new block functionalities by combining existing basic blocks (typically C++-based) within the same or other top-level (sub)graphs.

Proposed Actions:

1. Dedicated YAML-Based Nested Graph Definitions

   • Implement dedicated YAML files for defining nested graphs.
   • Store these YAML definitions in the block registry for reuse across multiple graphs.
   • Leverage the grc-loader and its YAML-parsing capabilities.

2. Plugin-Like Extensions for User-Defined Nested Graphs

   • Introduce a plugin-style extension allowing users to browse and load nested graph definitions from user-specified directories.
   • This enhances flexibility and modularity in defining and reusing nested graphs.

3. Plugin-Like Extensions for External Graph Sources

   • Extend the plugin architecture to support external sources beyond local files.
   • Include dynamic querying of graph definitions from sources such as databases or community-driven repositories via HTTP(S).
   • Enable nested graph YAML definitions to be fetched and loaded dynamically from external websites or HTTPS-based repositories.

Message-Based API for sub-graph management

Add support a message-based API for creation, duplication and editing sub-graphs.

Key Considerations for Messaging API Design:

• Minimalism: The API should include only the essential methods necessary for sub-graph management. Avoid introducing additional methods or functionalities unless they are absolutely required.
• Consistency: Ensure the API remains consistent and easy to use across different components of the system.
• Avoid UI-Specific API: Features that can be implemented at the UI level should not drive changes to the message API. New APIs should only be added if they are essential for core functionality and not just for UI convenience.
• Maintenance Overhead: Keep in mind that once an API is introduced, it is hard to remove or refactor without breaking backward compatibility. Minimizing the API surface area reduces long-term support and maintenance burdens.

Sub-Graph Modifications: All Instances vs. Single Instance

Sub-graphs are essentially templates that abstract common graph topologies into a reusable form. When a sub-graph is modified, all instances of that sub-graph should automatically reload and reflect the updated version.

Key Behavior:

1. Modifying All Instances:

   • Changes made to the sub-graph template will propagate to all instances of that sub-graph. It is considered acceptable that runtime modifications may cause a loss of state information e.g. buffer contents and/or block settings returning to their defaults if needed.

2. Modifying a Single Instance:

   • To modify only one instance of a sub-graph, the user can ungroup the sub-graph.
   • Once ungrouped, the connection to the original sub-graph template is removed, and the instance becomes independent.

3. Re-grouping Modified Sub-Graphs:

   • If the user groups the modified sub-graph again, a new sub-graph template is created based on the changes.

This approach ensures flexibility by allowing both global modifications (sub-graph template) and instance-specific changes.

This is a follow-up of the following issues/PRs:

• Add subgraphs with exported ports #479
• [8SP;6SP] Improve Nested/Sub-Graph Integration (formerly 'hier-blocks') opendigitizer#184