| Summary: | DCR - suggestion to improve running vs. debugging | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Steve Northover <snorthov> |
| Component: | Debug | Assignee: | Darin Wright <darin.eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cocoakevin, erich_gamma |
| Version: | 2.0 | ||
| Target Milestone: | 3.0 M8 | ||
| Hardware: | Other | ||
| OS: | other | ||
| Whiteboard: | |||
|
Description
Steve Northover
We have looked into this. The problem is that users almost always have a breakpoint set in the workspace from the last debugging session. Breakpoints are "global" in the sense that we can't know which breakpoints are effective for a particular run. This means the user will almost run under the debugger. Since it is slower than normal running I'm concerned about even providing this as an option. Moving to Debug for further comments So make it an option that people can turn off. You could also get rid of both buttons, only have one and prompt - "You have enabled break points, do you want to debug?". Again, all of this should be optional. Coming from VA/Java to LF and Eclipse, this particular thing still burns me, even after all this time. Given that things are less interactive in the JDK (no hot code replace) it often takes a long time to get to the state you care about and it drives you nuts to find out later that you were running. Can we also optimize debug so it matters less? Given that we are running in an IDE, if debug took the same time as run, I think we'd always want to debug. Another possilbe solution would be to allow actions from action sets to be added selectively (i.e. select actions within actions sets). Users who do not want the run button could throw it away. I don't want to get rid of the run button, I just want the right thing to happen. I don't buy EG's argument. Yes users will "run the debugger" when they have a break point set but they will get a prompt "Did you mean to debug? I see you have breakpoints set ...". The dialog can have a "never ask me again" option and the whole thing could be configured so that users can have the old behavior back again. When I entered this PR, I was used to V/A Java. These days I care less but it's still annoying. Think about it, when do you ever set a break point and then mean to run a program instead of debug? It's one of the small things that we could do that would make sense and make the IDE better. The real problem is that you "run" and then find out lots later that you meant to "debug" because there is no strong visual cue that this is what you just did. I actually do quite often have breakpoints set, and use "run" mode. I often leave breakpoints lying around to re-use on future debug sessions. I dialog would not kill me, but at this point, it would be a surprise to many users (so perhaps a better default would be to have the dialog turned off, and let those who want it, turn it on). I think the key observation is that this is a problem for people who are (recently) switching from VAJ - however, once you are used to the idea, it's not that difficult. (Note that VAME has two buttons as well). Agree that VAME users have less of a problem. I still think that this is a fundamental problem in our product and that we should do something about it so for me, the issue is not RESOLVED. I also care less these days about it. I still think this is wrong and do it all the time. So does everyone on my team. However, I don't actually expect you to fix it. Re-opening to close. We do not intend to change the current implementation/behavior. We are actually adding providing support for an extensible set of launch modes (for example, "profile"). Marking as "won't fix". Interesting. As long as the solution solves the problem that 99% of the time when I set a breakpoint I mean to debug despite the fact that I pressed run. If this problem isn't solved by "launch modes", then you really aren't solving my problem at all, just closing the PR and saying WONTFIX (condeming me and others like me to the endless torment of run vs. debug). Not sure why adding a dialog "Did you mean to debug?" with the check option "Never ask me again" is such a bad idea? I am simply trying to torment you :-) Launch modes does not address your issue. It means that we are adding another launch button - which makes your problem worse. The bug is marked as "won't fix" since we have no intention of adding prompters when you press one of the launch buttons. It seems to me there are too many questions: * (no breakpoints, press debug or profile) "Did you really mean to run?" * (breakpoints, press run or profile) "Did you really mean to debug?" * (none or some breakpoints) "Or perhaps you meant to profile your application?" Thus far, we have seen no complaints (outside of this bug report) that this is a serious usability issue (Votes = 0). The answers to these questions are obvious:
* (no breakpoints, press debug or profile) "Did you really mean to run?"
* (breakpoints, press run or profile) "Did you really mean to debug?"
* (none or some breakpoints) "Or perhaps you meant to profile your
application?"
(no breakpoints, press debug or profile) -> do it
(breakpoints, press run or profile) -> prompt
(non or some breakpoints) -> do it
The only case where you get caught is when you set a breakpoint and press run,
get 60,000 miles into the problem, setting the initial state, answering all
the right questions only to find out that you are running!
It's an old complaint and easy to fix and also easy enough to get rid of for
those that don't like it ("never prompt me"). Do you think it's worth my time
trying to drum up support from the community?
Too bad, yet again about this one. I notice we now have a dialog that says something like "Workspace is building, do you want me to wait?". Do you realize how much time this one simple change would save Eclipse users? NOTE: I saw Erich make exactly the same mistake during his demo at EclipseCon. Why is this so hard to change given that we are already prompting when the workspace is building? This one simple feature would save the Eclipse community hours of wasted time. patches submitted for this bug along with bug #45887 and bug #54925. (patches attached to #45887). Darin, please verify This isn't actually getting fixed, is it? Yes! Yes! Yes! Applied patch. I think we should promte this to function in the debug platform, rather than making it Java specific. Please move prompt & preference to the debug platfrom. This is now fixed. Support exist in the debug platform, but launchers have to subclass our abstract launch delegate to inherit the feature. Currently, Local Java Apps, Applets, and JUnit launch config types have the behavior. Logging a bug against PDE to subclass our new launch delegate. Verified. If the breakpoints are not active, the dialog shouldn't be launched. The dialog should allow you to cancel the operation (running nothing) so you can go and clear the breakpoints. Also, it needs to have the standard check box "don't ask me again" button that other dialogs of this type have. reopening for consideration of comment 21 and comment 22 There are a bunch of places where this new kind of dialog has appeared. It needs to have the "Eclipse standard" look for dialogs of this type or it will piss too many people off. I agree. Reported new Bug# 57272 to handle the problem with the dialog. Only show dialog if the BreakpointManager is enabled and there is at least one enabled breakpoint in the workspace. fix in LaunchConfigurationDelegate and LaunchConfigurationMessages.properties Darin, please verify Verified. Does it make sense to add an option to disable break points from within the dialog? That way you can run right away and keep the warning dialog active for the future without having to exit, disable or remove break points. Otherwise its tempting to say "never show me again" (or whatever) rather than going and removing break points. The issue here is that you are hot to see your code run and quitting, fixing the break points state and running again is a pain. |