Meeting № 18 Summary

[devhelpr]

Meeting 18 transcription

Recording of meeting

Meeting № 18 Summary

Summary

Major Discussion Points

• Transclusion in the Spec
  Transclusion was previously thought to be missing from the spec, but it was discovered that it is already inherently supported through parent-child relations. A new document called the Cookbook was created to explain how to use this feature.

• Defining Visual Node Shapes
  There was debate over whether primitive shapes like ovals should be considered distinct types or treated as resource-based elements like text and images. Some members preferred keeping simple geometric shapes as top-level visual elements rather than treating them as resources.

• SVG vs. Custom Resource Types
  The group discussed whether to use SVG paths for shapes or define custom JSON resource types (e.g., an "oval" resource type with properties like width, height, and stroke). A simpler custom format was seen as beneficial.

• Conceptual vs. Visual Canvases
  The group considered whether certain design choices should prioritize visual canvases (e.g., whiteboarding apps) or conceptual canvases (e.g., auto-layout diagrams). This decision impacts how geometry and spatial positioning are handled.

• Z-Ordering of Visual Elements
  There was discussion about whether shapes should always appear on top of their associated resources (e.g., an oval should overlay an image). The consensus leaned toward defining a recommended Z-order but allowing implementers flexibility.

• Multiple Resources per Node
  Currently, each node can only have one resource. A potential extension was suggested to allow a "background resource" for cases like text overlaid on an image.

• Z-Index Handling
  The visual node Z-index determines layering, but there was discussion on whether nodes themselves should have a Z-index. The current approach is to allow optional Z-coordinates that define stacking order.

• Layering as a Relation Type
  A "layer" relation type was proposed to allow grouping of elements that can be moved together while maintaining individual Z-ordering. This would be distinct from "sets" or "groups."

• Transclusion as a Node or Relation Extension
  The group debated whether transclusion (inheritance from another node) should be a node extension or a relation extension. Keeping it as a relation extension was preferred for flexibility.

• Demo of Codeflow Canvas Integration
  Michael showcased a demo of importing an Open Canvas Exchange Format (OCIF) file into Codeflow Canvas, highlighting challenges and successes with integrating OCIF into real-world applications.

• Exporting OCIF Files to TLDraw
  A method for exporting OCIF files to TLDraw was demonstrated, showing how nodes and their connections were represented.

• Handling Shared Resources in OCIF
  There was discussion on how to manage resources shared by multiple nodes, particularly ensuring that updates propagate correctly.

• Encouraging OCIF Adoption
  The group considered ways to encourage adoption, including targeting simpler tools like Obsidian Canvas and writing converters to popular formats.

---

Action Items

• Review the 0.3 draft of the spec and finalize it within 24-48 hours.
• Add documentation on best practices for handling shared resources in the Cookbook.
• Consider implementing a background resource extension to allow multiple resources per node.
• Investigate ways to encourage adoption of OCIF, possibly by developing conversion tools for Obsidian Canvas and TLDraw.
• Continue refining Codeflow Canvas integration and improving export options.

---

Takeaways

• The Cookbook will help clarify existing features like transclusion.
• Keeping primitive shapes as top-level visual elements may simplify implementation.
• A clear Z-ordering policy will improve consistency across different canvas implementations.
• Using a structured approach to defining resources (instead of relying on SVG) could simplify implementation.
• OCIF’s success depends on providing compelling use cases and easy-to-use conversion tools.

Would you like any additional refinements to this summary?