Skip to content
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

Function breakpoints - protocol allows condition but no UI to set condition #3646

Closed
rkeithhill opened this issue Mar 2, 2016 · 16 comments
Closed
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality insiders-released Patch has been released in VS Code Insiders on-release-notes Issue/pull request mentioned in release notes on-testplan
Milestone

Comments

@rkeithhill
Copy link

Maybe I'm missing something in the debug UI experience but I see no way to add a condition to a function breakpoint even though the debug protocol supports it.

@isidorn
Copy link
Contributor

isidorn commented Mar 2, 2016

You are correct, function breakpoints currently can not have a condition.
We will add this in the future to the UI

@isidorn isidorn added feature-request Request for new features or functionality debug Debug viewlet, configurations, breakpoints, adapter issues labels Mar 2, 2016
@isidorn isidorn added this to the Backlog milestone Mar 2, 2016
@rkeithhill
Copy link
Author

Thanks for the confirmation! Glad to hear it is a planned feature.

@weinand
Copy link
Contributor

weinand commented Nov 13, 2017

Ropened because function breakpoints do not appear in the gutter and provide no UI to add/edit their condition.

@isidorn isidorn added the *out-of-scope Posted issue is not in scope of VS Code label Sep 21, 2018
@vscodebot
Copy link

vscodebot bot commented Sep 21, 2018

This iteration we focus on issue grooming. This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

@davidanthoff
Copy link
Contributor

@weinand should this really be closed? The feature is supported in the DAP, it would be nice if it was also surfaced in the UI.

@weinand weinand removed the *out-of-scope Posted issue is not in scope of VS Code label Feb 12, 2020
@weinand weinand reopened this Feb 12, 2020
@weinand
Copy link
Contributor

weinand commented Feb 12, 2020

Yes, this is a valid feature request and we should address it because bringing VS Code's debugger UI on par with the Debug Adapter Protocol is actually on the VS Code roadmap.

@isidorn
Copy link
Contributor

isidorn commented Dec 10, 2020

Let's assign to this milestone for the inital investigation.

Ideas on how the UX would look like are welcome.
Here's how this looks for Exception Breakpoints #111227 (comment)

I would probably go with a similar approach for function breakpoints
fyi @connor4312

@yannickowow
Copy link
Contributor

Hi,
First of all, thanks for adding this to January goal !
I saw how you handled conditions for breakpoint filters.
Since FunctionBreakpoint has as hitCount attribute as well, I see two possibilities:

  • it can be shown the same way as ExceptionBreakpoint with a Edit Hit Count and Edit Condition actions.
  • it can be shown as a drop-down menu the same way as SourceBreakpoint

Thanks

@isidorn
Copy link
Contributor

isidorn commented Dec 14, 2020

@YannickMeeus thanks for jumping in and for sharing ideas.
If we do it inline like we did for Exception Breakpoint than indeed we need two actions as you proposed. Since there is not enough vertical space for a rich widget that could have a drop-down.
If we do a rich breakpoint widget than the question is where to show it, in what editor/

@yannickowow
Copy link
Contributor

yannickowow commented Dec 14, 2020

Yes, you are right about vertical space, I missed that point.
Maybe instead of showing full name for Condition and Hit Count we can display products icons such as symbol-key and symbol-numeric (or new/customized ones) to reduce vertical constraints.
If you click on this logo it will display a drop-down with logo + full text and this text will be reduced after selection.
You will then have a unique Edit Function Breakpoint action which will display this edit menu.

@isidorn
Copy link
Contributor

isidorn commented Jan 13, 2021

Here's an idea:

  • We add a Context Menu action to the Function Breakpoint: "Edit Condition...". We also add an inline edit action (like propossed here Inline action for "edit condition" action in Breakpoints view #113805)
  • When this action is executed we simply open the editor breakpoint widget in the Active editor and pass focus to the widget. We open the widget on cursor location. Even though the Function breakpoint is not tied to the active editor this will give us the most space, and a same experience as for regular breakpoints.
  • Rare corner case where there is no editor open: this action is disabled

I believe that in practice this will work nicely.

@weinand @connor4312 @yannickowow let me know what you think? I can also present this in the UX meeting today.

@weinand
Copy link
Contributor

weinand commented Jan 13, 2021

@isidorn editing an object (here a function breakpoint) in a random unrelated editor is a kludge.

I see two options:

  • we use the same UI as done for the exception breakpoints
  • we open the editor breakpoint widget in the breakpoints view

@isidorn
Copy link
Contributor

isidorn commented Jan 13, 2021

@weinand thanks for feedback. Editor breakpoint widget can not be rendered in the breakpoints view, it requires an editor the way it is implemented.

So let's go with option 1 and use the same UI as done for exception breakpoints, and have two context menu options as @yannickowow proposed Edit Hit Count and Edit Condition

@isidorn
Copy link
Contributor

isidorn commented Jan 14, 2021

I have pushed a first version of this. Please try it out with VS Code insiders from tomorrow.

A UI corner case is when a Function Breakpoint has both a Hit Count and a Condition. I try to render both, and am happy with the final result (can be seen in the gif).

What is not shown in this demo: the Edit Condition inline action and the context menu action gets disabled if the Exception Breakpoint does not support conditions, or if there is a debug adapter connected which states in it capabilities that it does not support conditions.

recording

@yannickowow
Copy link
Contributor

yannickowow commented Jan 14, 2021

It looks good and intuitive to me ! Thanks a lot ! I'll try this when available

@isidorn
Copy link
Contributor

isidorn commented Jan 14, 2021

Great, looking forward to feedback.

lszomoru pushed a commit that referenced this issue Jan 15, 2021
…unction breakpoints. Allow to edit conditions for function breakpoints

fixes #113805
fixes #3646
@isidorn isidorn added the on-release-notes Issue/pull request mentioned in release notes label Jan 29, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Feb 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality insiders-released Patch has been released in VS Code Insiders on-release-notes Issue/pull request mentioned in release notes on-testplan
Projects
None yet
Development

No branches or pull requests

6 participants
@davidanthoff @weinand @isidorn @rkeithhill @yannickowow and others