Community
Participate
Working Groups
This happened when going from 4.5m5 to 4.5m6... It probably wouldn't be such a huge problem if it was a darker background, but as it is a light gray background and not a dark gray the dark theme is not really usable anymore. I can reproduce it consistently in Windows 8 (haven't checked other platforms). I also got the latest integration build (I20150408-1100) in a fresh workspace and the issue is still present.
Created attachment 252244 [details] Screenshot showing issue Adding screenshot which shows trying to set a purple color and having the editor revert back after 'Ok' is pressed (and note that the editor has a light gray background).
Ok, I've investigated this a bit further and this happened due to applying the commit 62453526ec07379e36b8782df2f266924440d005 Bug 431845 - [Themes] [CSS] Simplify dark theme The commit has some things which I consider wrong: 1. It defines: /* Default fallback for any control not specified further */ * { background-color: #242728; color: #eeeeee; } And later it does: Form, Form *, { background-color: #4F5355; color: #AEBED0; } I.e.: can you spot the comma ending: "Form *,": this mostly overrides the previous definition for this separate background which makes the editor have a lighter background meant to the preferences (this is definitely a bug is the commit which should be fixed -- but if this is done, the preferences don't have the lighter background as it ends up in the previous rule which is meant for the editor). Personally, I think that the commit should be reverted... it oversimplified things by creating global definitions which we can't really use if we want to be able to let the user customize the editor background color -- or anything else really (I know the previous rules were much more verbose, but at least they worked well). I'd like to discuss this and provide a commit still for M7 -- preferably reverting the previous commit and solving merge conflicts (as the simplification didn't work IMHO) -- and if not that at least fixing the bug on the "Form *," (although the final result isn't good for the preferences).
New Gerrit change created: https://git.eclipse.org/r/45534 WARNING: this patchset contains 1464 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
I reverted the commit in a gerrit request... but it seems to have an issue on ToolItems after the revert (I'm taking a look at it).
(In reply to Fabio Zadrozny from comment #4) > I reverted the commit in a gerrit request... but it seems to have an issue > on ToolItems after the revert (I'm taking a look at it). Actually, I spoke too soon -- it just required a restart (so, the revert should be Ok to fix the issues).
Stefan: do you have some comments here?
I'm loathe to use '*' rules since it affects custom widgets that assume certain colourings. It's hard to undo such problems.
I think the correct fix for this is to implement a CSS listener which resets the form to its default. A restart should already reset the color without the revert of the commit. Fabio, can you confirm that?
(In reply to Lars Vogel from comment #8) > I think the correct fix for this is to implement a CSS listener which resets > the form to its default. > > A restart should already reset the color without the revert of the commit. > Fabio, can you confirm that? Please disregard this comment, not a good idea to answer quickly on the phone. This is a completely different issue here.
Adding Andrea too (which was also at Bug 431845). Andrea, any comment here? Particularly on Windows (at least in my opinion), the current dark theme seems broken with the changes... The main things which broke were: - The editor background can no longer be customized. - The preferences had a color for the tree and another lighter one for the pages (as a workaround for not being able to customize hyperlinks).
Thanks Fabio for reporting. I would like to see if Stefan can come up with a fix for this, otherwise we unfortunately have to revert the change of Stefan. I added the explicit styling for the HeapStatus to the revert which is required if we remove the default color.
Hi all, I have feared that the simplification would be too much (which is why I wanted to create an experimental additional theme to try out things in the first place ...). I had hoped that the overly simplified version could be fresh start to which we would add specific rules again as needed. But I don't have objections against reverting the commit and take the original CSS and remove the workarounds for the bug which have been fixed in the meantime in there to simplify a bit. (Best thing would be if Andrea could help here, because he has the most knowledge about which parts are workarounds and which ones are not - this is not always clear from the CSS and it is quite some effort to get it right on all platforms). In a more general discussion, I think that CSS styling at the level we currently do will never lead to the perfect result, because what we try to achieve is a way to make Eclipse look good with light and dark themes on all platforms with maintainable and simple CSS. To do that, we want to style (almost) all widgets in general--if, e.g., a non-platform plugin creates and uses custom widget (subclass) which is based on the look of the platform, we would want to have it styled according to the theme (hence the *-rule(s) I have used). But your argument, Brian, is valid as well: > I'm loathe to use '*' rules since it affects custom widgets that assume > certain colourings. There might actually be widget the user does not want to be styled by the theme. In fact, both requirements are in conflict. We could think of other ways (for Neon ...) to do styling. A simple solution would be an opt-in or opt-out of theme styling with something like Widget.setData("css.styling.enable", Boolean.TRUE) A more flexible solution could be to define common colors (similar to SWT.WIDGET_FOREGROUND) which can be modified using CSS - or, as has been proposed by different people during the past months and years - we could move parts of the CSS engine down to the SWT level and use this to modify the SWT.xxx constants.
(In reply to Stefan Winkler from comment #12) > Hi all, > > I have feared that the simplification would be too much (which is why I > wanted to create an experimental additional theme to try out things in the > first place ...). I had hoped that the overly simplified version could be > fresh start to which we would add specific rules again as needed. > > But I don't have objections against reverting the commit and take the > original CSS and remove the workarounds for the bug which have been fixed in > the meantime in there to simplify a bit. (Best thing would be if Andrea > could help here, because he has the most knowledge about which parts are > workarounds and which ones are not - this is not always clear from the CSS > and it is quite some effort to get it right on all platforms). > > > In a more general discussion, I think that CSS styling at the level we > currently do will never lead to the perfect result, because what we try to > achieve is a way to make Eclipse look good with light and dark themes on all > platforms with maintainable and simple CSS. > > To do that, we want to style (almost) all widgets in general--if, e.g., a > non-platform plugin creates and uses custom widget (subclass) which is based > on the look of the platform, we would want to have it styled according to > the theme (hence the *-rule(s) I have used). > > But your argument, Brian, is valid as well: > > I'm loathe to use '*' rules since it affects custom widgets that assume > > certain colourings. > There might actually be widget the user does not want to be styled by the > theme. > > In fact, both requirements are in conflict. > > > We could think of other ways (for Neon ...) to do styling. > A simple solution would be an opt-in or opt-out of theme styling with > something like > > Widget.setData("css.styling.enable", Boolean.TRUE) > > A more flexible solution could be to define common colors (similar to > SWT.WIDGET_FOREGROUND) which can be modified using CSS - or, as has been > proposed by different people during the past months and years - we could > move parts of the CSS engine down to the SWT level and use this to modify > the SWT.xxx constants. I think at this point (close to M7) the real solution is reverting, but given time I think creating a new experimental theme to work on it would be the ideal way of going (but we should only really stop using the current one when the new one has proven itself more as the current one covers many corner cases already). Regarding the approach, I think that the way to go would be really providing the common colors which users can use... I like the way that eclipse-color-theme works (the basic colors are defined and then mapped for plugins). It has some problems though: 1. it took it all upon itself to do the mapping, when in reality it should only provide the colors and plugins should take care of making that (but in his situation, not being something grown in Eclipse itself it was probably the only workable choice). 2. Additional colors can't be defined in plugins (for instance, in a plugin such as Git I'd like to add the colors related to the state of the file and give defaults for light/dark themes). 3. It's only based on the editor (at in its time there was no way of styling other widgets anyway). In LiClipse (http://www.liclipse.com/) what I do is provide more colors and mappings that are not editor-related (so that it works for EGit for instance)... that fixes number 3 (and 2 to some point as I extend it manually), but 1 still stands and is probably the major issue.
(In reply to Fabio Zadrozny from comment #13) > (In reply to Stefan Winkler from comment #12) > I think at this point (close to M7) the real solution is reverting, but > given time I think creating a new experimental theme to work on it would be > the ideal way of going (but we should only really stop using the current one > when the new one has proven itself more as the current one covers many > corner cases already). An new experimental theme could be created outside of the platform and distributed via the marketplace.
Gerrit change https://git.eclipse.org/r/45534 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4e700a0c61c6d2a9c0539df100fb5d7df79105cd
Thanks Fabio, for the revert. Thanks Stefan for the simplified version, I personally liked this experiment.
.
*** Bug 463690 has been marked as a duplicate of this bug. ***
Validated in 4.5.0.I20150428-0100
The bug is reproducible again (in 4.14 at least). Dark theme overrides preferences. Probably 514059 is duplicate.
I can reproduce this issue in 4.17 on macOS using the dark theme. Changing the editor background colour in preferences and pressing "Apply" does update the editor background. However, when pressing "Apply and Close" it reverts the background colour to the theme defaults.
Can confirm this issue seems to be back in 4.17 (tested on Windows)
(In reply to Serge Rider from comment #20) > The bug is reproducible again (in 4.14 at least). > Dark theme overrides preferences. > Probably 514059 is duplicate. This regression is reported as Bug 559321, it will be investigated in that context again.
