Debug: contribute a start view

[isidorn]

Hi 👋 VS Code dev here,

Last milestone we have introduced a Start View for debugging. More about this can be found here microsoft/vscode#84677

Using the context key debugUx which can have values simple or default any extension can contribute a view to the debug start experience.
Thus I am proposing that python considers contributing a view that can improve the start experience for new users not familar with python debugging. I am not a python expert but I suspect that there are quite some python specific actions which could be useful for new users.

If you think this is a good idea we can also work on fine tuning this start experience. We would also need to check for context keys of active editor to only show the view when the user has a python file opened.

For reference here's a picture how the debug start view looks now for python

fyi @qubitron @DonJayamanne

[brettcannon]

Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

[isidorn]

This feature will not get many upvotes, it is about making it easier for new users to start debugging. New users are not on GitHub.
As you suggested I think it would be great if you have a conversation about it. I also know that @qubitron was passionate about the debug flow for new users so I would be interested to hear his thoughts.
Thanks!

[brettcannon]

@isidorn sorry, the text is a template response to all new feature requests and I wasn't paying attention to who the request came from. 😄 We will take a serious look at it and Kai can also remind us at our monthly sync if you would like to us to try and integrate sooner rather than later.

[isidorn]

@brettcannon haha ok :)
Let me know your thoughts.

[luabud]

Just for reference: microsoft/vscode-python#2710

[isidorn]

We were discussing this and we could take another approach: that we make the inital start view contributable.
What I would be interested in is what Python would like to contribute to improve the start experience. If it is only commands, than I think it makes sense to show those commands in the start view (for example with additional blue buttons).
If it is much more then it makes more sense that Python contributes the whole view.

Let me know what you think and how you envision the python debug start experience.
Thanks!

[luabud]

@isidorn Oh I thought the "whole view" was the start view. If we were able to contribute to the whole view, would it be possible to e.g. when someone clicks "run and debug", that same view could change to ask users to select a configuration right there on the view, instead of showing the options in the middle of the screen like we do?

One common pain point when people use the debugger for the first time is setting up the right interpreter. A lot of people don't realize we display the interpreter selected on the status bar, and even those who do, don't realize you can just click on it to change the interpreter. I'm thinking it may be useful to add to the start view an information about which interpreter is selected, and then a button (or just a clickable text) to change interpreter in case that's not what they want.

Another common pain point (and this is usually more common for students, I believe) is how to run the code passing arguments. Maybe we can add something that would make this easier on that view as well, but then it's a bit tricky since this is one step further in configuring the debugger (i.e. you need you specify you want to debug a Python file before you can get to set up the args for it). I'm guessing this is when contributing to the whole view could be useful?

[isidorn]

@luabud great feedback, let me try to answer those:

1. Displaying options in the view is not something we usually do inside VS Code. I understand that using the quick pick to present the options in the middle of the screen might be strange at first, however we follow this pattern across vscode. For example clicking on the status bar to choose a language. Downside of using the quick pick is that it is usually visually far away, however I believe it gets the job done, especially once users get used to it. My point is: I would not change this at the moment
2. It makes sense to add information like that to the start view. For example if we allow extensions to contribute buttons, Python could contribute a button to the start view "Interperter NAME". Since it is a button user would more easily click on it than on the status bar. Clicking on the button the user would choose the interperter using the good old quick pick
3. The arguments passing: there are always two alternatives, build a UX for it or help users add arguments in the launch.json. This is a bit already covered by "To Further Configure ..." sentence. We can tune that sentence to add something like: "For example to add arguments". An alternative is that Python would add some python specific command. However I personally think that for arguments users should understand launch.json, and we should help them a bit here.

Let me know if this makes sense. And let me know if you are aware of other pain points users are hitting when setting up debugging. What we do depends also on what things we want to cover and we should not clutter the view at the end.

fyi @weinand
aslo @connor4312 and @roblourens for potential ideas on how we could improve the start view also for Node