Exolivelits x Patchwork Meta

[disconcision]

Related Branches:

• Hazel in Patchwork #1959: Adds Hazel as a patchwork tool. Currently sends the entire editor segment every update, and does not support projectors or refractors
• Exolivelits #1911: Embed external apps in Hazel via iframes and postmessage
• Patchworks tools as Hazel Exolivelit #2065: Load patchwork tools as exolivelit

Stuff to do:

• Hazel JSON support (to be used as a default model type for exolivelits)

  • Add JSON ADT to hazel stdlib (see fig. 1)
  • Write HazelJSON / YoJSON de/serializers
  • Maybe add nice Hazel helper fns to construct/process JSON

• Automerge projector (MVP for automerge integration)

  • MVP: A simple projector for data ingestion, similar to @7h3kk1d's CSV file loading projector. This should expose a text field taking an automerge URL, and it listens for incoming automerge data events, issuing SetSyntax after conveying to HazelJSON. Has no UI beyond the text field.
  • Add a toggle which determines if it is hot reloading or has a manual reload button
  • Add an optional type signature field pending below types work

• Patchwork Livelit (MVP for patchwork tool integration)

  • MVP: Assumes a fixed form when initially inserted. Has a dropdown which picks from a fixed set of Patchwork tools, and a text field for entering automerge doc URLs. Selecting a tool sets a fixed size for the livelit; it loads the tool in an iframe. Same as above, listens for incoming automerge data events, issuing SetSyntax after conveying to HazelJSON.
  • Add user resizability (exoprojectors already support this via dragging)
  • Replace existing Petrinaut integration with Petrinaut tool; try to regain the same functionality as the Edinburgh demo via processing its raw JSON into a similar format as the ad hoc one HASH whipped up.
  • Catcolab tool integration (not sure if currently live on patchwork)
  • Add the ability to specify more patchwork tools. This could itself be done via a tool provider tool which loads tools (from a registry) ands maybe emits a list of tools, which could be used in conjunction with next task. (This concept is half-baked)
  • Decide if we want have tool and/or data source specified via livelit parameters instead of by GUI.

• User-define exolivelits

  • Decide if we want to retain non-patchwork exolivelits, and decide what if any is the relationship is between the two mechanisms
  • Redo the existing exolivelits as either user-defined exolivelits or patchwork tools, or just delete them (slider, exobuilder, nool)

• Types for Tools / ExoLivelits

  • Agree with Ink & Switch on a JSON meta-schema for tools
  • Develop a mapping from this meta-schema to hazel types (see my existing stab at this in the implementation)
  • Implement said mapping
  • Allow ExoLivelit definitions to specify a type; edit-time enforced

• Clarify patchwork/hazel implementation boundary

  • Figure out with Chee if we can split the integration js into a seperate I&S hosted lib

fig. 1

type JSON =
  + Assoc(String, JSON)
  + Bool(Bool)
  + Float(Float)
  + Int(Int)
  + List([JSON])
  + String(string)
  + Null

[disconcision]

@cyrus- @dm0n3y started at list of things to do re: ARIA exolivelits/patchwork implementation-wise. This is mostly stuff we've talked about before, but I also realized we can/should do a kind of lightweight universal data loader; see section 2