11–20 of 168 posts
It would be nice to see actual examples. We use an infinite canvas ( https://switchboard.app ), but it's hard for me to map the objects we have on our virtual-desktop-like-canvas with the file format described here. The items on our infinite canvas are more akin to a desktop app, where most objects are application windows.
If you click "Toggle output" on the linked page, you can see the code for the page itself
file (required, string) is the path to the file within the system.
What kind of path, within what system? It's not clear that the 'file' type couldn't just be another kind of 'link'. If various fields like 'background' were defined to be URLs, that would offload a lot of complexity onto existing web specs.
It would be nice to see actual examples. We use an infinite canvas ( https://switchboard.app ), but it's hard for me to map the objects we have on our virtual-desktop-like-canvas with the file format described here. The items on our infinite canvas are more akin to a desktop app, where most objects are application windows.
> It would be nice to see actual examples If you click "Toggle output" on the linked page, you can see the code for the page itself
https://obsidian.md/blog/json-canvas/
We just released it today, so this is still a very nascent project. A little over a year ago we released Obsidian Canvas. The .canvas file format has felt stable enough to give it a name and resources that other apps can freely use. See the original Show HN:
https://news.ycombinator.com/item?id=34066824
The spec is conservative, and definitely does not support many features canvas apps will want to implement (yet).
The purpose of giving JSON Canvas a name and site is to encourage an interoperable ecosystem to grow around this format. We're definitely looking for feedback of all kinds!
It's great to see all the suggestions already shared in this thread because it starts to provide a roadmap for how this could become a more useful format for other apps.
I really like the idea of a format for interchange between infinite canvas apps, but the preset colors and list of node types makes this spec feel strangely opinionated. You could build something like Kinopio [1] but not much beyond that. It looks really promising though! I'm definitely interested in seeing this grow. [1] https://kinopio.club
This was released (and originally implemented) by Obsidian: https://obsidian.md/blog/json-canvas (see also https://news.ycombinator.com/item?id=39670684 )
It has basically changed the way I interact with LLMs and research and plan things
This looks a little pre-1.0, it's quite short on detail. For example: file (required, string) is the path to the file within the system. What kind of path, within what system? It's not clear that the 'file' type couldn't just be another kind of 'link'. If various fields like 'background' were defined to be URLs, that would offload a lot of complexity onto existing web specs.
> cover fills the entire width and height of the node.
Does that work like the CSS background-size: cover; or background-size: 100% 100%;?
> ratio maintains the aspect ratio of the background image.
Does that mean CSS cover? contain? Something else?
What is the upside of using an infinite canvas? I tried playing around with them in the past but I think my brain's mental model of how to parse data is incompatible with "clutter" (for lack of a better term) of an infinite canvas.
https://youtu.be/GblI7GI0jQ4?t=85
(Alas, the original desktop app (iMapping, in Java) as shown in the video is no longer being developed, and now they are only developing the web app (Infinitymaps) only run in the browser, which imo is not the best fit for infinite canvas apps which can be very resource-intensive)
Also see the app author's own all-purpose mega-map that he used to organize everything: https://youtu.be/bTQWL5wmdZY?si=6VrnPIErOzasisEe