Bug 129132 - [Preferences] preferences for saving-before-build should offer Always, Prompt and Never
Summary: [Preferences] preferences for saving-before-build should offer Always, Prompt...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2006-02-23 05:31 EST by Andrew Ferguson CLA
Modified: 2019-09-06 16:15 EDT (History)
3 users (show)

See Also:


Attachments
Proposed patch (19.01 KB, patch)
2007-08-14 11:32 EDT, Bernie CLA
no flags Details | Diff
Patch (42.20 KB, patch)
2008-01-21 16:21 EST, Tod Creasey CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Ferguson CLA 2006-02-23 05:31:15 EST
hi,

 for manual builds (i.e. when when the preference for Build Automatically is not selected), there is only a choice to build regardless of editor dirty state, or to automatically save dirty editors and then build. 

It would be better if the user had a choice analogous to that offered when launching a launch configuration, under the preference:

  Preferences -> Run/Debug -> Launching -> Save dirty editors before build

which offers both the Always and Never behaviours already available, and in addition Prompt.

Prompt opens a dialog with a list of dirty editors and check boxes to allow a subset to be selected for save before the launch.

thanks,
Andrew
Comment 1 Tod Creasey CLA 2007-06-13 16:28:32 EDT
There are currently no plans to work on this however I would be happy to look over a contribution
Comment 2 Bernie CLA 2007-08-14 11:32:47 EDT
Created attachment 76051 [details]
Proposed patch

This is my first attempt at a platform patch, some I'm more-or-less expecting there to be some issues. It's OK as far as I can see, but I'm happy to make changes.

Some API change was necessary. Main points to note:

BuildAction.isSaveAllSet is gone - there are now 3 possible values rather than 2, so it doesn't make much sense for this to be boolean. As it was rarely used, I've replaced it with direct lookups of the preference.

BuildUtilities.saveEditors is now boolean as the user is able to cancel the build on prompt, so we need to be able to tell callers about the cancellation.

BuildUtilities.saveEditors now collects the list of dirty editors and calls EditorManager.saveAll in order to get the 'prompt' behaviour, instead of directly saving editors itself.

As 'save before build' is only meaningful for manual builds, I modified the UI to grey out this option if 'build automatically' is selected.

I've set the default behaviour for manual builds to be 'prompt'.
Comment 3 Tod Creasey CLA 2007-11-23 15:40:33 EST
Removing BuildAction#isSaveAllSet is a breaking API change so we can't delete it.

What make make more sense is for us to replace an action with a command and have the new command support supply the menu entry and then we use that. Build Action will still be there and not use the support.

I agree with the spirit of what you are doing - we should consider this as part of what we want to do as we move to commands.

Adding Boris and Paul as they own editors and commands respectively.

Comment 4 Tod Creasey CLA 2008-01-21 16:21:15 EST
This patch has some issues

1) It breaks API. BuildAction is API so we can't delete isSaveAllSet(). We could deprecate it but we need to understand the issues.

2) We can't change the value of an existing preference from a boolean to a String as there will be people with it still in thier preference store.

I have updated the patch for the current code stream and I will attach it now.
Comment 5 Tod Creasey CLA 2008-01-21 16:21:57 EST
Created attachment 87446 [details]
Patch
Comment 6 Susan McCourt CLA 2009-07-09 19:27:56 EDT
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Comment 7 Eclipse Webmaster CLA 2019-09-06 16:15:22 EDT
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.