Community
Participate
Working Groups
The option 'Store the encoding of derived resources separately' only restores to whatever the last saved state was. It should restore to false, since that is the default. The relevant code is ResourceEncodingFieldEditor.doLoadDefault(), which should look like this: protected void doLoadDefault() { super.doLoadDefault(); if (separateDerivedEncodingsButton != null) separateDerivedEncodingsButton.setSelection(false); }
Can reproduce using 4.3 RC3.
Created attachment 232692 [details] Patch
Dani, can you please push this?
(In reply to comment #3) > Dani, can you please push this? Ideally, Platform Resources would provide a constant for the default which could then be used in the UI. If we decide to change the default in the future, we currently have to update several places in Core and UI. If you think it's too much work, then we can go ahead with the suggested change, but to be correct, Tom should attach a patch (with copyright addition), since he suggested the fix.
.
(In reply to comment #4) > Ideally, Platform Resources would provide a constant for the default which > could then be used in the UI. If we decide to change the default in the > future, we currently have to update several places in Core and UI. It makes sense, although I think there are also many other places where defaults are hard-coded in UI instead of being exposed as API from core plugins. See for example performDefaults methods for ResourceInfoPage or JavaCompilerPropertyPage. Do you think we should fix all of them?
(In reply to comment #6) > (In reply to comment #4) > > Ideally, Platform Resources would provide a constant for the default which > > could then be used in the UI. If we decide to change the default in the > > future, we currently have to update several places in Core and UI. > > It makes sense, although I think there are also many other places where > defaults are hard-coded in UI instead of being exposed as API from core > plugins. See for example performDefaults methods for ResourceInfoPage or > JavaCompilerPropertyPage. Do you think we should fix all of them? I would fix as we go i.e. if a problem arises in such an area, fix it, but don't spend time too touch something that works fine.
I'm working on a patch, including the suggested constant.
Created attachment 232744 [details] Resources patch
Created attachment 232745 [details] UI patch
(In reply to comment #9) > Created attachment 232744 [details] [diff] > Resources patch Thanks for the patch Tom. Unfortunately, the patch does not apply via IDE: EGit does not (always) like git am patches, see bug 368358. After manually cutting away the non-patch related stuff, I got a conflict in the copyright date because the patch was probably not made against R4.3, but some older branch. The fix looks good in general but it needs some minor polish: - make the patch against 'master' - since it adds new API to Luna, the bundle version needs to be increased to 3.9 ==> pom.xml and MANIFEST.MF need to be updated ==> the new constant gets 3.9 - the copyright date is wrong: it has to be yearOfFirstChange, yearOfThisChange You need to confirm that you wrote the code. I suggest you do this using the "new way" i.e. sign the CLA and write in this bug report that you contribute the patches under that CLA. For more details see: http://mmilinkov.wordpress.com/2013/06/17/eclipse-clas-are-live/ Alternatively, you can answer the 3 questions.
Comment on attachment 232745 [details] UI patch (In reply to comment #10) > Created attachment 232745 [details] [diff] > UI patch Thanks for the patch Tom. The fix is not complete as there are other places in that class that assume the default being 'false'. Test Case: 1. set the default (constant) to 'true' 2. start a target workspace 3. create a project 4. open its properties ==> good: option is checked 5. disable the option and click 'OK' 6. open its properties ==> bug: option is still checked
Created attachment 232811 [details] Resources patch
Created attachment 232812 [details] UI patch
I signed the CLA. I'm not familiar with pom's, so hopefully my guess for the fix is correct.
(In reply to comment #15) > I signed the CLA. I'm not familiar with pom's, so hopefully my guess for the > fix is correct. Looks all good! Pushed with http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=7482f74653c7df762431dab80ad7bb6adbcd1984 http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=59911823d58de77541ca51edf6b03ee3d1be86a0
There was one scenario that was still broken: 1. set the default (constant) to 'true' 2. start a target workspace 3. create a project 4. open its properties ==> good: option is checked 5. create a derived file with custom encoding ==> good: stored in special pref file 6. disable the option and click 'OK' ==> good: encoding moved to "normal" pref file 7. enable the option and click 'OK' ==> bug: encoding not moved to special pref file Fixed with http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=33aeb3fd6360a63c8fb96d20a071435fb1d0dbbb
Verified in I20140528-2000.
