Breakpoint should probably disappear when debugger disabled #3093

Closed
shiffman opened this Issue Feb 5, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@shiffman
Member

shiffman commented Feb 5, 2015

When the debugger is enabled you can add and remove breakpoints. Once you disable the debugger, however, the breakpoints still appear in the IDE. Because you can no longer add or remove or use these breakpoints I think they should not visually remain in the IDE unless you re-enable the debugger.

@Akarshit

This comment has been minimized.

Show comment
Hide comment
@Akarshit

Akarshit Feb 5, 2015

Member

Even in other IDEs the breakpoints are visible even after debugging has been stopped . It's just that their is an easier way to remove them , and in Processing IDE to remove them one has to enable the debugger and remove them.

Member

Akarshit commented Feb 5, 2015

Even in other IDEs the breakpoints are visible even after debugging has been stopped . It's just that their is an easier way to remove them , and in Processing IDE to remove them one has to enable the debugger and remove them.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Feb 6, 2015

Member

Some notes on the desired behavior:

  • being on a line in the text editor and clicking “toggle breakpoint” (or hitting ctrl-b) will add a breakpoint (currently implemented)
  • double-clicking in the margin where breakpoints show up will add/remove a breakpoint
Member

shiffman commented Feb 6, 2015

Some notes on the desired behavior:

  • being on a line in the text editor and clicking “toggle breakpoint” (or hitting ctrl-b) will add a breakpoint (currently implemented)
  • double-clicking in the margin where breakpoints show up will add/remove a breakpoint
@Akarshit

This comment has been minimized.

Show comment
Hide comment
@Akarshit

Akarshit Feb 7, 2015

Member

Is turning their visibilty off while the debugger is disabled is still the desired behavior

Member

Akarshit commented Feb 7, 2015

Is turning their visibilty off while the debugger is disabled is still the desired behavior

@Akarshit

This comment has been minimized.

Show comment
Hide comment
@Akarshit

Akarshit Feb 7, 2015

Member

The double-click is implemented but its not working because the public void mousePressed(MouseEvent me) in JavaTextArea is getting called twice. So it sets the breakpoint and then removes it.

Member

Akarshit commented Feb 7, 2015

The double-click is implemented but its not working because the public void mousePressed(MouseEvent me) in JavaTextArea is getting called twice. So it sets the breakpoint and then removes it.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman May 20, 2015

Member

Now that clicking the line numbers works to add a breakpoint I'm coming back here to revisit this issue. While I understand this is not the convention, it feels to me that the breakpoints should not be visible when the debugger is disabled as they no longer play a role. . this is also a further indication to the user regarding the enable/disable status of the debugger which I find useful.

I also feel that you should not able to add and remove breakpoints when the debugger is disabled (currently in 3.0a9 you can). I think this will cause problems if a first-time user starts clicking on line numbers well before they are ready for the debugger and wonders what's going on.

I would also personally like to see lines with breakpoints highlighted a bit more strongly (the <> feels quite subtle to me) but this is a more minor point and I defer to the wisdom of others with better design instincts.

Member

shiffman commented May 20, 2015

Now that clicking the line numbers works to add a breakpoint I'm coming back here to revisit this issue. While I understand this is not the convention, it feels to me that the breakpoints should not be visible when the debugger is disabled as they no longer play a role. . this is also a further indication to the user regarding the enable/disable status of the debugger which I find useful.

I also feel that you should not able to add and remove breakpoints when the debugger is disabled (currently in 3.0a9 you can). I think this will cause problems if a first-time user starts clicking on line numbers well before they are ready for the debugger and wonders what's going on.

I would also personally like to see lines with breakpoints highlighted a bit more strongly (the <> feels quite subtle to me) but this is a more minor point and I defer to the wisdom of others with better design instincts.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 20, 2015

Member

@shiffman that's three reports in one, ahem.

Agree on all points and can take care of it for the next release.

Member

benfry commented May 20, 2015

@shiffman that's three reports in one, ahem.

Agree on all points and can take care of it for the next release.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman May 20, 2015

Member

Heh, I'll break them out! This one will be for the seeing the breakpoints when debugger is disabled. Also, will add a debugger label.

Member

shiffman commented May 20, 2015

Heh, I'll break them out! This one will be for the seeing the breakpoints when debugger is disabled. Also, will add a debugger label.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 20, 2015

Member

Nifty, thanks. If anything, it's easier to have them too atomic and mark something as a duplicate rather than trying to keep track of multiple things.

Member

benfry commented May 20, 2015

Nifty, thanks. If anything, it's easier to have them too atomic and mark something as a duplicate rather than trying to keep track of multiple things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment