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

[connor4312]

Kai and I were discussing this in our 1:1 yesterday. I think we have similar needs for js-debug in contributing to the view. A facet of js-debug different from the previous (javascript) debugger is a move away from requiring launch configs for the majority of users; we can debug any npm script without any extra config, and most users probably will never need extra config if they enter through that path. So our approach is that we want to explore how we can make the debugging entrypoints, such as the start view and select and start debugging command, a comfortable permanent home for these users. I set up a call with Andre, Rob, Kai, you, and myself next week to start thinking around this.

[luabud]

@isidorn thank you! That makes perfect sense and I agree with everything you said there. You made a very good point, we'll need to be mindful not to clutter the view. I think for now the Python interpreter would be a good help. We're also conducting some user research around debugging on the next couple of weeks, so it'll be interesting to see if more interesting ideas will come up.

I also like the idea @connor4312 gave around not needing extra configuration. What we have considered before is to identify when users are trying to debug a Flask or Django application, and then pre-select or at least put these configuration options higher on the list (microsoft/vscode-python#1179).

Another problem I can think of (but it's not directly related to the debug view) is that the Python extension needs to be activated for it to appear as a debugger configuration option. I remember seeing an online course where people were posting comments about how confused they were because the Python option didn't appear for them when they were configuring the debugger in VS Code, and it did for the instructor in the video (who probably had the extension activated before recording that class).

[isidorn]

Ok great. So it seems like adding additional commands / buttons in the start view is the way to go here. I will also initiate discussion with some other debug extension authors to get their feedback. In this milestone we want to identify what solution would be benefitial for most extensions, and next milestone we will probably do it.

@connor4312 sounds good, let's continue the discussion in that call
@luabud as for the activation problem I have created this issue with a suggestion how to fix microsoft/vscode-python#9557

[karrtikr]

Originally posted by @karthiknadig in microsoft/vscode-python#9582 (comment)

We need to figure out what we want to show in this view.

Things to think about:

1. Should we add a button for current file. Should the button have the name of the file it will run (like Debug 'myscript.py').
2. Should debugger feature be globally enabled via this UI. like justMyCode, or pathMappings etc. Feature settings like gevent, threading behavior, return values etc.