Community
Participate
Working Groups
Created attachment 282900 [details] Dark elements in older non-themed Eclipse This morning I was experimenting with the latest Eclipse nightly build to investigate dark theme issues in Bug 562043. This afternoon, I opened an older version of the IDE (2020-03 M1 from early January 2020). It has theming completely disabled, but I immediately noticed that some native elements were styled as dark. See attachment. Closing the latest Eclipse nightly and restarting the older Eclipse do no solve the problem, my next attempt will be to restart the whole system, though postponing that for now as there's a big Windows update pending... Are "OS.setTheme" or one of the newly introduced APIs changing settings at the operating system level, causing them to be applied to all IDE instances, even older ones that do not ship these new dark switches?
Restarting the computer did not help. However, resetting all entries to default in "Colors and Fonts" made things go back to normal. Did some weird preference synchronisation happen somehow?
w.r.t. preference synchronization, how did you install the IDE's? When using Oomph (eclipse-installer) user preferences can be synchronized via the user setup, Navigate > Open Setup > User > User Preferences. Depending on your settings they might be automatically recorded and applied on startup.
The older IDE version was indeed installed through Oomph. Though the nightly build was an unpacked zip from the Eclipse downloads website. Granular styling attributes from one of the default built-in themes is really not the kind of thing that I would expect to be synchronized, even more so if it's some of the attributes but not others.
*** Bug 565477 has been marked as a duplicate of this bug. ***
When the dark theme is applied, many properties are touched. These property changes are detected by the Oomph properties recorder and (optionally) stored in the user profile. These properties get re-applied to other workbenches, including light ones. As a result, the dark preferences could be applied to a light workbench. Basically, there are multiple sets of (default) parameters, one for each theme. In a single workbench this is okay, assuming that a user doesn't switch all themes all the times and the user doesn't customize the theme properties themselves. In the multi-workbench case, introduced by Oomph, this becomes an issue. Because its more likely that a user has workbenches with different themes. @Ed: Do you have an opinion or some input on this?
Generally the preference recorder has no idea what all these things actually mean and I'm not familiar with what's all recorded when changing the theme preference. Ideally it would just be a single setting to be recorded and changing that would do all the necessary things, but I assume that isn't how it's actually implemented...
(In reply to Ed Merks from comment #6) > Generally the preference recorder has no idea what all these things actually > mean and I'm not familiar with what's all recorded when changing the theme > preference. Ideally it would just be a single setting to be recorded and > changing that would do all the necessary things, but I assume that isn't how > it's actually implemented... Yes, that makes sense to me. The color preferences are independent of theming. If theming sets color preferences, there is no way to know later if they were set by theming or directly by the user. Pierre, did your unzipped Eclipse operate on the same workspace?
It's been a while, but I seem to recall it was a brand new workspace, which was all the more confusing.
(In reply to Pierre-Yves Bigourdan from comment #0) > Created attachment 282900 [details] > Dark elements in older non-themed Eclipse After a theme switch, Eclipse prompts for a restart and if we don't restart that may lead to above looking Eclipse. Otherwise I can't reproduce this issue. Please share exact details on how to reproduce this issue.
