Bugzilla – Full Text Bug Listing
| Summary: | [Launch] Auto-delete of configurations - dangerous interaction with File Refresh hooks | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Luke Usherwood <ldubox-coding101> |
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | daniel_megert, Michael_Rennie, pawel.1.piech, remy.suen, sarika.sinha |
| Version: | 4.2 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
Luke Usherwood
I agree it would ideal to prompt the user if we are going to delete them. I think something as simple a checkbox list of all the configurations that would be deleted and let the user select the ones (or none) that they want to delete. Reducing the severity and upping importance; the feature works for auto-deleting configurations, we just need to make it more user-friendly. Am I going insane, or did the option "Delete configurations when associated resource is deleted" (Run/Debug, Launching, Launch Configurations) get enabled after I upgraded to 3.7.1? Quite likely the former. (I was probably testing this ticket and forgot to disable it again.) Anyway, I lost all my launch configurations yet again, after a bad "svn switch" command using the command line. Great... At least I can recover the source files, but not the launch configurations. Mike, I assume this won't make it into M3? (In reply to comment #3) > Mike, I assume this won't make it into M3? You are correct, M3 is not going to happen. This is not going to make it into My either, moving to 4.3 P1 priority means we will not ship Juno without it. Since it is already targetted to 4.3/Kepler I will move to P2 priority. (In reply to comment #6) > P1 priority means we will not ship Juno without it. Well, strictly speaking, it means we will not ship the release/milestone indicated by the target milestone, and this is Kepler ;-). This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. Hi, sorry for not checking back earlier - Issue still present.
I've just confirmed that preference (2.) still executes immediately upon resource refresh, without prompting.
NEW INFO: this is despite the following option, found one level higher in the tree, being checked:
(3.) Run/Debug > Launching
[✓] "Prompt for confirmation when removing a configuration from the launch history"
Thus, even doing something like a git-bisect - whether done inside or outside of Eclipse (maybe I'm working on my C++ code in Visual Studio, for example) - can result in launch configuration files in Eclipse being silently zapped.
Having said that, having made (2.) default to OFF in Bug 233773 probably went a long way to mitigating this to only affect power-users and preference-tinkerers.
--------
IMHO I find that too many "knobs and dials" harms usability - and I could imagine both preferences (2.) and (3.) being eliminated. (YMMV)
2.) As suggested, a manual "cleanup" action that can be executed from the Launch dialog, to zap all configurations that are unused at that point in time, I think would be nicer than:
- a pop-up confirmation appearing out of nowhere
(say, during that external git bisect.)
- the current dangerous behaviour
3.) Yeah, no-one likes extra popup dialogs, but a preference buried in some obscure place is not a great solution either. The user can multi-select (ctrl+click) before hitting delete, so a one-time confirmation shouldn't be that much of a burden. Esp. since there's no Undo.
Thanks for confirming! Will analyze in 4.14. There should be a dialog before removing the launch configurations, even if the preference is set. If someone can take this up, will be available for review. Downgrading to normal as preference is switched off by default. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |