-
Notifications
You must be signed in to change notification settings - Fork 29.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI changes for profiling state in debuggers #94812
Comments
I like your mockups, feels to me like we are heading in the right direction. |
|
Looking into this and thinking how we could split up work. @connor4312 How about the following suggestion:
This milestone we can do the first point - to have a menu contribution point. And the description vscode API would be best to tackle in may, since there is no need to rush this in. @connor4312 we should create a api-proposal and assign it to May so there is time to present it in the API sync. Let me know what you think. fyi @jrieken for the menu contribution point menu name |
Yeah, the name-generation-engines says |
@jrieken awesome. Yeah we should use the "inline" group. Editing my comment from above. @connor4312 as the context when the contributed action is triggered on the session we would pass the session id to the extension. You can use the |
@connor4312 you asked for input on
From the DAP perspective the "stopped state names" are coming from the "description" attribute of DAP's "stopped" event. So in theory a debug adapter could just provide a formatted description that includes the "sub state". But this does not work for "Running (profiling)" because the string for the "Running" state is not received as part of a "Stopped" event but it is hardcoded in VS Code (@isidorn is this correct?) So a clean solution would be to make the client (VS Code) receive the "Running" state string via DAP. Some ideas:
|
@weinand Correct, "running" is hardcoded in the VS Code ui here
|
@isidorn how would you explain the semantics of the debug session's I think the only approach that makes sense is to get the "running" state description via DAP, because that's where the other descriptions are coming from. Having two sources for those strings is rather strange. So we could provide it with the initial capabilities but that would make it more difficult to change the string dynamically, e.g. from "Running" to "Running (profiling)" Or are you suggesting to show the "(profiling)" not as part of the session's state at all, but to move it to the name of the session? |
I like the idea of having the description be set purely in DAP. The displayed state is correlated and partially controlled by the debugger state already, and keeping it centralized in DAP is useful. The continued event is optional, but we could say either that the continued event must also be sent if the adapter wants to update the description, or introduce a description in the responses that apply continuation. One other slightly weird part is that it's possible to start profiling when we aren't paused, so would be emit an |
@connor4312 would it work for you if we decouple the "(Profiling)" from the state by appending it to the session name? That would solve the "weird part" you've mentioned above. |
BTW, I created a DAP feature request for addressing the issue with the hard-coded "Running" state. But please note that this feature would not automatically solve the issue of updating the "Running" state string at arbitrary times. |
Yea, appending |
We are now supporting contributing |
Yep, it's just work for me and the DAP issue that Andre opened. |
Okay, all of these are now done, pending possible DAP support for additional state descriptions. Thanks everyone 🙂 |
Per previous explorations, there are two changes we would like to make for profiling in VS Code. I've presented these as independent features, however we could also take the approach of supporting a generalized "profiling" state through DAP and drive the UI from that.
[ ] 1. The ability to contribute a hover action to targets in the call stack view.
This serves as a point of discovery for profiling. An additional contribution point like
debug/callstack/actions
would be the most straightforward approach for this.[ ] 2. The ability to set a custom sub-state for debug sessions
This could be a VS Code-specific API like how we can change the
DebugSession.name
today, which would feel natural to me. Alternatively, it could be a new method on DAP. @weinand interested to hear your thoughts, I will open a proposal on the DAP repo if we want to go that route.[x] 3. Disabling pausing the profile is running
For discussion: this is in the mockups and something I mentioned wanting before, but thinking on it further I would rather enable it and simply prompt the user when they click it with a modal like
With this implementation we would not need UI changes.
The text was updated successfully, but these errors were encountered: