Viewing a table object in a new window

[pdeffebach]

In notebook mode, it is possible to right-click on a cell and select "Create new view for output". Is there any way to do this in the code itself? Something like

import pandas as pd
df  = pd.read_csv("file_path...")
new_view(df)

This would then open up a new tab for easier viewing of a very large table, and not clog up your notebook.

I apologize if this is already a feature, or is against the philosophy of the ipython notebook.

On second thought, would this only be able to be done as a console command? I can understand how this would make python notebooks not transportable at all.

[ellisonbg]

I haver thought about adding some optional metadata that kernels could provide to indicate that output should be put either in a new main work area panel of even in the left sidebar. My only hesitancy on this is that it adds JupyterLab specific metadata to kernels, which wouldn't work with other frontends. However, if that metadata is optional, maybe it is ok?

@rgbkrk I would love your take on this?

One big usage case that I ran into is the progress bars that many libraries now have (such as keras). It would be nice to have them render in the left sidebar so those things don't clog up the document.

[rgbkrk]

People have certainly asked for ways to dock outputs in a separate window in nteract. It's a doable thing, even there. For us it means we're making another window. I could imagine a metadata field or message type (I'd lean towards this more) that says to "dock" separately. Not sure what the semantics would be.

[ellisonbg]

OK, that is helpful. I will think more about the semantics - not obvious to me right now.

…

On Sat, Jan 20, 2018 at 5:00 PM, Kyle Kelley ***@***.***> wrote: People have certainly asked for ways to dock outputs in a separate window in nteract. It's a doable thing, even there. For us it means we're making another window. I could imagine a metadata field or message type (I'd lean towards this more) that says to "dock" separately. Not sure what the semantics would be. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3692 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0FKLv-r5E7QLfV2MG0N55UeQumLaks5tMowvgaJpZM4RlT4N> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[rahuldave]

I'd love for this sort of access to be provided at the js level. This would make it possible for an extension to, say on the click of a button, use the sandbox extension to load a web site in the right hand side panel. Similarly a button could be provided in an enhanced dataframe output in the notebook view which opened the dataframe rstudio style in a separate panel (whats currently provided by the csv viewer panel)

(I do know you can add new view for output, but i's like to be eventually be able to do this by default. Here is a use case. I'd like to write a nbviewer style extension, in which clicking on a cell could bring up a discourse forum on the cell for discussion in a new sandbox view. Wood be cool for teaching)

[xappppp]

Maybe I'm wrong, but the link below seems to be a useful trick.
https://stackoverflow.com/questions/40554839/pop-out-expand-jupyter-cell-to-new-browser-window

[saulshanabrook]

I could imagine a metadata field or message type (I'd lean towards this more) that says to "dock" separately.

@rgbkrk What about a custom mimetype that nests other mimetypes? I am just thinking about what's easiest to implement in kernel code.

[rgbkrk]

@Carreau and I talked about this a while ago (some sort of container mimetype). What we ended up figuring out was that having display take variadic arguments made it really easy to display lots:

display(
  obj1,
  obj2
)

What I was saying about that metadata was something like this:

display(obj, metadata=dict(dock=True))

or simply:

display(obj, dock=True)

My thoughts on this are pretty old / stale though.

[BoPeng]

I think this is exactly the %preview magic of the SoS kernel for Jupyter where the preview of variable is sent to a side panel. The proposed solution for JupyterLab was a transient_display_data message and a matching UI.

[aldanor]

Just wanted to mention another somewhat typical usecase -- long-running tasks (e.g. machine learning / model fitting) generating a ton (thousands of lines) of intermediate output, inline, in real-time.

Something like a %preview magic would be absolutely cool to have, so the output is automatically routed to a new view. Would it have to be text (stdout/stderr) only, or rather anything that can be display()ed (e.g. dataframes or plots)?

[BoPeng]

Yes, the %preview magic can display tables (searchable and sortable) and figures. You can use it now with classic jupyter. Let us know if the kernel you are using is not supported by SoS yet.

[aldanor]

Yep, that's very close. Would be great to eventually have it working this way or another in a default jupyterlab installation, even if in a simplified form of some sort.

[gkvoelkl]

Doing “create new view for output” with Python API? #4021
Will there be a solution?
Is there an Python API that can communicate with jupyterlab?
I wrote some nbextension. It is very difficult and not intuitive.
It would be great if there will be a pythonic way of writing extensions in jupyterlab.

[pdeffebach]

Would the new DataBus feature in #5857 be helpful in making this feature easier to implement?

[saulshanabrook]

Would the new DataBus feature in #5857 be helpful in making this feature easier to implement?

Possibly! We haven't settled yet what the UX experience should be for opening a dataset from a notebook.

[SylvainCorlay]

It seems that the jupyterlab-sidecar package fills that purpose perfectly.

[gjoseph92]

@SylvainCorlay I disagree there. When JupyterLab natively provides a rich system for managing views, having a separate widget to duplicate that functionality isn't a good long-term solution.

For example, you can't drag a sidecar to another side. You can't drag it to split the view horizontally instead of vertically. You can't drag it to the tab bar to display in as its own full-size window. You can't navigate between sidecars with the standard keyboard shortcuts. It's a bit of an awkward workaround for a system that already provides this functionality well.

Allowing code to open new native views opens the door to creating much richer UIs within the JupyterLab ecosystem. (What I'm trying to do right now, and finding this a blocker.)

LMK if there's a way I can help out with moving this along.

[gkvoelkl]

I tried sidecar. It is a great tool. But so far I understand, you can’t control the window with parameters.

What I need is an Python API that can communicate with Jupyterlab. It would be easier for Python programmer who are not so good in JavaScript.

@gjoseph92 I think it would be great if JupyterLab has a Python API to all UI stuff that’s already available. I do not know much about Jupyterlab. I did some Jupyter-widget. If i could help, I am in.

[ellisonbg]

My thinking on this has evolved over time. The backend shouldn't need to reason about the layout - as the layout is highly contextual and personalized. A better approach will be to separate the providing of the data in different formats from the rendering. This is what we are trying to do in the new JupyterLab data registry and explorer: https://github.com/jupyterlab/jupyterlab-data-explorer with this in place here is how it would work: * Datasets in any format get registered with the data registry. * The data explorer shows the users the data sets. * Extensions can register renderers for those data sets and those renderers can own the questions of where/how it is rendered. More details about the architecture and design can be found on the above repo. Cheers, Brian

…

On Mon, Jul 1, 2019 at 11:42 PM Gerhard Völkl ***@***.***> wrote: I tried sidecar. It is a great tool. But so far I understand, you can’t control the window with parameters. What I need is an Python API that can communicate with Jupyterlab. It would be easier for Python programmer who are not so good in JavaScript. @gjoseph92 <https://github.com/gjoseph92> I think it would be great if JupyterLab has a Python API to all UI stuff that’s already available. I do not know much about Jupyterlab. I did some Jupyter-widget. If i could help, I am in. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3692?email_source=notifications&email_token=AAAGXUA7RGQOLYPYXZL2B73P5L2G7A5CNFSM4EMVHYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZAHWEQ#issuecomment-507542290>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGXUGART6ETZGR3FFOL6DP5L2G7ANCNFSM4EMVHYGQ> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[NumesSanguis]

I want to add another perspective to this discussion: Cooperation between Data Scientists and other teams (Dashboard).

• The problem that @ellisonbg Data Explorer solves is that of Notebook clutter by separating the data from the code and giving powerful tools for insights. This is very helpful for the Data Scientist (or related titles), but doesn't help when you want to communicate findings to Marketing / Consultancy / other people less fluent in programming.
• Dashboards are very useful for the people scared at seeing code. In my case I want the output to be displayed in a separate window with dashboard items like sliders and buttons. In this way the non-programmer can play around with the data. How I would see this:
  • Single-Document Mode for Output View with tabs. Single-Document allows for the code to be hidden (already working), but to make it less cluttered, tabs would allow for mini-dashboards, instead of long-scrollable pages (which are annoying if you have elements that themselves are scrollable, like DataFrames)
  • Options on how to arrange the visual output. Maybe integration with Pyviz Panel?
  • Current issue: If Display() is called in two different cells, the output cannot be in the same Output View. This creates a unnatural workflow, in which all Display calls have to be grouped together at the end of a Notebook.

Implementation-wise I could imagine it be like one of these:

• Add options to Display() (similar to @rgbkrk 's suggestion) like name="foo" (creates a new Output View if no view with "foo" exists, or adds output to existing "foo" Output View), and group="spam"(allows for side tabs in the output view, like sidecar)
• Have Display() accept a View Description object and allow other libraries control how output should be displayed. E.g. Panel output. Somewhat more separation between backend and frontend.

I agree with @ellisonbg that backend and frontend should be separated as much as possible, but I would argue that Display() is already linked to frontend in terms that it generates instructions how content should be displayed.

---

Edit: This added functionality to Display could help other libraries, like Pyviz, to prevent bugs like this (output shown twice in Notebook, but not at all in Output View): holoviz/pyviz_comms#3

[Trezorro]

Adding to the suggestions for inspecting views of pandas dataframes in a movable side window, I'm very much thinking about the RStudio plotting workflow and how beneficial that would be for data exploration in Jupyter Lab.

How might such functionality of plotting to a separate side window be implemented best?
Should it be added as an extra option for the %matplotlib magic? Or should plt.plot() accept some parameters referring to a specific output window (or slide, or tab) to be populated, similar to the suggestions made by @NumesSanguis for Display(obj)?

How useful it would be to be able to compare plots by dragging them around next to each other, perhaps even interacting with them %matplotlib notebook style, or flicking through consecutive plot 'slides' RStudio style. Anything that cuts out all the scrolling while drafting notebooks would be an improvement in my opinion.

[psychemedia]

I have another use case for this, although I don't know if the backend ipywidgets plumbing will keep operating: the jp_proxy_widget extension provides an easy way to wrap a js application in an ipywidget wrapper. At the moment, only one instance of the widget can be opened (I think...). This means that whilst the widget can be displayed as a cell output, that cell output/widget can't be opened a second time.

It would be really useful to be able to open a jp_proxy_widget directly into a new JupyterLab output window.

[dsblank]

Just going to mention the ipylab project as it wasn't mentioned here before. Although, I, too, and looking for a better-integrated solution that builds on "Create new view for output".

[krassowski]

So I needed to quickly check results in a pandas DataFrame using interactive filtering but did not want to install a third-party plugin; here is what you can easily achieve with sidecar + ipywidgets:

Gist with code: https://gist.github.com/krassowski/159bb0c76ff47edb031710e2cff6862f

The code could be improved by rewriting the search to use regular expressions and to sanitize the cell content (html), but other than that it works fine for me. An important feature is the default limit on numer of columns and rows so that large datasets do not freeze the lab.

The only major issue is with sidecar layout preventing scrollbars from working. It was raised a few time over at the sidecar repository but it seems to receive little attention. It would really be great if someone with better understanding of the widgets system could have a look at jupyter-widgets/jupyterlab-sidecar#59 (and issues mentioned in there).