Community
Participate
Working Groups
While working on the color api fix patch (Bug 508819) I found two issues with Color/Font preference if defaultsTo is used. 1) Definitions can still be edited by others: If you set a color (or font) to be not editable (isEditable=false), then Colors (or fonts) that reference it via defaultsTo=... can still edit such colors (or fonts). 2) User preferred color is loaded instead of default if isEditable=false is set: If a user sets a color (e.g HOVER_/Information), and if that color is subsequently made 'isEditable=false', then when eclipse loads, the prefered user color is loaded instead of the default one. So if colors that reference it use "reset to default", they get the old prefered color instead of the default one. This has the issue that the old color is left no-mans-land and cannot be changed and isn't set to it's default. I wrote a fix to address these problems. Patch to be submitted shortly.
New Gerrit change created: https://git.eclipse.org/r/96889
New Gerrit change created: https://git.eclipse.org/r/96895
Created attachment 268295 [details] Screenshot of issue
~Awaiting patch review when time is right...
~Awaiting Oxygen release / code unfreeze at end of June.
~Awaiting patch review/merge.
@ Platform.ui committers, can someone review please?
Gerrit change https://git.eclipse.org/r/96895 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d78dda54220af7f1a6523c69531e01988c12fe6b
Tested with the properties from org.eclipse.e4.demo.cssbridge.ui.views.Theme and the new behavior looks correct to me. Thanks, Leo.
(In reply to Lars Vogel from comment #9) > Tested with the properties from org.eclipse.e4.demo.cssbridge.ui.views.Theme > and the new behavior looks correct to me. Thanks, Leo. Thank you for review
