eclipse-platform / eclipse.platform.ui

Eclipse Platform
https://projects.eclipse.org/projects/eclipse.platform
Eclipse Public License 2.0
78 stars 163 forks source link

UI refresh: a modern light and dark theme #2114

Open thomasritter opened 1 month ago

thomasritter commented 1 month ago

Known issues

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

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 image

IntelliJ image

Visual Studio image

XCode image

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: image

Modernized theme: image

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

image image

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.

image image

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. image

Current theme: image

Modernized theme: dark_theme_java

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:

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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. image
thomasritter commented 1 month ago

@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 commented 1 month ago

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

HeikoKlare commented 1 month ago

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 🙂

image

vogella commented 1 month ago

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:

image

image

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 commented 1 month ago

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

vogella commented 1 month ago

https://github.com/eclipse-platform/eclipse.platform.ui/pull/2112 and https://github.com/eclipse-platform/eclipse.platform.ui/pull/2103 merged

vogella commented 1 month ago

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 commented 1 month ago

cc @PyvesB

PyvesB commented 1 month ago

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 commented 1 month ago

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:

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 commented 1 month ago

grafik 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 commented 1 month ago

grafik 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 commented 1 month ago

grafik

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

laeubi commented 1 month ago

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 commented 1 month ago

@laeubi thank you, this might be helpful! I have created a PR here, I believe it already addresses the issue quite well: https://github.com/eclipse-platform/eclipse.platform.ui/pull/2119 (What I want is not custom styling, what I want is adaptation to the target)

thomasritter commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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

vogella commented 1 month ago

Ubuntu sounds good to me

iloveeclipse commented 1 month ago

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

vogella commented 1 month ago

@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 commented 1 month ago

@vogella We are working on it. Will update you once it's done.

HannesWell commented 1 month ago

What I have noticed as well is that in Stacks of views all tabs (regardless of if they are active or not) now have the very same background color and at the least the active is not separated horizontally from the other ones anymore. One can only distinguish it from the other ones from the underlining:

grafik

HannesWell commented 1 month ago

@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.

Since you mentioned that it can be difficult to work on this I wanted to make you aware that from today in three weeks we have Milestone-3 for the upcoming autumn release. I think it would be good if the regressions are fixed until then. Fixing that only in the RC phase could become stressful since we then there is only little time to fix regressions from regression-fixes. :)

vogella commented 1 month ago

New light theme looks good to me:

image

The color for the selected tab in the new dark theme seem off with its blue text color.

image

mvm-sap commented 1 month ago

I'm currently working on the issue - Editor line number strip should have the same color as the editor background. (Dark -> Win, Mac)

BeckerWdf commented 1 month ago

I'm currently working on the issue - Editor line number strip should have the same color as the editor background. (Dark -> Win, Mac)

Great. Just push a PR once you have something ready...

vogella commented 1 month ago

I agree with @HannesWell that a small tab separator would be nice. https://github.com/eclipse-platform/eclipse.platform.ui/pull/2111#issuecomment-2261270341 Something very thin, like Xcode in the above screenshots.

thomasritter commented 1 month ago

@vogella just to be clear. With Xcode you mean this separator, correct?

image

I like the idea of something very minimal, too. Can such a shortened separator achieved with the current theme engine or will it require additional code?

vogella commented 1 month ago

an such a shortened separator achieved with current theme engine or will it require additional code?

I think it would require additional code (I did not check in detail in the code).

BeckerWdf commented 1 month ago

an such a shortened separator achieved with current theme engine or will it require additional code?

I think it would require additional code (I did not check in detail in the code).

Hi Lars, does https://github.com/eclipse-platform/eclipse.platform.ui/pull/2150 fulfil your requirement?

BeckerWdf commented 1 month ago

What I have noticed as well is that in Stacks of views all tabs (regardless of if they are active or not) now have the very same background color and at the least the active is not separated horizontally from the other ones anymore. One can only distinguish it from the other ones from the underlining:

grafik

Does https://github.com/eclipse-platform/eclipse.platform.ui/pull/2150 help here?

mvm-sap commented 1 month ago

grafik 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?

This would be addressed with this issue - https://github.com/eclipse-platform/eclipse.platform.ui/issues/2151

vogella commented 1 month ago

Maybe it is time to mark this issue as solved and have new issues for the remaining topics? They could be linked here.

BeckerWdf commented 1 month ago

Maybe it is time to mark this issue as solved and have new issues for the remaining topics? They could be linked here.

We use this as umbrella to collect issues and PR. I regularly update the initial post. So let’s keep it open.

Phillipus commented 1 month ago

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 - https://github.com/eclipse-platform/eclipse.platform.ui/issues/2173

mvm-sap commented 1 month ago

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 commented 1 month ago

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

BeckerWdf commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Phillipus commented 1 month ago

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 commented 1 month ago

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

Correct. This changed. This was done by intention.

estepper commented 1 month ago

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 commented 1 month ago

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.