Support for "Icon Packs" in Eclipse Platform and Eclipse IDE Products

[BeckerWdf]

Scope Of This Discussion

Since quite some time there is the wish to support alternative icons in Eclipse Platform / Eclipse IDE Products.
See for example #13

"Icon Packs" can cater multiple use cases. This post tries to list these use cases and to rank them. This post is the shared understanding of the Vector (especially @fedejeanne and @HeikoKlare and SAP community members (especially @BeckerWdf, @sratz and @thomasritter). This should start a discussion with the whole community about this topic. The discussion should address the "what" (what to achieve) of the "Icon Pack" topic. Details of the "how" (how to technically implement this and how this looks from the user's point-of-view) should follow later.

Use Cases

Use Case 1: Deliver a Whole Product With Custom Styling

A company delivers a complete product that is based on the Eclipse (RCP) Platform. This product has nothing to do with Eclipse itself except for the fact that it is based on the Eclipse (RCP) Platform. The company wants their product to comply to a application specific styling.

Example

The ACME (A Company Modelling Everything) company builds an RCP application for modelling products. It uses the Eclipse Platform and SWT as the technology to build that product. This product is not anything similar to an IDE.

Characteristics

• The provider of that product has complete control over which bundles and features are included in that product.
• There is only a small(er) amount of icons to deliver for own bundles.
• There is no need to wait for other bundles to deliver appropriate icons, every icon can be created by the same team.
• The provider of that product needs to replace icons from Eclipse (RCP) Platform with icons that follow a custom styling.

Use Case 2: Extend Existing Product and Contribute Icons to an Icon Pack of That Product

A company extends an existing product that is based on the Eclipse (RCP) Platform. This is for example the case when one delivers extensions to the Eclipse IDE. In this case, the product is the Eclipse IDE. The company want's to contribute icons to an icon pack that is defined by the extended product.

Example

Eclipse Platform defines an icon pack called "Monochrome Flat". The Eclipse Platform bundles provide icons for this icon pack. Bundles from other Eclipse SimRel projects (e.g. JDT, CDT, ...) also contribute icons for this icon pack. A Company provides their own set of bundles to provide IDE support for their proprietary programming language and also want to contribute icons of Eclipse Platform's "Monochrome Flat" icon pack.

Characteristics

• The provider of the extension has control only over a limited set of bundles and feature in the product.
• There's a large amount of icons, scattered through several bundles (and possibly several teams).

Potential Issues

• There might be some bundles that don't provide icons for a given icon pack which means that the product may end up having a mixture of differently looking (3D-ish colorful vs- flat monochrome) icons.

Use Case 3: Provide Community Icon Pack

A freelance developer wants to define her own icon pack for a product she even does not provide or extend.
This use case is some kind of mixture of use case 1.

Example

A developer loves the Eclipse IDE but does not like the Eclipse default icons and also not the icon packs provided by the Eclipse IDE. Instead she wants to have 3D-ish monochrome icons in shades of purple.

Characteristics

• The developer of the icon pack has no control over which bundled and feature are included in the product.
• There are no "own" icons to deliver.
• There is no existing icon pack available to extend.
• The developer of the icon pack needs to define an own icon pack.
• The developer of the icon pack needs to replace icons of "foreign" bundles.

Ranking of Requirements

We see use use case 1 and use case 2 as the most important ones. Use case 3 seems not so important but should be possible anyway. But use case 3 should not add much complexity for the solutions for use use case 1 and use case 2.

Requirements For All Use Cases

• For use case 1 it might be no need for the user to have a possibility to change icon packs. But it might be that someone wants to deploy multiple icon packs for a complete RCP product that are interchangeable. So this possibility could be a desirable optional extension of this use case.
• For use case 2 and use case 3 the icons should be exchangeable at runtime. Best case would be without the need for a restart but a restart would also be ok.
• It should be possible to exchange the icons independently of the UI-Theme (CSS Theme).

Technical Considerations

Even though this document should only collect requirements but don't provide too much technical / implementation details this chapter lists some of them.

It should be possible to choose if the (replacement) icons will be delivered in bundles or in fragments.

Use case 1 seems to be already addressed by eclipse-equinox/equinox#732 and eclipse-equinox/equinox#731. See the example provided by #2686.

For Use case 2 and Use case 3 we still have to think of implementation ideas.

Outside Of The Scope of Icon Packs

Related Requirements

These are requirements that are related to the topic icons but are independent from the implementation of the icon pack use cases.
They should not be a prerequisite for icon packs and should be handled and implemented separately.

• Icons should be able to adapt to the current UI theme (Light/Dark).

  • There shouldn't be "light" and "dark" icon packs. Instead, the designer should be able to deliver more than one version of the same icon. A technical possibility to distinguish between them could be by the name of the file or by a segment in the file path e.g.
    • folder_icon.png is for the "light" UI theme and may be used for the "dark" UI theme too.
    • folder_icon_dark.png is for the "dark" theme and, if present, will be used instead of folder_icon.png when the UI theme is "dark".

• Sharing of frequently used icons between bundles should be possible.

  • Without the need of copying files.
  • Providing bundle should have a possibility to explicitly state for which icons this sharing should be possible (explicitly making it part of the API). Today sharing is possible e.g. via platform:/ uris but the API-aspect of it is missing

• Style of alternative icons (See: Refinement of the new modern icon style eclipse.platform.images#117)

• Possibility to use SVG natively in SWT for icons.

[laeubi]

For Use case 2 and Use case 3 we still have to think of implementation ideas.

I'm not completely sure why case 2+3 should not be possible with what we have for case 1 and how case 2+3 actually differ?

I also missing a bit the question or what to exactly discuss here even though it gives a good overview about different aspects of the topic.

From my point of view it would be most suitable to enhance the example documentation here:

https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/examples/org.eclipse.ui.examples.iconpack/README.MD

with new aspects and or demonstrate missing features with real code example (maybe more examples).