[WIP]: Move Debug Actions Widget to the Debug Viewlet

[mikeseese]

This PR is one of two solutions that I propose in which fixes #2513. The other PR is #49097.

At the time of writing, this PR was created before the work was implemented to open discussion about the design for this. While #49097 is a simple fix to mitigate #2513, I believe it is ugly from a UX perspective, and the debug actions widget needs to be moved to a more permanent place.

Many solutions have been proposed in #2513.

• Move to the navigation bar
  • I believe this solution is somewhat odd in terms of expected placement
  • Further, the process selection drop down would need to be a button which then pops up a drop down for selection. I think this would just look funky and not get approved by VS Code maintainers
• Pin it to the title bar (left or right side) and the scrollable region for title tabs will be less
  • While this seemed promising at first, this solution breaks down when you do split windows. Each window gets its own tabs and title action, and it would be non-intuitive as to which window the widget was placed. Further, with 3 split windows and the side panel open, there could be very little space for a debug actions widget without making the file names inexistent/small
• Move it to the debug viewlet
  • This would put the debug actions viewlet below the header and above the views container (see the below picture). I feel this is the strongest place to put the debug action widget as it's exactly where you'd expect to find it. Users don't need to see the widget all the time if they use shortcuts, but it would be available in the first place they'd look.

Unfortunately, putting this in a viewlet does bring up a couple of questions: is it a view like variables/call stack/watch/breakpoints? If so, does it still have a header, is collapsible, and could be reordered? I think that this should always be at the top or bottom of the viewlet. I think it's redundant to show a header, and I think it should always show in the viewlet.

This means it should be a static div outside of the split-view-container. We could make a "hack" and just get the element in the debugActionsWidget.ts file and append a div in the right spot. However, I could see that we would want to standardize this a little for posterity's sake. This would pose that a viewlet should be able to have a sub-header or something along those lines to display content. Should you only be able to have one div or maybe an array? Should you be able to add div(s) to both above and below the split-view-container.

A lot of questions to answer. I'm totally fine with doing the "hack", and I'm fine with figuring out a forward-thinking solution. However, I think we should solve this one way or another in a timely fashion, even if it means implementing a less-than-perfect solution.

Tagging @isidorn on this for discussion

[isidorn]

Thanks for your PR and ideas.
I will present this to the team in our UX meetings and we will choose a solution. If time allows I will work on this in May.
Currently I am leaning towards some status bar popup solution, similar to how once you click on the smile in the bottom right corner you get a widget poping out. But this is still in early stages. Once we settle on something I will let you know.

Thanks again

[mikeseese]

Alright, thanks. I'm fine with working this as it seems that you just don't have the time for this issue (no offense at all); I really just need direction and approval. I can go ahead and implement my suggestions here, but I don't want to do the work if it's going to be denied on a UX principle.

I personally think clicking something on the status bar is not intuitive. I don't believe new users (remember that many users will have never used an ide/debugger) will think to look there. I know I wouldn't.

I really think the solution must be a permanent, non-floating box.

With that said, please understand my skeptism about the ux meetings since you said something very similar to me a year ago and nothing (that the community knew) came out of it. I stress a solution is better than the prolonged ideal solution at this point.

Thanks!

[fabiospampinato]

My 2 cents:

• Hiding the actions inside a popover triggered from the statusbar requires the user to click the statusbar item first, and adds another useless (at least to me) statusbar item.

• Putting the debugger actions in the debug pane/viewlet feels like the obvious solution to me and many people seemed to like this proposal:

• I would like to have an API for opening a custom popover from a statusbar item, many extensions could use it, and if somebody really wanted the debugger actions inside such popover an extension could be made for it.

[endquote]

I work on projects where I'm debugging multiple processes at once, I hope that scenario is considered in any redesign.

I find the current behavior of having a dropdown to switch between running processes to be cumbersome, especially since the items in the list change as processes come and go. I'd prefer to have a totally separate debug bar for each process.

I like @fabiospampinato's approach as a first step, with a future step being a stack of debug bars whenever there are multiple processes.

The argument against this is that it would get out of control if you're debugging a whole ton of processes (10? 100?), but I've only ever had under 10.

[fabiospampinato]

@endquote as soon as they decide to expose the necessary debug state (#30810 10 months old issue 😩) and if they add an API for switching debug session an extension could fix your problem by providing a quickpick for quickly switching session, IMHO this should be implemented in core though, using the select is not very ergonomic.

Said extension (or VSC itself) could also provide commands for switching to specific sessions, such that you could bind ctrl+alt+1 for switching to the first session, ctrl+alt+2 for the second and so on.

[mikeseese]

I think the goal here is to close #2513. I don't want to start proposing features and changes with the way the widget actually works or adding backend features when all we need to do in this PR is move the widget.

I think the multi process scenario should be talked about in the UX meetings, but I don't see any reason for this PR to change the current behavior.

[isidorn]

Thanks for the PR we landed on a different solution which I covered here #2513
Thus closing this