Community
Participate
Working Groups
On each of the JDT project property panes, "restore defaults" clears the "enable project specific settings" checkbox, disables the rest of the preference fields, and sets their displayed (greyed) contents to default. However, it evidently sets the displayed content to *factory* default. This is misleading, because if workspace preferences have been changed from factory defaults, it is the workspace settings that will be in effect after "restore defaults" in a project property pane. It can also create a misleading situation if the user checks the "enable project specific settings" checkbox, because the fields will be re-enabled and will contain factory default rather than current workspace preferences. To see this in action: 1. Go to workspace preferences, Java / Compiler / Building. Click "restore defaults" to restore factory defaults. Note that "max number of problems" is 100, and "enable use of exclusion patterns" is checked. 2. Change "max number of problems" to 50, and clear "enable use of exclusion patterns. Click OK. 3. Create a new Java project (or edit an existing one with defaulted values). View its project properties, Java / Compiler / Building. Note that the values displayed are the workspace settings (50, unchecked). 4. Click "restore defaults". Note that the "enable project specific settings" is unchecked, and the displayed values of the settings change to 100 and checked, that is, to the factory defaults. (This happens regardless of whether the project specific settings checkbox had been checked, and regardless of whether the values had been changed.) EXPECTED: values should be 50/unchecked, same as workspace preferences. 5. Click OK to dismiss the property pane; then launch it again. Note that the values have (correctly) returned to the workspace values, 50/unchecked. So despite the misleading display, "restore defaults" actually led us to the current workspace preferences. 6. Click "restore defaults"; note settings change back to 100/checked. Now check "enable project specific settings". Note settings are still 100/checked. 7. Click OK to dismiss the property pane; then launch it again. Note that settings are 100/checked. In this case, "restore defaults" led us to factory defaults. So depending on the precise set of operations, "restore defaults" has two different meanings. EXPECTED: "restore defaults", in a project properties pane, should ALWAYS mean "return to current workspace settings".
I believe the problem is this code in OptionsConfigurationBlock: public void performDefaults() { DefaultScope defaultScope= new DefaultScope(); //... This should probably be something like: public void performDefaults() { Scope defaultScope= (fProject == null) ? fLookupOrder[2] : // DefaultScope fLookupOrder[1]; // InstanceScope // ...
Sorry, make that "IScopeContext", not "Scope". I've tested this change and it does appear to cause the behavior that I think is right.
Martin, can you please investigate ?
you're right. Fix released for 3.2 > 20050802 Dirk, do you want that for 3.1.1 (IMO not a major bug, but a trivial fix)
Created attachment 25543 [details] patch on OptionsConfigurationBlock.java
Can be annying. Approved for 3.1.1. Reviewed patch and is ok for me.
Reopening for 3.1.1 back porting.
Tom, can you do a second review?
reviewed the patch - ok.
released in 3.1.1 stream for M20050803
Start verification...
There are now problems with widget enablement: 1. set Workspace Compiler > Javadoc > 'Malformed Javadoc comments' setting to 'warning' 2. click 'OK' 3. open project properties of that preference 4. click 'Restore Defaults' ==> some of the widgets become visually enabled but in fact they are disabled. This is at least as confusing as the 3.1 behavior and should be fixed.
Created attachment 26799 [details] Picture of broken properties dialog
I would suggest that a new bug is filed for this so this one can be closed again.
Do as you like, however make sure that the new bug is targeted for 3.1.1.
Daniel, you are normally one you prefers having new bugs instead of reopening existing once if the bug reported got fixed ;-). Opened bug 108793. Daniel, can you please set the bug to verified if you agree that the problem reported by this bug is fixed.
see comments above
