Open caxelrud opened 3 years ago
@shashi You had some ideas about this, right?
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.
Why @cell()
with no arguments - where do you type the code? Can you make a drawing?
And what about map(@cell(), 1:10)
?
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.
Related: #528
@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?
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".
(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.)
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
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.
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
Okay wouldn't that still require rendering on the Julia side?
you mean that it would take longer for the output to show up because of the extra round trip?
I implemented the idea from my previous comment in https://github.com/fonsp/Pluto.jl/pull/1126 . You can use CSS flex and CSS grid to create cool layouts, for example https://fonsp-disorganised-mess.netlify.app/layout . @pankgeorg is working on a dashboard feature, see https://www.youtube.com/watch?v=nRmLfB-bKdc
This is exactly what I was looking for. I love what Pluto does, and where Pluto is going. I work in a group where many data scientists, at different experience/skill levels, contribute to creating analytical visualizations. Most of us use Jupyter Notebooks. The outputs are copied into ppt presentations, etc. I think it remains that way, largely because PowerPoint (and other SVG edit capable software), has pretty easy WYSIWYG layout editing. I've been working to try and make those "prototype notebooks" go more directly into presentations. One issue is that the default html renderer just creates things linearly, top to bottom (another renderer, based on reveal.js, can create something more like a dynamic slideshow, but seems kinda "too busy" for me). So I've been using the Voila Gridstack template (via nbconvert API). I believe that just leverages the CSS grid standard, probably like you do here. But I wish I didn't have to specify extra rendering steps, etc. (And I really like that, with Pluto, the notebook itself is Julia code)
I feel like a CSS grid should just be the default way to render things. Computer screens are 2D and work well because are retinas are 2D. Grids are a natural way to interact. I'd envision, if possible/easy, Pluto just always use a grid layout. Maybe the default would be to initially just have a single column (emulating the legacy behavior). Then additional columns could be added via widget. I'd say that when more than one column is enabled, cells would add left to right, top to bottom, by default. Then, after that, a person could move a cell to whatever grid spot they want. Do cells already have numbers indicating what order they were created in? If not, maybe have that, or perhaps a pop up indicating dependency parents and children, to allow an orientation of "original order". But that might not be necessary for this. Just some thoughts. Maybe some of this is already done, or in process. It seems Julia folks are often already on track towards good designs! :-)
I implemented the idea from my previous comment in #1126 . You can use CSS flex and CSS grid to create cool layouts, for example https://fonsp-disorganised-mess.netlify.app/layout . @pankgeorg is working on a dashboard feature, see https://www.youtube.com/watch?v=nRmLfB-bKdc
Was there something fundamentally wrong with this, like too slow, or did development resources need to be moved to other things, or something? https://github.com/fonsp/Pluto.jl/compare/main...2D-Report-Layout Maybe @pankgeorg hasn't had time to work on this?
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.