There's more than one way to do it.

I think the way I would do it is traverse the created views to get a mapping of rect coordinates that you could use. horizontal and vertical layout are really just measuring and stacking items. It seems like you're working with a fairly regular grid, so it wouldn't be unreasonable to write a few helper functions to do the layout within the grid.

I'll write some example code. One sec.

Awesome thanks!

ok, here's quick sketch. It's a little longer than I'd like, but hopefully most of the uninteresting parts can be hidden away in a util.clj or similar. This solution uses zippers. I can update the example with something else, but zippers do a really great job of fulfilling the OO equivalent parent/back references. The other thing to note is the introduction of IContentOffset . ui/bounds and ui/origin conflate hitboxes, view extents, and probably a few other things. This is a known problem and something I'd like to fix in membrane, but I'm also trying to avoid partial fixes until I get a chance to think things through a bit more (or reference someone else who has thought it through).

I think @U63D7UXJB has also been working on diagramming and maybe has some tips.

I've also done some basic diagramming. It would be nice to investigate building a standalone library similar to mermaid.

Awesome thanks for all that! Really appreciate it

If the layout is grid based, I might also explicitly model that.

It's easy to create a protocol which you use to lay out elements eg top-left bottom-right, also easy to write your own eg horizontal-layout

What would be more involved/interesting might be changing how events get dispatched based on capture but it's not super necessary as they just get passed along

It's tricky because it seems like working at a higher level like this (without pixel coords, or possibly any coords, but as you say, explicit nominal coords might be worth it too) is desirable when possible, but it takes a bit of effort to get there too, it's sort of unclear before implementing a couple options which will be the nicest to actually use

I think because html DOM is such a cluster fuck people might assume rolling your own here is harder than it is

I should keep a list of missing utilities somewhere so that they can either be added to membrane or packaged in helper libraries.

or even just a list of utilities people would like to see.

I always hit this pattern of problem where I want to draw say a graph, look up some libraries, find one that looks nice, say https://js.cytoscape.org/#notation/graph-model (i tried this first. Well, after graphviz which also wasn't really doing what I want without hacks). But then before the day is over I always hit something that is basically impossible to express cleanly in that framework. Like I wanted to add labels to the x and y axis here, you can't do that in cytoscape without awkwardly using separate graph items as labels, or shoving the graph in a dom and trying to line things up there. Like it seems like it would be ideal if a "graph" library could just plug into an existing ui/layout engine (like membrane 🙂 ) and it's job is just to draw the lines nicely between things with splines and whatever nice graph features. But instead every visualization/charting/etc library re-implements it's own layout/coordinate stuff in a non-compatible way, and they all have a learning curve, and you always hit limitations (at least I always do)

Yeah I've felt this, if they yielded effects/data it would help but people also want interactions

Added a https://github.com/phronmophobic/membrane/discussions/66#discussioncomment-5085064 in github discussions to start keeping track of "missing pieces".