Debug view per debug session

[thegecko]

Apologies if this has already been raised, a search of the issues didn't uncover an existing request.

In more advanced debugging scenarios (e.g. multicore debug on embedded devices) it's common to have multiple debug sessions running either through a compound configuration or by starting them individually.

The current concept in VS Code is to only have one of these sessions "active" and the active session can be changed through:

• The debug toolbar dropdown
• The stack view
• The debug console view

When changed, all views are updated to show details relating to the active session (e.g. the controls above are updated and the variables view is switched to the active session).

When debugging multiple targets, the developer often needs to be able to compare data in these windows between the sessions and this isn't currently possible with the built-in views (e.g. variables).

For custom debug views, we can get round this limitation by managing multiple window instances, however it would be great if a UX pattern for this could be implemented by VS Code for the built-in views.

My proposal would be to show the views as-is when a single debug session is running, but as soon as multiple sessions are available, a dropdown appears on the views to allow:

• Pinning to a specific debug session
• Opening a new version of the window alongside the existing one

This would allow the user to manage multiple debug windows targeting each debug session and compare data between them or observe changes across all debug sessions in tandem.

It's becoming more common for existing IDEs to be migrated to VS Code and functionality to be recreated. I'm involved with multiple teams doing this and the advanced debug needs (such as this) are becoming a blocker to this migration.

If this proposal makes sense, I'm happy to carve out time to create an initial PR.

cc @roblourens @connor4312

[connor4312]

Related: https://github.com/microsoft/vscode/issues/201772

I like the idea of having a "pop out" aux debug view that is static with debug information (debug views, toolbar, and repl) tied to a single debug session. I could see that being a very nice experience when dealing with concurrent debug sessions.

I'm not sure I'm a fan of having multiple debug views in the main window, or switching to a dropdown within the existing view. I can't imagine a dropdown being a better experience to select the active debug session than the existing Call Stack view which functions as a 'switcher'.

[roblourens]

I'm trying to understand if we're talking about "windows" or "view containers"? I kind of like the window option but we can't have views in aux windows afaik

[thegecko]

I like the idea of having a "pop out" aux debug view that is static with debug information (debug views, toolbar, and repl) tied to a single debug session. I could see that being a very nice experience when dealing with concurrent debug sessions.

Regarding user experience, do you see this as being similar to running another VS Code instance?

I'm not sure I'm a fan of having multiple debug views in the main window, or switching to a dropdown within the existing view.

This is a common idiom for approaching this problem. For example, here are screenshots of Arm Development Studio debugging multiple cores:

Creating a new stack:

Selecting/updating the core its tied to:

However this may not be possible in VS Code as the debug views all need tying to a stack view.

I can't imagine a dropdown being a better experience to select the active debug session than the existing Call Stack view which functions as a 'switcher'.

As the Call Stack is a central control point and context reference, perhaps this is the main view we need to consider duplicating. However we would need to make it clear to the user which other views would relate to each Call Stack. This led me to the individual view pinning idea. Another approach is as you say to "pop out" the whole debug UX into a new window.

Alternatively, the Call Stack could become the container for all debug views (built in or contributed) and a view container is created per session? e.g.:

I'm trying to understand if we're talking about "windows" or "view containers"? I kind of like the window option but we can't have views in aux windows afaik

I'm keen we don't get blocked on limitations such as this, however this use case could be a good catalyst for supporting external windows containing views.

I don't want to make this more complex, but this need would also be beneficial for the disassembly view (which seems to be tied to a source file at the moment?!). I plan to create a separate issue dedicated to disassembly, so can link that here later.