UI refresh: a modern light and dark theme

[thomasritter]

Known issues

First version has been submitted. Here the list of already known issues we will work on.

• Headers do not react to hovering events anymore. Add hover indicator. ( Dark, Light -> Win, Mac)
  --> Adding hover indicator for unselected tabs #2130
• “Git Staging” view does not have a grey background. This makes the grey buttons standout. Background should be grey. (Light -> Win, Mac)
  --> Fix for 'Git Staging' view background #2168
• "Types" view does not have a grey background
  --> Fix for background color of some views like Types, Console etc #2153.
  --> Revert in Reverting the bg color for StyledText, Button, Table controls #2181
• Editor line number strip should have the same color as the editor background. (Dark -> Win, Mac)
  --> Fix- Background color for gutter line in editor #2144
• Provide same themes for Linux (Dark, Light)
  --> Improvement to Light and Dark theme for Linux #2137
• Issue in breadcrumb
  --> Removing unnecessary themeing extension for breadcrumb (light theme) eclipse-jdt/eclipse.jdt.ui#1577
• Missing alternate row colors in trees on macOS
• Editor Tabs looks greyed out --> Light (Preview) Font color change for text in tabs #2294
• Multipe Tabs have blue highlight --> Light (Preview) theme - change in the behavior of highlights for selected tabs #2286

Status quo

A lot of Eclipse users are asking for a more modern look&feel. If you search the internet you will find a lot of such posts.

https://www.reddit.com/r/eclipse/comments/i4hlpw/make_eclipse_look_modern/
https://www.reddit.com/r/eclipse/comments/jvfyv8/will_eclipse_get_amajor_ui_upgrade_to_look_modern/
...

There is quite some progress in this area with simplified tab view options (available), sticky scrolling (in progress), modernized find integration (in progress) and many other small and bigger fixes which are currently being worked on in the Eclipse community.

This issue focuses on the default themes. The default light theme has not been updated in years. It is not state of the art anymore. All major IDEs have shifted to a different light theme style. Here is an overview how the other most commonly used IDEs look like out of the box.

VS Code

IntelliJ

Visual Studio

XCode

What design styles follows a theme in 2024?

When comparing the different IDEs it is easy to pick out the design decisions they all share. These are:

1. Lightweight view tab design.
2. Flat look. No use of 3D gradiants.
3. Views use a darker background color. This naturally focuses the eye on the editor area which is where most of the work happens. We like to call editors the main actors and views the supporting actors.

Especially, point 3) is important. When looking at other UIs outside the IDE space it becomes clear that this is the standard. The navigation sidebar is usually using a darker background color than the main content area (e.g. MacOS finder, Apple Music, Powerpoint, OneNote, MacOS notes, MS teams, ...). That's probably the biggest reason why Eclipse feels so outdated.

Proposal for the updated default light theme

The updated theme addresses all three points mentioned above. Here are some before/after screenshots.

Current theme:

Modernized theme:

Details
Views tabs. Same minimalist design you can find in the other IDEs.

Editor tabs. Same design as in the other IDEs. The active tab has a white background which blends in nicely with the white background of the editor area.

Proposal for the updated dark theme

The updated theme follows in the footsteps of the light theme. From a design perspective it simply inverts the colors. This means the most important part is the darkest and the less important parts are brighter. When working on the dark theme we noticed that it was already in a much better shape. Our proposal simply cleans up same aspects of the current design.

Here is a screenshot of the IntelliJ dark theme as a reference.

Current theme:

Modernized theme:

Summary

We have been working hard on these proposals and were pleasantly surprised how good Eclipse can look like with the updated themes. Our in house developers have been using them already for months and do not want to go back to the old ones. While we tested them extensively there is still a chance that we missed some small details. Please report any issues you find and we will look into them. We decided to split the changes into three changes for easier review:

• One for the light theme: Improvement to the existing Light Theme #2103
• One for the dark theme: Improvement to the existing dark theme #2112
• One to adjust the thickness of the highlight underline of active tabs. We propose to reduce it by one pixel: Height reduction of highlight #2111

At the Eclipse Community Day we asked whether to immediately replace the existing themes or add them as new ones. All committers (@merks , @HeikoKlare , @marcushoepfner , @BeckerWdf , @HannesWell , @sratz , @fedejeanne ) we talked to asked us to replace the existing themes. We can always rollback the changes if there are issues.

As a final note, we focused on Windows and Mac first. This is already a lot of work. If these changes get accepted we will also look into applying the visual refresh to the Linux themes.

[Wittmaxi]

I love this change! Having see the difference it can make, I can not wait for this to be in my IDE. Thank you!!!

I might be alone with this opinion, but to me the new theme looks almost unchanged and I feel like a bigger contrast might look even better. From your presentation I know that you copied the values of VScode but to me, the light theme looks nearly unchanged. Have you experimented with "greater contrasts" already?

[laeubi]

It might be my glasses but with the "modern" style I can hardly read Main class + method names ... and even if it says "Please ignore the incorrect syntax highlighting. It does not occur with the change." I wonder, why not make a screenshot with correct syntax highlight?

[HeikoKlare]

I really like and appreciate these changes and consider them a great improvement in terms of look&feel 👍 I hope that we can find an agreement soon and have them available as soon as possible.

I have two concerns so far:

1. I agree with Christoph that having a proper dark theme screenshot with the correct syntax highlighting would be good.
2. I am not sure about the view tab changes when using the classic dense tab style with icons instead of the newer one without icons. While I like this change with the new tab header styling (aligned with, e.g., VS Code), with the classic one they don't really feel like headers to me anymore. In addition, the headers do not react to hovering events anymore, like they did before, which makes it more difficult to understand them as tab headers. At least the latter is probably a bug and not intended.
   

[thomasritter]

@laeubi Your comment applies to #2112, correct? Sorry, for that one. Matthias Becker told us that the syntax highlighting colors are linked to a theme ID and if you change the ID they break. This is what you can see in the screenshot because we duplicated the theme while working on it. Now, with #2112 we thought it would not be a problem because we change the existing theme and no ID breakage should happen. But it turns out that we were wrong and somehow the editor is picking the light theme syntax colors and not the one for the dark theme. We are investigating this, right now. Of course, in this state the change for the dark theme cannot be submitted.

[thomasritter]

I updated the screenshot of the new dark theme. It features the correct syntax highlighting, now.

[HeikoKlare]

I updated the screenshot of the new dark theme. It features the correct syntax highlighting, now.

Thank you! The screenshot shows the new dark theme also with a changed font color theme. I don't see that as part of the current dark theme improvement PR. Will you provide it later on? When I test the PR, I still have the existing "christmas tree" font colors in dark theme, so I would really appreciate an update of them as well 🙂

[vogella]

I also like the changes, tested under Windows. They are not ground-breaking but do the little twists to make the theme look more professional.

In my opinion our styling also suffers from:

• Old styling icons, if you check the above non Eclipse tools they all moved to less colorful icons
• Color errors in the toolbar and toolbar icons, see for example the perspective button in the dark theme which is light or the toolbar background in the Outline view

• Mis-aligned icons, the center of multiple icons is different, for example the center of the "Run external tool" button icon is higher than the "Run button". Put a lineal on the toolbar bottom or top to see what I mean

None of the above is related to this change but I wanted to mention it, now that more people work on the theming.

I merge the changes so that we can polish these changes with the help of more eyes (and also to get the promised Linux change cc @thomasritter)

For reference on my styling background I introduced the dark theme in Eclipse and updated the Windows theme to be less Win95 (removed the gradients) among other changes in the CSS. I also introduced the pseudo-class support for preference styling to help @BeckerWdf with his initial dark theme of the ABAP tooling.

[humphreygao]

make sash width = 0? see https://bugs.eclipse.org/bugs/show_bug.cgi?id=562536

[vogella]

#2112 and #2103 merged

[vogella]

make sash width = 0?

Can you test and create before and after screenshot with new Eclipse? Your closing X for the view proves that you are using a super old version. IIRC the sash zero did not make a difference in past.

[vogella]

cc @PyvesB

[PyvesB]

Can you test and create before and after screenshot with new Eclipse?

You'll need to pull and rebase my proposed change to do so: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/170913

[HannesWell]

Thank you @thomasritter for this enhancements, in general I like it. I tried tonight's I-build on my Windows computer and found the following cases that don't look nice after the update:

• Breadcrumb
  
• EGit Staging View
  

In both cases it looks like the background of 'flat' buttons (haven't checked what they are exactly) don't fits to the overall background color anymore. Maybe this is because some assumptions about the background were made that are not true anymore or maybe something is missing in the updated theming. I also noticed that the Commit-Header in the History view (green box) is now in a light gray, while before it was the same white as the git-diff shown below (in my screenshot that part is empty since no file is selected for a better contrast). But with files being selected and after one gets used to it, that looks actually fine.

[Wittmaxi]

As a small nitpick: the gutter line should be completely dark and not have this lighter border to the left of the numbers (or at least, there should be more padding to the left of the numbers, which is probably a bigger change)

Great job guys, I really enjoy this new dark mode!!! :)

[Wittmaxi]

I am not sure what I expect here but the staging view does not feel coherent. Maybe the outside should be light and the commit message box should be dark?

[Wittmaxi]

I feel like my Find/Replace Overlay should be adapted to the theme of the editor... I'll think about this

[laeubi]

I feel like my Find/Replace Overlay should be adapted to the theme of the editor... I'll think about this

If you like your widget to be CSS style-able you can read about it here.

[Wittmaxi]

@laeubi thank you, this might be helpful! I have created a PR here, I believe it already addresses the issue quite well: #2119
(What I want is not custom styling, what I want is adaptation to the target)

[thomasritter]

Thanks for trusting us on this and merging the first version 🙏 I went through the comments and started collecting all reported issues at the top of this issue.

@vogella We will make work on the Linux themes a priority. However, I want to be transparent. We usually do not develop on Linux so it will take a little while to get @mvm-sap up and running on a Linux machine.

[Wittmaxi]

I just found this plugin. Maybe you already knew it, maybe you didn't - anyways, I think it's cool and seems widely adopted

https://github.com/PyvesB/eclipse-planet-themes

[vogella]

@thomasritter for a quicker test of the Linux changes, remove the platform restrictions in the plugin.xml for the theme. This allows you to test it under windows. Not perfect as Linux is slightly different but this should allow you to move faster and Linux user can do the final testing.

[thomasritter]

@vogella Thanks for the pointer. We will keep that in mind. One question: which distribution should we ideally use for dev&testing? Ubuntu?

[vogella]

Ubuntu sounds good to me

[iloveeclipse]

Fedora would be better, as Ubuntu is known to break GTK time to time.

[vogella]

@thomasritter and @mvm-sap any news on the Linux update? Like I explained with my dev trick, you can use Windows to test and the Linux user community (that includes me) can do the final testing.

[mvm-sap]

Especially, point 3) is important. When looking at other UIs outside the IDE space it becomes clear that this is the standard. The navigation sidebar is usually using a darker background color than the main content area (e.g. MacOS finder, Apple Music, Powerpoint, OneNote, MacOS notes, MS teams, ...).

I can understand using a darker background color on the controls in certain views (the tree in Package Explorer for example) but not for every table, tree, and styled text control that happens to be in a view. It's not appropriate to always have a darker background color on these controls, especially the text control in the Console view and some tables and trees in other views (and see here for a regression on Mac.) Even VS Code doesn't use a darker background color on every panel (Terminal, Problems panels for example).

Views use a darker background color. This naturally focuses the eye on the editor area which is where most of the work happens. We like to call editors the main actors and views the supporting actors.

For some Eclipse based RCP applications this assumption doesn't hold. Views can be the "main actors", too. Our RCP app uses Eclipse's themes and these recent changes make everything grey and homogeneous (I've forked the theme plug-in so I can avoid these changes).

Grey backgrounds in Tabbed Properties Views (based on FormToolkit) look wrong - grey controls on grey parent composites doesn't work. Some controls are white, some grey. A Text control is white on a grey background whereas a StyledText control is grey on a grey background and looks like it's disabled. As it stands now it's inconsistent. So this grey background for all controls doesn't work if there is a mix of different controls in a view.

Edit - I opened a separate issue - #2173

Thanks for the feedback Phil.
So, what is the best way to handle this issue? How do we decide which views/controls must be grey or white? As we wanted to have the console view grey, I set the background of StyledText to grey, but that has changed the background color of the description field in the properties view as both use the same control.

[humphreygao]

why should we make some view grey? I think pure white is great.

[BeckerWdf]

why should we make some view grey? I think pure white is great.

Pls. see what @thomasritter wrote above:

When comparing the different IDEs it is easy to pick out the design decisions they all share. These are:

1. Lightweight view tab design.
2. Flat look. No use of 3D gradiants.
3. Views use a darker background color. This naturally focuses the eye on the editor area which is where most of the work happens. We like to call editors the main actors and views the supporting actors.

Especially, point 3) is important. When looking at other UIs outside the IDE space it becomes clear that this is the standard. The navigation sidebar is usually using a darker background color than the main content area (e.g. MacOS finder, Apple Music, Powerpoint, OneNote, MacOS notes, MS teams, ...). That's probably the biggest reason why Eclipse feels so outdated.

[Phillipus]

So, what is the best way to handle this issue? How do we decide which views/controls must be grey or white?

@mvm-sap Right now I don't know what the best solution is. But I think there's a big difference between the aim ("This view's controls have a grey background") and the broader implementation ("All view's controls have a grey background").

I can think of cases where this would be undesirable. and, also, not consistent - for example form-based controls as used in Manifest/Product editors are white because they are EditorParts but grey when the same controls are in a ViewPart. In this case I'm not sure the end user would know why this is so given that they are both functionally "main actors".

Perhaps you can declare the theme CSS to apply the grey background to child controls in a desired view rather than all views. Is that possible?

Do you think these theme changes should be made in a new experimental theme rather than the existing theme (same goes for dark theme) to get user feedback?

[mvm-sap]

Perhaps you can declare the theme CSS to apply the grey background to child controls in a desired view rather than all views. Is that possible?

Yes, we could do that with the help of CSS ID. But then we will not be able to implement that generically as we would not know all CSS ID from different plugins. Other alternative would be that each plugin should have their own CSS extensions and customize the background colors, this is just an idea, might be cumbersome to implement.

[mvm-sap]

PR has been created to fix issues w.r.t some of the grey background in views . #2181

[Phillipus]

Another change is swt-selected-highlight-top is true for EditParts but false for ViewParts. I find it a bit strange to see the blue highlight in two different places, top and bottom.

Also, before this change, only one Part in the Workbench had the selected highlight (swt-selected-tab-highlight), now each Part in a stack has the highlight so I'm seeing multiple highlighted parts and I don't know which one is active.

[BeckerWdf]

I find it a bit strange to see the blue highlight in two different places

Correct. This changed. This was done by intention.

[estepper]

I appreciate that you try to modernize Eclipse's look & feel for the many users that you've asked.

Personally I still prefer the traditional look & feel, the one that I've been using since decades. It would be wonderful if your new look & feel becomes a new theme. One that I can easily switch off in case you select to make it the default one. Thank you ;-)

[BeckerWdf]

I appreciate that you try to modernize Eclipse's look & feel for the many users that you've asked.

Personally I still prefer the traditional look & feel, the one that I've been using since decades. It would be wonderful if your new look & feel becomes a new theme. One that I can easily switch off in case you select to make it the default one. Thank you ;-)

Maintaining and testing themes in Eclipse is so hard, that we do not want to add new themes. Sorry.

[Phillipus]

Also, before this change, only one Part in the Workbench had the selected highlight (swt-selected-tab-highlight), now each Part in a stack has the highlight so I'm seeing multiple highlighted parts and I don't know which one is active.

I find it a bit strange to see the blue highlight in two different places

Correct. This changed. This was done by intention.

As there can only be one active Part in the workbench at any time isn't the purpose of having one global swt-selected-tab-highlight to show that one selected Part? Having multiple highlights defeats that purpose.

[vogella]

@mvm-sap and @BeckerWdf maybe use another colour like gray as underline for the non active selected element?

[HannesWell]

First of all thank you @mvm-sap, @thomasritter and @BeckerWdf for modernizing the Eclipse UI theming. I really appreciate your work on this in general and all the fixes you provided in the recent past and I'm convinced that it is for the better of Eclipse.

But I'm not sure if the modernized (light) theming is ready to be the only one without any safety net. I therefore brought this topic up at today's developer call. @sratz and @soethoff already explained that maintaining multiple dark themes would be too much work, but that more than one light theme would be in general doable.
Therefore we decided to create a (non-binding) poll to gather feedback on how we should continue with the integration of the new theming and if and in which form the old light-theming should be preserved.
Everyone interested, please express your opinion at:

• Integration of the modernized theming for the Eclipse UI #2199

[garydgregory]

FWIW, the new tabs are awful for me, it's harder to tell which one is selected. Baffling IMO.

[ingomohr]

Thank you for the update! I like to see the gradients go away from the tabs on the light theme. (I had only added those because I wasn't able back then to have an empty part's background match the tab color.)

[jukzi]

In the current state this theming seems to have too many defects which can probably not be solved in-time before release. Therefore i suggest to not have it by default yet. It needs to be far better tested in all views and give other plugins a fair amount of time to adapt so it should only be made default in an M1. It should also not be named "modern" but "focused" theme - in some future it will not be modern anymore.

[vogella]

I still think the new themes are looking great.

[BeckerWdf]

As there can only be one active Part in the workbench at any time isn't the purpose of having one global swt-selected-tab-highlight to show that one selected Part? Having multiple highlights defeats that purpose.

This is addressed in #2286

[BeckerWdf]

For some Eclipse based RCP applications this assumption doesn't hold. Views can be the "main actors", too. Our RCP app uses Eclipse's themes and these recent changes make everything grey and homogeneous (I've forked the theme plug-in so I can avoid these changes).

From my point of view the themes provided be Eclipse Platform are made for IDE use-cases and we now optimise them for these use-cases. If RCP applications don't use the editor area or their "main actors" are views this is a different story. There the requirements are different. If the platform themes are fitting for RCP apps this is fine and they can be used but if the platform themes are not fitting (e.g. because in your domain for some reasons all views have to have green background or whatever) then I propose to exactly do what you did: provide your own application specific theme(s).

We can also discuss this on that topic via Zoom in Hannes's next community call on 26th of September at 4 pm CET.
I also invite everybody from the community interested in that topic to also join this call.