Community Poll: Modern Icon-Pack Style for Eclipse

[Michael5601]

The following icon styles created by @IamLRBA and @Michael5601 are part of a new initiative for a new modern icon-pack for Eclipse.
Your feedback will help decide which style will be chosen for the icon-pack.

Please vote for the styles that you like the most and think will work best for Eclipse.

How to Participate:

• At the bottom of the poll, you can vote for your favorite style.
• The background colors represent Eclipse’s light and dark themes, allowing you to evaluate the icons in their intended environments.
• Remember, this poll is about choosing an icon style, not the specific icons themselves. If you like a style but dislike a particular icon, you should still vote for the style since these designs are prototypes.
• The style with the most votes will be discussed further within the community and will serve as the foundation for a new style guide.
• For comparison, the poll also includes the current icons used in Eclipse. If you prefer the original style, feel free to vote for it as well.

Thank you for participating!

Number	style	Light 64x64px	Light 32x32px	Light 16x16px	Dark 64x64px	Dark 32x32px	Dark 16x16px
0	Original
1	Mono
2	Dual-Tone
3	Outline 1
4	One-Line
5	Outline 2
6	Solid
7	Abstract

[Claudio140]

For the outlined icons it might make sense to add colors to some of them, similar to how IntelliJ icons look:


I don't think it would be well readable if all of them were gray, especially if there are many icons close to each other like in a toolbar.

Additionally, if all icons were gray, I can't really imagine how one would easily distinguish active from disabled icon buttons.

[Michael5601]

Thank you for the feedback. The screenshot you provided also supports a disabled icon, so I don't see a problem with supporting icon enablement with monochromatic icons.

[mickaelistria]

FWIW, it's not clear to me which ones are disabled with the screenshot above. This screenshot is IMO highlighting the issue more than diminishing it.

[Michael5601]

The one pause icon in the middle is disabled. All other icons are enabled from which some are colored.

[Claudio140]

For me this is more about visual context than about single disabled buttons. Imagine all the icons were grayscale, then I think it would be harder to tell them apart.

A disabled icon like the pause button next to other gray icons can still be readable, but it is easier if there is at least a colored icon next to the disabled on one side.
Of course, other visual guides like separators and grouping in general also help to quickly identify buttons at a glance.

[mickaelistria]

I also am worried about the impossibility to express icons enablement. Currently is colored for enabled vs grayscale for disabled. What's the proposed solution for enabled vs disabled here?

[Michael5601]

We had a discussion about this here and my argument is that other IDEs also have modern monochromatic icons while supporting icon enablement as seen here.

The idea would be that the disabled version of an icon is darker/brighter than the original.

[IamLRBA]

@Michael5601 Thank you for your guidance and also to the other community members thank you for the detailed discussions so far!. I’d like to suggest an approach that combines the strengths of both perspectives regarding icon distinction and readability:

1. Subtle Accent Colors: While maintaining a monochromatic or dual-tone theme, small accent colors could be used selectively to signify functionality or state (e.g., active/disabled, critical, or recommended actions).

I believe this should try and work with a suggestion of @Claudio140

For the outlined icons it might make sense to add colors to some of them, similar to how IntelliJ icons look: I don't think it would be well readable if all of them were gray, especially if there are many icons close to each other like in a toolbar.

These accents wouldn’t overwhelm the minimalist aesthetic (which is something i believe @Michael5601 is gunning for us to achieve) but could enhance visual clarity.

3. Alternative Visual Indicators: Alongside color differentiation for enablement states, we could also consider using subtle design tweaks like:
   • A slight opacity change or a dashed outline for disabled icons.
   • A glowing or shadow effect for active icons.

This was suggested by @Michael5601

The idea would be that the disabled version of an icon is darker/brighter than the original.

4. User Preferences: Could we offer a toggle for the community to switch between strictly monochrome icons and those with subtle accents? This might cater to a broader audience while preserving the modern aesthetic.

5. Prototypes for Testing: Before finalizing, it might be useful to test these ideas with a small focus group to ensure usability, especially in complex UIs like toolbars or dense menus.

Ultimately, I think the goal is to balance modern aesthetics with functional clarity. This way, the icons serve their purpose effectively without compromising on the design ethos.
Thank you all again!

[Michael5601]

Thank you for your input, @IamLRBA. The community poll provided some valuable insights, even though the results were quite balanced except for the dual-tone style. This highlights how subjective design preferences can be.

I apologize for my limited time right now, but I’ll try to push this project forward so we can finalize the style guide and implement a quality control plan that enables independent icon submissions. I really appreciate your support with this project. 😊

With the poll finished, we can now move to the next phase: refining the most suitable style. I’ll create a new issue to discuss this.

Here are my thoughts on the "winning" icon styles:

1. One-Line Style: It received more votes than expected, but its abstract style makes it difficult to design complex icons (e.g., editor window + pin). While interesting for this poll, I wouldn’t recommend it as a base for the new style guide.
2. Outline 1 Style: I heard many concerns about icon enablement. The small surface are of Outline 1 style makes disabled icons less distinguishable compared to Mono style. Mono, with its larger surface area, is better suited for this. I agree that the icon enablement is harder to provide for Outline 1 but I don't agree for Mono as the surface area is large.
3. Dual-Tone Style: This style received the most votes. A style like Mono (Dual-Tone is essentially Mono with more color), with features like round corners, large surface areas, and bold 2px lines, supports dual-tone designs and icon enablement.

That said, including the dual-tone style may have influenced the results. It’s unclear how many would have favored Mono without dual-tone as an option. However, since it aligns well with usability and dual-tone integration, I suggest focusing on refining Mono-style aspects. If anyone disagrees, please share your thoughts in the upcoming issue.

Also here is some feedback on your comment, @IamLRBA:

1. Subtle Accent Colors: This is hard to visualize without seeing what exactly you mean. For me the dual-tone style does what you described here. If you have an idea that we can consider implementing into the new style it would be great if you can provide simple sketches.
2. Alternative Indicators: On the technical side we are right now bound to only using color as indicator for icon-enablement. I am implementing a way to dynamically alter SVG at runtime which allows more automatic customization but if an Eclipse RCP product doesn't use SVGs this wouldn't work. Even though I like the idea of additional indicators there are some technical bounds to this right now.
3. User Preferences: This means either we design all icons in both variants which results in not only one icon pack but in two. Or we dynamically change the icons at runtime which is not trivial and will only properly work for SVGs. As we don't even have the technical base for icon theming yet I think we should avoid adding more requirements.
4. Prototypes for Testing: Testing icons in context before finalizing is a good idea. Once we’ve designed a few icons based on the new style, we can load them locally into Eclipse and share screenshots for evaluation. This feedback can refine the style guide further.

Thank you again for your suggestions and for supporting this project.

[Michael5601]

See this issue for further discussion.

[IamLRBA]

Thank you, @Michael5601, for your thoughtful and detailed response. I appreciate the time and effort you’re putting into this project despite your limited availability. 😊

Regarding your feedback on the suggestions I provided:

You’re right that maintaining multiple icon packs or dynamic runtime changes could complicate the implementation significantly. Perhaps, as a long-term vision, this idea could complement an eventual icon theming system. For now, prioritizing a single, robust style makes sense.
I’m glad to hear that testing icons in context is part of the plan. This will undoubtedly provide valuable feedback to refine the style guide further. I’m happy to participate in testing or contribute ideas to ensure the icons function well in real-world scenarios.

Lastly, I agree that the Mono/Dual-Tone styles are strong candidates due to their balance of modern aesthetics and functionality. Refining these styles, as you suggested, seems like the best path forward.

Thank you again for engaging with the feedback so thoughtfully. I look forward to seeing how the style evolves in the next phase!

[laeubi]

Please be aware that we have one very hard to takle problem to solve: Extensions ... and Eclipse heavily depends on them. So If Eclipse switches to whatever "style" it immediately will lead to a wild mixture of old/new styles. So who will take care to update all these as well? Another one is about custom RCP applications, or even supporting "older" Eclipse releases ...

[Michael5601]

This is part of the icon theming implementation. There is already a PR that was worked on 1.5 years ago. A few days ago the work on the PR started again. As far as I know the icon theming shall also work for all bundles/extensions.

The new style is planned as a new icon pack which can be optionally activated with the mentioned icon theming. This means custom RCP applications are not obligated to use the new style but they can if they want. Older Eclipse releases will just use the current default theme and won't have access to the new style.

Plugins from the market place that provide new custom icons are out of scope for this initiative. Providers of the plugins need to update their icons regarding the icon theming or users have to endure mixed icons.