Repository navigation
Debug: contribute a start view聽#164
Description
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
Activity
brettcannon commentedon Dec 24, 2019
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 commentedon Dec 27, 2019
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 Dan Taylor (@qubitron) was passionate about the debug flow for new users so I would be interested to hear his thoughts.
Thanks!
brettcannon commentedon Jan 2, 2020
Isidor Nikolic (@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 commentedon Jan 3, 2020
Brett Cannon (@brettcannon) haha ok :)
Let me know your thoughts.
luabud commentedon Jan 7, 2020
Just for reference: microsoft/vscode-python#2710
isidorn commentedon Jan 8, 2020
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 commentedon Jan 9, 2020
Isidor Nikolic (@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 commentedon Jan 10, 2020
Luciana Abud (@luabud) great feedback, let me try to answer those:
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 Andre Weinand (@weinand)
aslo Connor Peet (@connor4312) and roblourens for potential ideas on how we could improve the start view also for Node
connor4312 commentedon Jan 10, 2020
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 debuggingcommand, 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 commentedon Jan 10, 2020
Isidor Nikolic (@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 Connor Peet (@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 commentedon Jan 13, 2020
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.
Connor Peet (@connor4312) sounds good, let's continue the discussion in that call
Luciana Abud (@luabud) as for the activation problem I have created this issue with a suggestion how to fix microsoft/vscode-python#9557
karrtikr commentedon Dec 20, 2022
Originally posted by Karthik Nadig (@karthiknadig) in microsoft/vscode-python#9582 (comment)
We need to figure out what we want to show in this view.
Things to think about:
justMyCode, orpathMappingsetc. Feature settings likegevent, threading behavior, return values etc.