Bugzilla – Full Text Bug Listing
| Summary: | [Dark Theme] [CSS] Syntax coloring preferences and annotation preferences not persisted on Dark theme | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kaspar Thommen <snooper77> | ||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | 2xsarilhos, Brandon_McCulligh, daniel.rolka, daniel_megert, dinghuicong, gautier.desaintmartinlacaze, kashihara, Lars.Vogel, mail, markus.kell.r, ricardo.richard.b, rustyscottweber | ||||
| Version: | 4.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=520512 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Confirmed using R4.4. Daniel, looks like bug 434485 did not catch all cases. The annotations are defined in /org.eclipse.ui.themes/css/dark/e4-dark_preferencestyle.css *** Bug 441333 has been marked as a duplicate of this bug. *** Or at least change the default preference back to underlined instead of highlight. This is driving me insane every time I re-open eclipse there are yellow highlights (warnings default) everywhere. *** Bug 450898 has been marked as a duplicate of this bug. *** The issue is caused by some kind of optimization done by JDT that doesn't store the property in the 'org.eclipse.jdt.ui.prefs' file when it gets the default value. So when i.e. the 'semanticHighlighting.localVariable.enabled' property gets the 'false' value then it gets stored in the preference file and it is fine from the CSS engine's point of view. However when it gets 'true' then JDT doesn't store it (or even removes from the property file) and for the CSS engine it is the marker that is it the default value (not modified by user) and it can get overridden with the proper CSS values. After removing the property from the property file there is no information that it gets customized by the user. The solution here is to always keep the property in the property file after user's customization. In this way the CSS engine will know that the particular property has been modified by the user and we should skip the overriding by CSS process for such property. I will move it to the JDT component since we are not able to fix it on our site - the fix for that should be quite easy. The 'semanticHighlighting.localVariable.enabled' property gets overridden in the '<ECLIPSE_HOME>/plugins/org.eclipse.jdt.ui_<SPECIFIER>.jar/css/e4-dark_jdt_syntaxhighlighting.css' style sheet Daniel (In reply to Daniel Rolka from comment #5) That sounds like JDT is just following the normal preference storage rules: If a setting is different from the default, then store it. If it's the same as the default, then *remove* the whole setting, so that the user always gets the default value, even if the default gets changed later. If the dark mode needs different defaults, then it has to set those defaults in the preference store. Note: If you want to move a bug to an other component, then you also have to update the assignee. Moved the bug back to Platform/UI now. (In reply to Markus Keller from comment #6) > (In reply to Daniel Rolka from comment #5) > That sounds like JDT is just following the normal preference storage rules: > If a setting is different from the default, then store it. If it's the same > as the default, then *remove* the whole setting, so that the user always > gets the default value, even if the default gets changed later. > > If the dark mode needs different defaults, then it has to set those defaults > in the preference store. > It is not so simple since I don't know the default value being at the IPreferenceChangeListener listener level. I know only the old and the new values and sorry, but I don't know how to guess the default one basing on it. OK, when the old value was 'true' and the new one is NULL, I can predict that the default will be 'false'. However such assumption is very risky, especially keeping in mind that values of preferences can have any format OK, we know what is the issue here, but I don't know how to fix it on the Platform UI side at this moment Daniel Removing all 'XIndicationHighlighting=true' from e4-dark_preferencestyle.css seems to fix this bug and prevents overriding user settings. I think we should just remove these lines. Created attachment 249562 [details]
Modified e4-dark_preferencestyle.css
PS: The patch fixes only the issue with annotations, not the one with syntax coloring, Thank you so much for this patch, it fixed the problem. Now I don't fret about closing eclipse. *** Bug 459939 has been marked as a duplicate of this bug. *** Is this still an issue with the default CSS preferences? (In reply to Lars Vogel from comment #13) > Is this still an issue with the default CSS preferences? No reply, marking as works for me. |
1. Extract eclipse-java-luna-R-win32-x86_64.zip and start Eclipse 2. Go to Window -> Preferences -> General -> Appearance -> Theme -> Dark. Click OK. 3. Create a new Java project and add the following class: public class Test { public static void main(String[] args) { int myInt; } } 4. Go to Window -> Preferences -> Java -> Editor -> Syntax Coloring, Element Java, uncheck 'Enable' on 'Local variable declarations' and 'Local variables' 5. Go to Window -> Preferences -> General -> Editors -> Text Editors -> Annotations, select 'Warnings' and select 'Squiggly Line' in 'Text as' 6. Restart Eclipse 7. You'll notice that the 'Local variable declarations' preference got re-enabled, because the 'myInt' variable is orange again, while the 'Local variables' one was persisted. 8. You'll also notice that the 'Warning' annotation has changed back from 'Squiggly Line' to 'Highlighted', because the 'myInt' variable is highlighted again.