canopy renders jsonl files as functional and interactive native GUI
Here is a hello world example
```example.jsonl
{"type":"createSurface","surfaceId":"main","title":"Tasks"}
{"type":"updateDataModel","surfaceId":"main","ops":[ {"op":"replace","path":"/tasks","value":[{"title":"Ship demo","done":false}]}]}
{"type":"updateComponents","surfaceId":"main","components":[ {"componentId":"root","type":"Column","children":["title"]}, {"componentId":"title","type":"Text","props":{"content":{"path":"/tasks/0/title"}}} ]}
```
jsonl to gui renderer is one part, canopy can connect with your llm provider directly and let the llm build the app thru these incremental jsonl.
canopy supports --claude or --codex at run in "reverse controlled mode", starts claude/codex with canopy as an MCP server and appropriate prompt.
the mcp also exposes a "screenshot" tool for itself so the LLM can actually "see" whats its build. and it can obviously interact with the app itself to test it.
the images in the readme are real examples.
apart from the basic native components like input field, scroll, layouts etc, canopy can do - ffi function calls - take its own screenshot - audio/video capture - api calls
for "demo" apps it works okay, i notice different kind of "behavioral issues" in the generated apps though, mostly in terms of state management for more complex apps, the issue gets multiplied. i tried a "pixel editor to ico export", the editor part worked fine (0 ergonomics for the user though), the export did not work at all. i coulnt get to a usable "sqlite browser" at this point.
but i am sure these are prompt problems/tooling that can be fixed with better abstractions (packages, reusable components)
https://github.com/artpar/canopy
go build -o canopy
No comments yet.
