About the design of the text editor light/dark theme support:
- The idea is that the SeText base text editor gets most of the logic, keeping the effort needed to support different themes in the specific text editors to a minimum.
- Each text editor defines a
...TextEditorStyleNames, an enum with named styles. The
TextEditorThemeinterface allows mapping named styles to concrete
Styleinstances, and thus allows defining multiple themes. Each text editor defines a
...TextEditorStyleNames. The text editors previously used to define
...Styleswith the named styles and concrete styles directly coupled. This is thus split to
- The light themes for all text editors still use the same styles. The one exception is that their
DEFAULTstyles are now all black, rather than some off-black slightly-brownish color. I have no clue why we ever defined that color.
- I invented new dark theme color schemes. I tried to use similar colors as for the light theme, to keep the colors recognizable (e.g., CIF controllable/uncontrollable event colors). Obviously black-like colors becomes white-like colors, etc. I spent quite a bit of time to ensure the colors are distinct from each other, but also have enough contrast with the editor background, and have a bit of a consistent feel in terms of brightness etc.
- Each text editor gets a preference page in the Eclipse Preferences window. There you can configure the editor to use a dark or light theme. But by default an automatic theme is configured that uses a dark or light theme depending on the current Eclipse theme. This way, it should work out of the box in most cases, and users won't have to configure these settings.
- I hooked into the preference system to monitor for changes to our own text editor preferences, as well as the Eclipse theme preferences. If any of these settings change, all open text editors automatically get rethemed to match the new settings.
- The common/shared Eclipse theme functionality is in the application framework. This allows reusing it for #417 (closed). I would have rather put it in
org.eclipse.escet.common.eclipse.ui, but that creates dependency cycles when using the functionality in the application framework.
- I opted for using internal Eclipse APIs to access
ThemeEngine.E4_DARK_THEME_ID, which contain the name of the plugin that defines some of the theming preferences, and the name of the Eclipse built-in dark theme. I could have opted to just hardcode the strings by copying them. However, this way we get compile issues if the plugin is renamed or so, which means we are less likely to have broken dark theme support upon changes to Eclipse itself.
- I could not find a general way to reliably detect whether the current Eclipse theme is a light or dark theme. I therefore opted to support only the built-in Eclipse themes for the automatic mode. As a consequence, if a user installs some custom dark theme, it does not get detected as a dark theme, and will thus be detected as a light theme, with our text editors also going to light theme mode. I'm not sure whether there is a better way to do this. Maybe we could check some background color of the current theme instead. But that seems more complicated. I doubt many users install custom themes, and if they do, they can also explicitly configure our text editors to use a light or dark theme, rather than using the automatic mode. So, for now this seemed sufficient.
- The CIF to yEd conversion uses the CIF text editor light theme, for backward compatibility.
The changes in the branch seem big, but a lot of it is just changed test output, or similar changes in various text editor plugins. I propose to review not per commit, but instead the final resulting changes, in this order:
- The new general Eclipse theme functionality in the
- Changes and additions in the
- Changes to the Chi, CIF, SeText and ToolDef text editor plugins, which are all very similar.
- Changes to CIF to yEd plugin.
- Changes to CIF to yEd test output.
Closes #347 (closed)