Explore built-in "variable explorer" notebook functionality

[roblourens]

The Jupyter extension has a variable explorer as a webview in a panel. This should be moved into vscode core as part of common workbench UI. Things to explore:

• The Jupyter extension creates a "fake" debug session to show variables in the debug UI
• Show variables inline in the cell editor, similar to debug inline values. Possibly even without a separate variables view
• Show variables on hover, same as debugging
• Show a separate tree/table view, similar to current experience
  • Odd duplication with debug variables view. Could be that you just have the same data visible in two places. Maybe the debug variables view hides when debugging a notebook.
• Show variables in the Debug viewlet, driven by new variable provider API when not debugging. This would be a new type of "debug session" for inspecting variables only, is managed by vscode, can't be terminated by the user, somehow gets upgraded to a real debug session when the notebook is debugged

[roblourens]

Request for showing the same data that the variables viewer shows in extra columns, but in normal debugging: #146748

[roblourens]

Some notes from conversation with @DonJayamanne

• I think we both agree that a tree is a better way to view variable data than a table with non-expandable rows
• Enable extensions to contribute actions to open different viewers on variable rows
• How important is it to show the size and type at the top level, like currently?
  • Seems that it would be ok to show those attributes on hover
  • But in a tree view, we could still show them up front and include them next to the value
• A tree would lose the ability to sort variables by name/size/type/value, but this doesn't seem important
• Can we get away with only showing variables using inline values/hover?
  • Many users do not use a variable explorer, and inspect variables by running code
  • On the other hand, they may be used to seeing a list of variables, and just want to see their familiar list
  • We have had a list of variables in vscode for quite awhile, could be an adjustment to remove it
  • And users may want to look at the value of a variable while not next to code that uses that variable. esp in long cells

[roblourens]

Hi @davidanthoff @jonsequitur @claudiaregio, I wanted to call this out to you that we have started to investigate how to add a built-in variable explorer with API that notebook extensions can drive. For Jupyter, this would replace the variables viewer that we currently have. I've written some thoughts on the UI experience at the top of this issue, and #166296 covers API.

Is this something that you would be interested in using? If so, what would you like to see in it?

[jonsequitur]

We'd definitely be interested in using it for Polyglot Notebooks.

One of most important distinctions we have is the need to say which subkernel a variable is located in:

Enable extensions to contribute actions to open different viewers on variable rows

Notice in the screenshot that we have an action button for sharing variables with other kernels. This doesn't open a viewer. It adds a cell with generated code:

I think we both agree that a tree is a better way to view variable data than a table with non-expandable rows

Agreed. For this reason, we're working on making our inline object displays into expandable trees similar to what we do for JSON:

[jonsequitur]

I don't see it mentioned here but when would the variables in this view be refreshed? Our current implementation is a bit chattier than necessary and we're thinking through how to improve that.

[roblourens]

One of most important distinctions we have is the need to say which subkernel a variable is located in:

Is it important that this data be immediately visible for every variable? What if you could see this info by hovering, or expanding the variable value?

we have an action button for sharing variables with other kernels

I'm imagining that extensions will be able to contribute arbitrary commands, the same way other menu contributions work.

when would the variables in this view be refreshed

That will likely be up to the extension

[jonsequitur]

One of most important distinctions we have is the need to say which subkernel a variable is located in:

Is it important that this data be immediately visible for every variable? What if you could see this info by hovering, or expanding the variable value?

Yes, I think this is critical to help people understand polyglot workflows and variable sharing.

[roblourens]

I'm imagining that as a shortcut, maybe the extension could return the kernel name as part of the variable name. e.g., it returns "name": "varname [pwsh]", do you think that would suffice? Does your table support sorting by kernel, and is that important?

Can you also tell me about the behavior of the filter box?

[jonsequitur]

The column header helps people understand what's in the column, so concatenating them would be less intuitive.

Another thing that would be very useful is a type name column. Our inline output always renders types with a link to documentation, and having that facility would be very helpful here as well.

Given these two considerations, the ability to add custom columns seems like it would let us bring our own specific scenarios as appropriate.

Sorting by kernel would be helpful. We don't currently support sorting.

The filter box currently filters across the string values in all columns, so you can use it to filter by kernel name or variable name or values.

[davidanthoff]

Is this something that you would be interested in using? If so, what would you like to see in it?

YES! We currently have a full variable viewer/inspector in the Julia extension, but I'd love to get rid of our custom implementation and reuse something that ships as part of VS Code itself.

Maybe I can provide a quick overview of how we do this right now in the Julia extension, and what features would be important for us to replace our custom implementation with something in the core product.

This is how things look at the moment:

Couple of random observations:

• We use a tree :) For a while we didn't have a tree, and the feedback from users was sooo overwhelming that they wanted a tree that I'd say this is a must for us. I'm showing a couple of named tuples here for example, but in a typical Julia program things can nest deeply with nested structures.
• The top level in our tree shows running Julia processes of three kinds: a) Julia REPLs that run in a terminal (marked as 1), b) notebook kernels (marked as 2), and c) test processes (marked as 3). It is very common for a Julia user to have lots and lots of different Julia processes that are launched from VS Code running at the same time.
• The workspace view also provides controls to restart and kill these Julia processes. An example is marked as 4 in the screenshot, but the same button also shows up for REPLs and test processes if one hovers there. Having these controls as part of the workspace has worked well for us.
• What is marked as 5 in the screenshot is the typical view of variables that have structure. A few points: a) we use icons to differentiate data types, b) for structured types we show the precise type as the value, c) for basic types we show the value.
• We have richer viewers for some types, particularly anything tabular and plots. For such types we show a button (marked as 6) that then opens a tabular viewer for that data, or shows a plot that is assigned to a variable in the plot viewer that we ship.
• We also show all the modules per process (marked as 7). One can toggle whether those should be shown or not in the UI. This is super powerful because it allows a user to drill into every single data structure that is currently loaded in the Julia process, in the core of Julia or any loaded package.

So that is where we are with Julia at the moment.

Some reactions to questions that came up above:

How important is it to show the size and type at the top level, like currently?

We haven't gotten any request for that from our users so far. I think having that info in a tooltip would be nice. The reason we don't have it right now is that the tree view doesn't really support columns, but of course the main VS has a tree/column type UI element, if that could be used I'd say that would be a win.

A tree would lose the ability to sort variables by name/size/type/value, but this doesn't seem important

Completely agreed, I think sorting is not important.

Can we get away with only showing variables using inline values/hover?

I think not :) I'd say if we had inline tree views in addition to something that is similar to the current Julia workspace it would be great (Juno, the Atom based Julia extension had expandable, inline tree views), but in my mind this couldn't replace a separate pane like we have right now.

Some other random thoughts:

• I never liked the distinction between the debug view and our Julia workspace, it seems weird. In particular because one can intermediately swap our REPL into a debug mode, swap back into non-debug mode again etc without restarts and having these two distinct UI elements that show essentially the same thing seems weird. If there is a way that these could be combined, I think it would be fantastic. Very roughly, it seems to me that whenever a debugger is running, there is "more" info that can be shown in terms of program state, so somehow, I would imagine that a UI could be that when not in debug mode it shows something like the Julia workspace, and then whenever a process is being debugged, "more" info is shown in the same view. But how that would look in detail, I have no idea, that would probably require a fair bit of design work.
• For us having the same variable viewer for the REPL and notebooks is really crucial, i.e. I don't think a solution that would be for notebook kernels only would work well for us.
• At the moment the test processes (marked as 3) use this UI only for process control (restart and kill), but I have plans to also expose variables from test processes down the road in the same UI.

Also pinging @pfitzseb for his thoughts.

[flying-sheep]

Is there a plan to have a UX professional take a look at the debugger interface?

I like how a lot of part of VS Code handle, but I have several usability issues whenever using the debugger. I think it needs a major overhaul. I added some reasons below as reminder to myself once I know where to go with that list.

Reasons

• the floaty debug control toolbar is a horrible idea, and by design always in the way. Maybe on a large screen you can find a place where it’s practically out of the way, but why not remove any reason for that grabby handle to exist instead?
• in the variable panel, having the string representation of a variable next to the variable and cut off by default (only really accessible via hover) isn’t great. There should be a way to expand the string representation (and e.g. copy it) instead of only having it accessible as a hover tooltip
• having the variable list in the sidebar makes it part of a panel that I always want to keep narrow, except when debugging, where I need it to be wide to see aforementioned string representations. Why not have the whole debugger UI in the bottom panel area where we can actually see things?
• There should be a way to customize how objects expand and display: A MappingProxy object should expand as a mapping (key-value), some objects should be displayable as matrices/dataframes, …

[gjsjohnmurray]

@flying-sheep, I hope you are aware of the other options for where the debug toolbar appears (debug.toolBarLocation), including the new one that landed in 1.83.

Re your third point I suggest you try the current 1.84 Insider, as you can now drag the "Run and Debug" icon off the Activity Bar and drop it onto the Panel.

An example layout (docked toolbar, justified panel):

[flying-sheep]

Oh wow, thank you! I wasn’t aware, and I’m trying to follow the release announcements closely.

With the two changes you mentioned, my debug experience should shift from “frustrating” to “nice”.

If it gets the the variable viewer from this issue that I so inconsiderably hijacked, and a few small changes, there’s potential for greatness.

[wrgrant]

For anyone interested, there is a preview version of this available!
See post from @amunger in microsoft/vscode-jupyter#1148