Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 264106 - [target] Provide careful handling when the "Remove" button is pressed
Summary: [target] Provide careful handling when the "Remove" button is pressed
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M7   Edit
Assignee: Ankur Sharma CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-08 17:13 EST by Simon Archer CLA
Modified: 2009-04-14 17:38 EDT (History)
3 users (show)

See Also:


Attachments
Patch (9.26 KB, patch)
2009-04-14 16:48 EDT, Ankur Sharma CLA
curtis.windatt.public: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Archer CLA 2009-02-08 17:13:09 EST
Using Eclipse 3.5 M5.

The "Target Platform (experimental)" preference page gathers all the targets that exist in the .metadata and the workspace. Unfortunately, the UI does not always show where the targets reside, and clicking the "Remove" button physically deletes the files, rather than just removing it from the list of managed targets.  The downside of this is that a file from the workspace can be lost without the user realizing it.

Some suggestions:

1. Show in the UI where the target file resides:

   - For those that reside in the .metadata you could just say something like
     "Private" or "Internal", or some such word.

   - For those that reside in the workspace, the workspace's relative path would
     suffice.

   - And if/when in the future targets can reside in the local file system, but
     outside of the workspace, the absolute path should be shown.

2. Creating a target is not necessarily trivial, so please consider adding a
   confirmation dialog to the "Remove" behavior.

   - This will help prevent accidental deletion, somewhat.

   - To delete a target that resides in either the workspace or the local
     file system the dialog should contain a checkbox that the user is
     required to check before the .target file is really deleted.  This is
     just like when you delete a Project from the workspace.

   - You could add a "Don't ask me again" checkbox for those that find it
     annoying. Although I'm not convinced that this is a good thing.
Comment 1 Darin Wright CLA 2009-03-09 11:20:58 EDT
> Show in the UI where the target file resides:

The pref page now shows were workspace definitions reside with workspace relative paths using a styled label provider.

We should prompt the user when removing target definitions with a "don't ask again" check box. (I suppose "don't ask again" preference setting for this could be on the same page). The prompt should explain that this will delete files.
Comment 2 Curtis Windatt CLA 2009-03-31 11:33:55 EDT
(In reply to comment #1)
> We should prompt the user when removing target definitions with a "don't ask
> again" check box. (I suppose "don't ask again" preference setting for this
> could be on the same page). The prompt should explain that this will delete
> files.
> 

As much as I don't like having more controls on the page, we do need to prompt before deleting files from the workspace.

Ankur, if you want to work on this, a similar dialog can be seen by going to the run/debug drop down icons that show a list of recent launch configs.  If you hold down Ctrl and Shift then click on one, we will remove it, but prompts your first.  The checkbox can be reset using the Run/Debug > Launching preference page ("Prompt for confirmation before removing...").
Comment 3 Ankur Sharma CLA 2009-04-14 16:48:15 EDT
Created attachment 131846 [details]
Patch

Added a confirmation dialog on Remove. The setting for prompt persisted in the store. Added check box to MainPreferencePage to control it. And Some code to keep the pref page and dialog behaviour in sync.
Comment 4 Curtis Windatt CLA 2009-04-14 17:38:07 EDT
Made a couple changes:

Now it only prompts if we are deleting a workspace file (Might have to update this when I look at the external files).
Updated the text to reflect the above change
Fixed the return code logic, hitting cancel was the same as hitting yes.

Fixed in HEAD.