You are viewing archived messages.
Go here to search the history.

🕰️ 2020-08-20 22:16:18


Raathi 2020-08-23 23:10:32

I also heard usually all the jetbrains IDEs also have a very good search built-in. VSCode also got a separate symbol search but the effectiveness depends on the language server powering it based on the language you use.

Chris Maughan 2020-08-24 07:04:03

The key word is 'separate'. Apart from potential performance considerations, I don't know why you would implement file and symbol search in different places, with different keystrokes. I know what I need to find; just give me a list of all the things......

Chris Maughan 2020-08-24 07:04:54

To be fair, I haven't tried JetBrains, though I intend to start using CLion on Mac to see how that goes....

🕰️ 2020-08-22 20:02:59


nicolas decoster 2020-08-24 08:21:59

Very interesting! 🙂 Can't wait to see what you will build.

Do you have started some implementation? What do/will you use? HTML/JavaScript? Other?

What do you think of "reactive" framework, like Vue.js? Reading your intro, it makes me think this this kind of framework can be a good fit to implement tools with bindings between several representations (the spatial canvas, the sheet, others...).

nicolas decoster 2020-08-24 08:26:00

Also, I am just starting digging in generative art (in fact, I am a completely new to it), but my feeling is that your way to express constraints can be very interesting for it. And I was just wondering how randomness can fit in your system. I.e. like a spread with random intervals between magnets or with some magnets that deleted, etc.

Andrew Reece 2020-08-24 11:42:11

Very excited to see where this goes!

The snapping being an extension to/equivalent to dragging seems promising from a UX perspective, particularly if it can be made clear after the fact what 'type' of drag created it.

-> is there an exhaustive list of the type of snaps? e.g translate, scale, rotate... if it's a small list then there maybe some scope for replacing the circular nodes with appropriate icons (or adding icons somewhere...)

spreads seems like an intuitive approach to one of the CS fundamentals - repetition

conditionals seem more abstract, and I'm not sure to what extent you can represent them, particularly if the other visual variables (colour, opacity, texture, position...) are all reserved for the user... I imagine they'd probably need a separate view, either for abstract conditionals in general or looking at a particular group (however that's defined), and showing all the potential alternatives

🕰️ 2020-08-04 12:48:33


William Taysom 2020-08-24 09:19:39

@Cameron Yick that polyhedra viewer is so neat. Instead of clicking on operations, want to see the space of them expanded out in VR.

hamish todd 2020-08-25 13:39:54

Joshua Horowitz If you had any specific thoughts on this talk by the way, I'd love to hear them!

François-René Rideau 2020-08-24 16:01:24

Konrad Hinsen is that you? More like Past of Coding than Future of Coding. Or retrofuturistic? forepasséistic?

Konrad Hinsen 2020-08-24 18:30:06

That's me indeed! It's about the past, but with the goal of learning for the future. Let's say the future of the past 😀

🕰️ 2020-08-20 23:34:30


tj 2020-08-24 23:22:48

Jack Rusher thanks for that recollection and story about tappers/listeners... this is a great reminder of why teachers, educators (and 'communicators') are professionals who's skills should be recognised and appropriately valued (within society), as that process of bridging between different points of understanding is (often) by no means easy, and as you say, can be easy to even lose sight of from one's own point of understanding... #fairpayforteachers! 😉

Chris Rabl 2020-08-27 04:23:27

I've been doing more and more writing lately, and have been wishing for a tool that allows me to write my outlines, drafts, and final compositions in the same editor window with the ability to toggle any of those "layers" on and off at will, merge them, copy selections to new layers, etc. It would work sort of like Photoshop but for writing... I have a feeling these principles could also work as an IDE extension (imagine being able to hide the "code" layer and show only the "comments" layer, or the "documentation" layer). Curious to hear your thoughts, or whether anyone else is working on something similar?

Ivan Reese 2020-08-27 04:38:20

This is a fascinating idea and I've never seen anything like it. I love the approach of taking something we take for granted in the GUI tools world and folding it back into the textual tools world. There's an open-endedness to this that is exciting to me the way Roam was exciting when I first saw it. I hope you keep exploring this space and share what you learn about it.

Chris Granger 2020-08-27 05:20:15

Yeah this is rad. 🙂 I designed and built a prototype of what you’re describing back when I was on Visual Studio - I even called it editor layers. Lots of our designs have trickled out over the last decade, but sadly that one hasn’t yet. We did all sorts of cool stuff with it, turned types on and off, reduced things to signatures, embedded profiling information in, unit testing coverage/passing, git blame-like stuff, callers/references, even real-time inline diffing, all toggled by this little series of buttons attached to the top right of the screen. The design came from thinking of the editor a bit like an overhead projector and you just kept putting transparencies over top whatever was there - different sets gave you very different views on the thing you were looking at. That same idea eventually was the source for the name “Light Table.”

Years later I was surprised to see Gary Berhardt basically produce the same design, with many of the same examples! 🙂

Chris Granger 2020-08-27 05:23:12

We did something similar in the Eve editor as well where you could control the sections of the document that were visible at any point in time, though that’s a little less layer-y and a bit more “build the document out of the pieces that are relevant.” We did also have a performance layer, but we never exposed the panel to turn it on.

Ivan Reese 2020-08-27 06:00:46

The thing I get from this, that I didn't get from A(n) Whole New World (for instance) is that these Rabl layers can be nothing more than a named text style with a visibility toggle. In the video, the style is just a color. The style could be a little fancier — maybe different fonts, why not. But the process of defining a new layer ought to be just like photoshop: add a layer on the fly, name it (or not), put stuff in it. The barrier being so low, you don't even acknowledge how powerful it is.

Sure, we could start imagining all the built-in layers a code editor could add, and that's cool... but that's a different thing than a tool just for a writer to define their own conventions around. Like the difference between adjustment layers (PS) or nondestructive filter layers (Pixelmator Pro) and regular layers (every nontrivial image, video, music, etc editor).

I want both, but they're separate ideas.

Mauro C 2020-08-27 06:34:19

Very simple yet powerful idea!

nicolas decoster 2020-08-27 06:42:02

Great Idea! I also like that the user only creates a layer and start to add text to it, without any meaning other than the one she decides according to her workflow.

Tudor Girba 2020-08-27 06:43:01

In Glamorous Toolkit, we utilized both ideas. Here is an example that covers both dimensions:

  • we only show a markup when the cursor goes nearby (so, toggling is implied by the user action), and
  • we insert arbitrary previews (not only text) live. These can be added by the syntax highlighting.

🐦 Tudor Girba: The idea of a layered editor was recently proposed by @crabl:

@spiralganglion wants it everywhere:

We already employ this in #gtoolkit. Eg, for showing the markup only when needed or showing previews live directly in the editor👇

🐦 Ivan Reese: This is a perfect Future of Coding demo — a super simple proof of concept, of something I’ve never seen before, that is so obvious in hindsight, that pulls disparate ideas together, that opens the door to much further exploration.

Shalabh Chaturvedi 2020-08-27 06:43:45

Very appealing idea. I'd love to write my polished, unpolished and draft snippets etc into different layers.

Andrew F 2020-08-27 06:55:25

Oh hell yes, give it to me now. My current workflow for writing fiction sort of emulates this in plain text: I often put an outline thingy (list of beats, anyway) at the start of a scene and delete them later. I also tend to mark things for future deletion with square brackets if I'm not sure yet whether I want to (or to give me time to cope with killing a favorite line). I would love to instead shunt them to a different layer. I crave layers every day, and so I've thought a lot about them, for outlining as in your demo, for coding as in Bernhardt's talk, and for data representation like Nick Smith and @Orion Reed have been talking about, e.g. if you're extracting and transforming data from a word doc, using layers as a way to separate info that is portable between formats and Word-proprietary details that just need to stay around if we want to round-trip processed data into the original format.

So yes, I've been working on it in the sense of thinking and wishing really hard. Still working out the details.

Konrad Hinsen 2020-08-27 08:23:55

This looks very nice! I use org-mode in Emacs in much the same way, but it's a lot more cumbersome to use because org-mode, like all outline/folding editors, supposes a hierarchy of detail which isn't always there. That's also true of the markup display technique in GToolkit that Tudor Girba just mentioned. That's a very nice implementation of detail-hiding, but not the same as unrelated layers.

Tudor Girba 2020-08-27 08:31:14

I simply said that the mechanism can be used in many ways in the two classes mentioned In the thread: either to hide/I hide or to augment with external content. The example exercises both. Indeed for a different use case than the initial one.

William Taysom 2020-08-27 08:34:32

I like the flexibility of it.

Chris Maughan 2020-08-27 10:15:51

I already experimented with this idea for markup and inline graphics plugins in my text editor. It's my hope that I can build a 'markdown wiki' hosted entirely in the editor, and single click deployed to github. One day I can use it to write documentation or update my website. I'm surprised more editors don't automatically format and let you edit markdown tags live inside documents; it feels like a natural extension that should have been done a while ago. The layers in the demo are more like 'folds', yes? i.e. the layers aren't independent of the text paragraphs on other layers - they are stacked with them? It's powerful stuff. I can imagine writing emails this way; but maybe that could result in embarrassing mistakes!!

Christopher Galtenberg 2020-08-27 13:31:11

This idea has some potential overlap with Progressive Summarization (with a large community interested in new tools)

Ivan Reese 2020-08-27 15:40:16

I am so excited by this idea of layers for arbitrary author-determined organization, I'm going to just rattle out some ways I can imagine it being used. All of these are written from a writer's perspective:

  • I'm not sure whether I want to say "John while Henry had had had had had..." or "Sarah while Kim had had had..." here, so I'll put the latter on a different layer here so I can come back and switch it later if I change my mind.
  • I'm going to put all copy-pasted quotes on a different layer, and URLs to sources on their own layer too, so I can be sure to catch them all when I do biblio at the end.
  • I want to write a parenthetical in this parenthetical, but that's going to be awful for readability. I'll throw it on a new layer, so I can catch it when I come back for rewrites.
  • I hate this sentence. I don't think it needs to be here. Let me hide it and live with that for a while.
  • I think I might be using too many adverbs. Let me make an adverbs layer, and I'll pull things onto that as I re-read, and then see how bad it actually is.
  • And.. new layer for "tweetables", and a separate one for "pull quotes"...
Shalabh Chaturvedi 2020-08-27 16:00:40

Yup I'm now thinking about how to add it to my editor. This opens up a whole new dimension. Kinda like transclusion, but simpler, because the content isn't "somewhere else, transcluded here" but rather "in another layer, but right here". There is an implicit, global organization (the flattened document), but then you can expand the flatness into the different dimensions as needed.

Christopher Galtenberg 2020-08-27 16:12:12

In my editor, it's possible to compact/expand different header levels - going to think about commands to make this straightforward

Cameron King 2020-08-27 18:20:32

I've been kicking around an idea for a while in the same vein, but coming from the direction of reading instead of writing. I like to take different kinds of notes--structural, commentary, cross-reference (within a work/to other works), summary, etc. I've been thinking about building something around an e-book reader that would allow me to move between and freely intersperse different forms of notes.

So, I could start with a view of my structural notes (my "map" of the book; possibly involving visualizations) and quickly drill down to the right section for deeper reading. Then I could add a cross reference by searching through my corpus for the right information, then pull it up side-by-side and add shared commentary--which can then serve as a new work that I can then structure, commentate, cross-reference, and so on.

It's a view of writing (or note-taking) that emphasizes the connection between the stimulus (the original work) and the response (the layers of annotation), always keeping them linked. So, theoretically, if I published a blog post and a reader owned a book I reference in the post, they'd be able to move directly from a reference in the post to the relevant passage in the book, then be able to surf my layers of annotation (and add their own) if they so desire.

Haven't gotten around to doing anything yet, though.

Andrew F 2020-08-27 18:26:57

I pitched the idea at some friends in a writing slack and they were also excited.

Chris Maughan 2020-08-27 18:46:56

That's at least 2 more people working on editors; I'd love to see these projects.

Chris Rabl 2020-08-27 18:58:47

Wow! Thank you all for your kind words and feedback, I certainly wasn't expecting to strike such a chord 🙂 I'm super excited to see this concept appearing in some projects around here (especially the work that Chris Granger and Tudor Girba have done!) if you're interested in talking about things like this, my DMs are always open. Like Christopher Galtenberg mentioned, it would be so crazy to incorporate some element of progressive summarization (or spaced repetition!), so I'll definitely be exploring that as I start building this out.

Dennis Heihoff 2020-08-28 16:59:54

Curious to hear people's thoughts about how different this is from using nesting content. Seems very similar to me except that children are inlined when visible. When nesting, for example:

- 1

  - 2

    - 3

- 1

  - 2

    - 3

      - 4

the user would need a shortcut or UI to choose a global depth (level) which would open all nodes until a certain depth (1,2 or 3, 4).

I think either approach (flat & nested) possible in roam today by using tags & filters. So the user would have to tag a block like #ideas and the apply the appropriate filter.

Ivan Reese 2020-08-28 18:17:18

You could implement one in terms of the other, as long as you allowed arbitrary showing/hiding, rather than needing to open nested levels strictly in order. Beyond that, the difference is entirely in the UI. Nesting mixes content and presentation, layers (as imagined in this thread) don't. What seems nice about nesting is that it's easy to move things between layers — just indent/outdent to the level you want.

Andrew F 2020-08-28 21:11:35

The way I understood it, this sort of layering is very different from hierarchical nesting. The individually showable/hideable segments in an org-mode style outline are confined to mutually exclusive regions (wrt their "level"), whereas layers can freely intermingle through the full extent of the document. To recover layers from an outline, you would need to not only have an operation that hides/shows everything at, say, level 2 without changing the parent's visibility, but you would need to have other "levels" under level 1 that actually sort of compare the same as 2, in the sense that they are always siblings, but distinct for the purposes of the global show/hide command. I'm not sure that would be enough, actually. Once you add the idea of arbitrary visibility, it's hard for me to think of it as hierarchical at all.

Looked at another way, nesting induces a total order on the "layers" that may not be desirable.

So, I would argue layers are more general than nesting. Nesting is easily implemented in terms of layers (one per node), but nesting is not enough to implement layering without at least using weird hacks.

Shalabh Chaturvedi 2020-08-29 04:47:22

My mind keeps going back to this idea of layered text and everything you could do with it. What about true overlapping layers? Would it make sense? E.g one layer may have a text snippet and another layer may have a link that overlaps exactly with that snippet. It can subsume all embedded markup. You just dump all style info into the style layer, exactly overlapping with the parts you're styling.

Shalabh Chaturvedi 2020-08-29 04:48:15

OK if layered text, and not plain flat text, was the lingua franca of Unix, what would programming languages look like?

Andrew F 2020-08-29 05:20:57

It would be cool to have OS support, but I worry about pipe-based composability. I think that's essential to being a Unix "lingua franca". To process a piece of layered text, you have to know what layers exist and what they mean. Most of them are probably very application-specific, even stream-specific. You could generically pass them through, but then an entire ecosystem of utilities has to deal with format complexity they can't benefit from and can only mess up. At that point it's probably better to build a full object system like Powershell, since you're already paying for most of it.

Shalabh Chaturvedi 2020-08-29 05:38:25

Pipes could still be flat text (you'd select or flatten the layers when you pipe), but what I was getting at was how the 'medium' affects what we design. We design PLs with a 'flat' grammar because we are designing languages represented in flat text. Layered text is still very free form and Unix like, but would lead to different kinds of PLs that make use of the layers.

Chris Maughan 2020-08-29 07:38:16

I'm trying to get the implementation of this clear in my head, since I'm seriously considering adding it to my text editor to help with other issues. One thing I've been thinking about is annotating shaders with widget information. For example, what if my flattened code looked like this:

/* Layer:1 Widget:Slider, Min:0, Max:10 */ float val;

Effectively showing layer 1 would enable editing of how the float value widget would work. Hiding layer 1 just gives you the shader code with the widget popup.

As I understand it layers aren't nested, but I think you'd need to be able to 'expand' deeper layers into upper layers without opening intermediate layers. For example:


L1: ------|-------

L2 ----|----------

The | represents the location in Layer1 of layer2. Expanding layer 1 would show layer 2, and inside layer 2 there is another point where a further layer lives. But if L2 is shown but L1 is not, then L2 would effectively appear where the | is on layer 0. I think?

And of course, edits to the L0 layer would wind up 'moving' the insertion point of Layer1. But what about deleting the region around the expand point? I guess the next layer just drops into the nearest sensible position.....

I do something similar with Markers in my code, which can be used for things like compile errors. Which brings up the next issue of compiling code and referring back to locations in the source that may not be expanded, etc. 😉

So in short, interesting issues that might lead to a powerful system......

Chris Maughan 2020-08-29 07:45:04

Implementation note: with layers that contain extra information comes the possibility that a flattened file could not be just dropped into a game engine without sanitizing. So for this case, comments in layers makes sense because it keeps the code compiling and keeps it as a plain text file. But it's just a convention.

Chris Maughan 2020-08-29 07:49:09


Chris Maughan 2020-08-29 07:51:26

And collapsing Layer1 from my code sample above could have a special display; I was thinking some kind of mark in the code to indicate points where layers are embedded; but suppose the widget was a color picker.... then the collapsed layer 1 would be a color swatch. Nice....

And not forgetting that layer 1 is effectively several fragments, since there can be multiple point in the text where layer 1 pieces are inserted. Hmm, this might keep me going for a week or 2!

OK, I'll stop designing out loud......:)

Konrad Hinsen 2020-08-29 15:44:44

Shalabh Chaturvedi One use case would be to make type annotations a different layer, to reduce visual clutter. And that would open the way to having multiple annotations on code, not just a single rigid type system.

Chris Rabl 2020-08-29 17:05:02

Chris Maughan feel free to keep designing out loud :) It's really helpful to hear this sort of feedback because there are just so many ways this idea can be interpreted. My proof-of-concept was deliberately open-ended for this reason: I really like to see the sorts of assumptions folks make once they start implementing a concept such as this and how practicalities like the choice of underlying data structure influence which affordances become possible or impossible as a result.

Scott Anderson 2020-08-27 18:14:42

A year ago I was working on VR Visual Scripting in Facebook Horizon. They've recently started to share some more information leading up to Facebook Connect. I figured the scripting system would either be largely the same, or entirely rewritten since I left. It seems like it's mostly in tact based on documentation shared (

Scott Anderson 2020-08-27 18:22:26 for some examples (this is all new content from when I was working on the project)

🐦 Oculus: Hello from Horizon! We’re creating a new social VR experience that ignites your imagination and brings people together. As our invite-only beta community builds new worlds, follow along at @FacebookHorizon for a peek behind the curtain.

Scott Anderson 2020-08-27 18:22:45

Unfortunately it looks like it didn't really advance much past when I was there, which is not a good thing imo 🙂

Ray Imber 2020-08-27 18:49:50

Reminds me or (or the grand parent of those kinds of systems, for VR.

It's a great idea that's well suited for VR. If it's even passingly similar to those other platforms I bet it will be a wild commercial success (which VR desperately needs anyway, so good for them).

It unfortunately doesn't seem to be pushing the boundaries of that kind of platform very much though. It's very status quo in a way.

Scott Anderson 2020-08-27 19:01:33

yeah it's a Facebook product

Scott Anderson 2020-08-27 19:03:22

It was extremely challenging (and according to some people I know that are still there, still challenging) to propose reimplementing direct features from any of the products that inspired it

Scott Anderson 2020-08-27 19:03:35

let alone anything that pushed boundaries

Ivan Reese 2020-08-27 20:39:39

If there was something about this that was particularly interesting, that survived through to the public (or that you feel comfortable talking about), what would it be?

Scott Anderson 2020-08-27 21:19:21

I'm still not 100% sure how much survived based on the documentation, the basics are there

Scott Anderson 2020-08-27 21:23:53

There are also no screens or videos of the final UI, but that's probably what will disappoint me the most, the description in the documentation makes it sound like it's mainly the same as when I left

Scott Anderson 2020-08-27 21:26:04

so I designed the system to be a 2.5D s-expression-like editor, inspired by scheme bricks and scratch, it was meant to use mostly the same tools as the world building tools (which are featured in some of the videos)

Scott Anderson 2020-08-27 21:26:28

from the documentation it looks like that didn't happen, and it's mostly a big list view with lots of buttons and drop downs

Scott Anderson 2020-08-27 21:28:21

so probably the most interesting thing about it is it allows for semi-collaborative editing and live coding by default (although when I left objects reset when scripts changed)

Scott Anderson 2020-08-27 21:30:57

the core of it was an object oriented message passing system. So each scripted object has a single script associated with it, and communicates with other objects via message passing

Scott Anderson 2020-08-27 21:32:36

originally it was a lot more dynamic, but while I was there it was pushed to be more and more static (I wanted super loose coupling, my manager wanted really tight coupling that looked like a more "traditional" OOP language and explicit used method instead of message in all communication)

Scott Anderson 2020-08-27 21:32:59

it seems like the tighter coupled version won out based on the UI description, but its hard to tell, might be multiple ways to do it

William Taysom 2020-08-28 07:47:05

Scott Anderson what do you think of Neos VR? It seems to have a delightfully, awkwardly, awesomely weird, hm, flexibility to it.

Scott Anderson 2020-08-28 19:05:52

I used it as a counter example

Scott Anderson 2020-08-28 19:06:10

Some members of the Horizon team were really pushing a node and wire UI

Scott Anderson 2020-08-28 19:07:04

and we had a working version of it at one point, and Horizon can still use wires for object references

Scott Anderson 2020-08-28 19:07:38

In two dimensions managing node and wire complexity can be hard, but with zooming and organization it can be ok... I guess

Scott Anderson 2020-08-28 19:07:47

in three dimensions it's a much harder problem

Scott Anderson 2020-08-28 19:21:30

Dreams uses node and wire and solves it by making it a zoomable 2D UI constrained to a plane and clipped (basically nested floating 2D windows in 3D space)

Ivan Reese 2020-08-28 19:26:52

Yeah, the 2d-in-3d seems to be the best of both worlds, for my money.

Scott Anderson 2020-08-28 23:06:25

I do want to experiment with very 3D programming languages, but occlusion is an issue. Two ideas I thought of are a 3D wire world/redstone variant, and tangible programming inspired by modular robotics kits

Scott Anderson 2020-08-28 23:15:34

oh 3D graphical rules rewrite system in the style of KidSim

Scott Anderson 2020-08-28 23:41:36

Building a 3D esolang in VR would also be fun

William Taysom 2020-08-29 09:18:54

Thanks for your thoughts Scott Anderson. I've been messing with a 3D esolang — though progress certainly ground to a halt with the ending of the world. My superficial constraint has been no text. The real constraint is to make it "non-symbolic" in that representations cannot be "arbitrary." Representations need to be structure preserving in a sort of uniform way.

Mariano Guerra 2020-08-28 14:58:40

In case the two minute summary was too much in too little time, here are longer versions I just did: and

Dennis Heihoff 2020-08-28 17:10:36

What started with me reverse engineering notion became a data-first recursive UI resolver I called

Here's how it differs from most common technologies today:

  • Approaches to UI development like react.js + graphQL require UI components to request data in a shape that satisfies the UI tree. This means the shape of the data is determined by the UI tree. Root takes an inverse approach where the UI tree is determined by the shape of the data.
  • A major benefit of this approach is that the UI layout is thus entirely determined by data, data that can be traversed, transformed and stored in arbitrary ways and by arbitrary means.
  • This is powerful for unstructured, user-determined, block-based UI's like rich documents (think Roam Research, Notion etc.) enabling queries and functions that, based on users' demands, derive the optimal presentation of a document.

It packs a few more punches. The best example is probably this in about 200 LoC ( Github repo

Brian Hempel 2020-08-28 17:25:56

nice. see also Chorus, where data = UI

Brian Hempel 2020-08-28 17:27:37

🐦 yoshiki: I've been jamming on this concept for making data-driven designs. Given some JSON, this app will provide you with an interface to describe how you want each entry styled, allowing you to gradually create a more complicated design. Here I create an airbnb-ish app.

Dennis Heihoff 2020-08-28 17:40:21

Brian Hempel thanks for the pointers. these are great!

Dennis Heihoff 2020-08-28 17:41:46

side note, the biggest project I wrote with root is (unfortunately not OSS yet). As with any approach data-first comes with its own set of tradeoffs. Happy to elaborate if anyone is curious.

Kartik Agaram 2020-08-28 17:59:31

I love how root renders all data by default. This helps with the 'dataphobia' being discussed over at

Dennis Heihoff 2020-08-28 19:01:43

thank you! I commented on that thread. Yes, it’s like a data browser incrementally becoming a UI. Lots can be done there to improve DX, for example analyzing strings for urls/images that can be embedded automatically. All kinds of remembered hiding and showing of state and so forth.

Kartik Agaram 2020-08-28 19:20:31

The other project this reminds me of is PANE..

Garth Goldwater 2020-08-28 23:32:45

this looks really cool! can you talk a bit more about how the data directs the ui tree?

Dennis Heihoff 2020-08-29 17:58:11

Kartik Agaram tried finding PANE unsuccessfully, got a link?

Kartik Agaram 2020-08-29 18:03:00

Sorry, I was on the phone when I wrote my previous comment. The author posted new work here recently:

[August 22nd, 2020 1:02 PM] joshuah: I'm prototyping a new approach to drawing dynamic pictures with direct manipulation. So far, I've been calling it "Apparatus with Magnets". We'll see if the name... sticks. :wink:

Here's a "project proposal":||…. Progress is slow but steady. Feedback is welcome!

Dennis Heihoff 2020-08-29 18:09:41

Garth Goldwater sure! When you define your ui-root you give it a lookup function and content-keys . from there it works like reduce: you pass it a root-id that it passes to lookup. lookup returns data that root wraps in your defined UI components or the default component. It also looks for content-keys on lookups return value, passes those to lookup and recurses down all the paths. Upfront root is not aware of the structure of the data. Given the id, lookup can run arbitrary computation. It can for example issue an http request or read from indexedDB. It can return data or a promise that root will resolve and eventually render. It’s dumb by design and that gives it lots of flexibility.

Garth Goldwater 2020-08-30 16:17:23

thanks! checking my understanding here: so lookup is in charge of grabbing the data from content-keys and returning it in some shape, and ui-root decides how to wrap that unit of data in UI markup, and then runs lookup on the returned shape’s content keys field?

and root-id is just where ui-root starts that process in the data tree?