2D cell layout

[caxelrud]

Hi, Great tool.
My suggestion for a new feature is to be able to create "dashboard" style documents: cells that are stacked vertically and horizontally.
What about a '+' on each (four) sides of an existing cell.

[fonsp]

@shashi You had some ideas about this, right?

[shashi]

Yeah my idea was to have a @cell() macro which creates a cell. It is syntactic because we don't want to allow dynamically creating cells, we want to statically know how many cells there are and what's in them.

So you can have a cell that is like

hbox(@cell(), @cell())

And you'd get something like hbox(Cell("uuid1"), Cell("uuid2")) and the cells with those UUIDs would appear inside the hbox -- this allows us to know exactly how to save a notebook as a .jl file.

[fonsp]

Why @cell() with no arguments - where do you type the code? Can you make a drawing?

And what about map(@cell(), 1:10)?

[j-fu]

Just to add this idea to have a more generic cell layout: it might be interesting to have floating cells
(or however you would call them): these would e.g. stay always at the top of the right screen half independent of the scroll state (very much like the live docs panel at the bottom).
These could be used for parameters or scroll bars which than could be changed without scrolling back and forth in the notebook.

[pbouffard]

Related: #528

[shashi]

@fonsp so if you support showing Pluto custom elements inside HTML displays and we make a HTML writing library or hack Hyperscript to use that, then we don't need a special cell layout, is that correct?

[shashi]

Oh btw, with that kind of composing, we'll end up re-rendering the whole layout every time a part of it changes, so nested layout-ed cells do seem "useful".

[fonsp]

(For context, shashi and I discussed the idea of being able to register Julia objects to Pluto, and have them accessible inside HTML as a web componentn <pluto-output object_id=876a8b68ab6 />. You would use this like

bond = @bind x Slider(1:10)

HTML("""
<div>
$(PlutoRunner.output([1,2,x]))
$(PlutoRunner.output(bond)
</div>
""")

which would render as

<div>
<pluto-output object_id=876a8b68ab6 />
<pluto-output object_id=b1cbc123b12 />
</div>

and it would allow you to create dashboards with arbitrarily composed UI elements and outputs.)

[fonsp]

Oh btw, with that kind of composing, we'll end up re-rendering the whole layout every time a part of it changes, so nested layout-ed cells do seem "useful".

Oops that's true

[shashi]

Oops that's true

I think that's why I said @cell() should be used.

map(x->@cell(), 1:10) should probably return a Vector of the same cell....

Pluto would replace that with:

map(x->Cell(<uuid>), 1:10)

where <uuid> is a single UUID.

[fonsp]

I have an idea!

How we would implement these <pluto-output> nodes is that we search for those nodes whenever a cell output is rendered, and insert the output of each pluto-output node. But if a cell updates a second time, then we can check whether the old cell output contained a <pluto-output> with the same object ID, and we just move over the DOM node instead of re-rendering.

Maybe this could also solve #515