IRdisplay icon indicating copy to clipboard operation
IRdisplay copied to clipboard

Adding metadata/styling from repr output

Open jankatins opened this issue 9 years ago • 5 comments

[edit] Currently, without a change in the frontend, the best we can do is simple send the complete metadata to the frontend in the normal display data: If we manage the styling, we send the styling only once on the first exec of such code. But then the frontend (=Notebook) could reevaluate the cell which currently has the styling and we would no notice this and no send styling, and the notebook would end up without styling information.

See also https://github.com/jupyter/notebook/issues/116 and https://github.com/jupyter/roadmap/pull/9 [/] It would be nice to be able to specify that something only needs to be displayed once, e.g. the styling for a table or an interactive plot.

The repr side probably only needs to document the way this should happen, the actually implementation needs to be in the display package.

From the old issue comment by @flying-sheep:


yeah, the point is that there needn’t be a new interface: we can simply add attributes to the character()/raw() returned, which avoids changing signatures.

an example where i loop a bunch of things, create their HTML reprs and only do setup once:

repr_html.stuff <- function(x, ...) {
    ...
    structure(html_markup, setup = list(stuff_setup_script = '<script>...</script>')
}

html_setups_seen <- character()
for (thing in things) {
    thing_repr <- repr_html(thing)
    thing_setups <- attr(thing_repr, 'setup')
    new_setups <- stuff_setups[intersect(html_setups_seen, names(thing_setups))]
    html_setups_seen <- c(html_setups_seen, names(new_setups))

    display_html_setups(new_setups)
    display_html(stuff_repr)
}

PS: for the implementation, we should have a list of seen setups, keyed by format and class. this way there will be less potential for name collisions. or we just us the passed code itself as key.

jankatins avatar Mar 09 '16 15:03 jankatins

i wanted to wait for notebook itself to implement such functionality, but actually we could do this ourselves.

anyway: can you find the notebook issue about this? there has to be one…

flying-sheep avatar Mar 09 '16 16:03 flying-sheep

At least my search-foo didn't find one in jupyter_client and now notebook and the old ipython one.

But for me, the pro/con list makes it pretty clear that this is not a thing which should happen in the notebook backend/frontend but on the kernel... Just imagine a plot library adding their own xxx kb css and js files to each call (maybe even 2x because html and markdown output?) and then having that in the ipynb file :-( In knitr, the stuff never reaches the final output file, so it's similar to an in-kernel-solution.

jankatins avatar Mar 09 '16 17:03 jankatins

Tricky, because what if the output which has the styling is cleared later?

takluyver avatar Mar 09 '16 19:03 takluyver

Oups, that the reverse "restart the kernel" problem... so reruns of all cells (or just the one which got the styling) do not work... So it seems we really need something in the notebook and do it there?

jankatins avatar Mar 09 '16 21:03 jankatins

@jdfreder put together a proposal to help with this and it's generally unsolved.

rgbkrk avatar Mar 10 '16 15:03 rgbkrk