You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[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 jupyter/notebook#116 and jupyter/roadmap#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.
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:
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.
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.
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?
Activity
[-]Adding metadata/styling to repr output[/-][+]Adding metadata/styling from repr output[/+]flying-sheep commentedon Mar 9, 2016
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…
jankatins commentedon Mar 9, 2016
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.
takluyver commentedon Mar 9, 2016
Tricky, because what if the output which has the styling is cleared later?
jankatins commentedon Mar 9, 2016
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?
rgbkrk commentedon Mar 10, 2016
@jdfreder put together a proposal to help with this and it's generally unsolved.