Add duplicate icons that were already created

[Michael5601]

Fixes #192.
Fixes #191.
Fixes #190.
Fixes #189.
Fixes #188.
Fixes #187.
Fixes #186.
Fixes #185.
Fixes #184.
Fixes #183.
Fixes #182.
Fixes #181.
Fixes #180.
Fixes #179.
Fixes #178.
Fixes #177.
Fixes #176.
Fixes #175.
Fixes #174.
Fixes #173.
Fixes #172.

[laeubi]

Add duplicate icons that were already created

Instead of adding duplicates, one might want to use links instead: https://stackoverflow.com/questions/954560/how-does-git-handle-symbolic-links

[merks]

It's probably not idea to assume that works well on Windows...

[laeubi]

It's probably not idea to assume that works well on Windows...

See https://stackoverflow.com/questions/5917249/git-symbolic-links-in-windows

Its a litte more setup, but we already require some special setup for SWT git-lfs as well, given that this repo is not being used by much developers it seems better than to repeat the C&P style of previous days.

If that's not sufficient enough, I would propose to do it at least automatic by a (maven build) script on demand during the build instead of polluting the repository.

I think I suggested it already earlier that a more semantic structure for icons would be much better... it then can be copied to whatever structure we want later on.

[BeckerWdf]

@Michael5601: Should I merge these? Should I or @jasmin261098 do a detailed review on them?

[laeubi]

@Michael5601: Should I merge these? Should I or @jasmin261098 do a detailed review on them?

See above, I don't think this is a useful pattern, it makes the whole thing completely unmanageable.

[Michael5601]

It's probably not idea to assume that works well on Windows...

See https://stackoverflow.com/questions/5917249/git-symbolic-links-in-windows

Its a litte more setup, but we already require some special setup for SWT git-lfs as well, given that this repo is not being used by much developers it seems better than to repeat the C&P style of previous days.

If that's not sufficient enough, I would propose to do it at least automatic by a (maven build) script on demand during the build instead of polluting the repository.

I think I suggested it already earlier that a more semantic structure for icons would be much better... it then can be copied to whatever structure we want later on.

I don't quite see the benefits of your proposal yet. Maybe I do not understand it fully yet. I am open to change if you want to elaborate it more.

The folder in which all dual tone icons will be saved resembles the exact location of every icon in all eclipse repositories. Why should this be less manageable than the repositories itself? This approach might be the naive solution but it is also very simple, makes sure we don't forget any icons, gives us the ability to view the progress of the project, allows simple refactoring of any existing icons (also programatically e.g. changing colors) and makes migration of the icons to eclipse itself later on very easy. The last point is especially important for demonstration purposes as this project may take a while.

Your proposal adds complexity and is also the wrong end to begin with in my opinion. I would rather have improvements in the duplicate icon situation in eclipse itself than on this dual tone icon project.

[Michael5601]

@Michael5601: Should I merge these? Should I or @jasmin261098 do a detailed review on them?

If the concerns of @laeubi are settled we can merge in my opinion. I only added all icons, we already designed to the specific locations where their duplicates lie in eclipse.

[Michael5601]

@Michael5601: Should I merge these? Should I or @jasmin261098 do a detailed review on them?

If the concerns of @laeubi are settled we can merge in my opinion. I only added all icons, we already designed to the specific locations where their duplicates lie in eclipse. So no need to review, if I made any errors, they will be found later on, when we update the progess of the project: #151

[laeubi]

The folder in which all dual tone icons will be saved resembles the exact location of every icon in all eclipse repositories. Why should this be less manageable than the repositories itself?

You raise a valid point about the current state of Eclipse repositories. Indeed, icon management there is already problematic (as evidenced by recent confusion with duplicate and forgotten updates to Eclipse Feature icons). However, this doesn't mean we should replicate those problems here - instead, this is an opportunity to establish better practices.

I would rather have improvements in the duplicate icon situation in eclipse itself than on this dual tone icon project.

I agree that platform improvements are needed. However, if we simply replicate the existing structure here without addressing the duplication issue, we risk perpetuating the problem indefinitely. The platform improvements and this icon pack development can happen in parallel.

Your proposal adds complexity and is also the wrong end to begin with in my opinion.

I understand your perspective on complexity. Let me clarify what I see as the trade-offs:

Current approach (direct copying):

• ✅ Simple initial implementation
• ❌ Difficult to identify which icons are true duplicates vs. intentionally similar
• ❌ Cryptic naming conventions that don't reveal purpose
• ❌ Tight coupling to repository structure (any reorganization requires changes here)
• ❌ Maintenance burden grows with each icon pack variant

Proposed semantic approach:
I envision a two-step process that would actually reduce long-term complexity:

1. Semantic Icon Library: Define icons with meaningful names and clear purposes

   - add.svg         → Used for adding items to lists/tables
   - remove.svg      → Used for removing items from lists/tables  
   - delete.svg      → Used for permanent deletion operations
   - create-new.svg  → Used for creating new entities (files, classes, etc.)
   

   This would be documented in the style guide with clear usage guidelines.

2. Mapping Configuration: A simple mapping file (e.g., icon-mappings.txt) that defines where each semantic icon should be placed:

   add.svg → platform. ui/icons/full/elcl16/add_obj.svg
   add.svg → platform.ui/icons/full/etool16/add_task.svg  # reuse for consistency
   create-new.svg → jdt.ui/icons/full/wizban/newclass_wiz.svg
   

Benefits of this approach:

• Changes to repository structure only require updating the mapping file
• Easy to generate icon pack JARs programmatically
• Developers can create custom icon packs by providing alternative icons with the same semantic names
• Clear documentation of which icons are intentionally duplicated
• Reduced file duplication in this repository

I hope it is now a bit more clear, and I don't want to block the development but currently this does not feel to go in the right direction if we talk about developing "icon packs" in the future.

[Michael5601]

I hope it is now a bit more clear, and I don't want to block the development but currently this does not feel to go in the right direction if we talk about developing "icon packs" in the future.

Thank you for your detailed clarification. I can see your concerns way clearer now and I agree that the trade-offs are technical debt we should avoid in this early stage of the development. I did not have these points in mind before.

I still have some concerns regarding the mapping file and semantic icon library:

1. You propose to save icons in this dual tone icon pack with a broader semantic name, so they can be used in different locations mapped in the configuration file. I think the naming will be hard for items with a similar use case that should still be handeled differently. One example for this can be found in the "next_nav" icons as mentioned in this comment. The one icon is used for navigation inside one file and the other one for navigation between files. The semantic names would quickly get very specific.
2. Most icons only have one usage and no duplicates, which means one entry in the semantic icon library would have only one entry in the mapping configuration for most icons. Is the new semantic name of these icons equal to their old name?
3. New overhead is added because we need to maintain the semantic icon library and the mapping configuration. They also will be quite large because of my concern no. 2, which adds a new vector for duplicated entries.
4. The new metadata files also must be maintained and adapted if icon usage is changed in eclipse.
5. Right now it is very easy to copy all icons of a repository to eclipse and then demo how the new icons look in the UI. With the new approach all icons have potentially different semantic names and a different location. We need a script that transforms the icons according to the mapping configuration so they can be loaded to eclipse as long as we don't have a technical implementation of switching icon packs in the Eclipse UI settings.

Apart from my concerns I can see some advantages of your approach you did not mention yet:

1. I wonder if the technical implementation for switching icon packs in the eclipse UI settings (must be implemented later to use these icon packs) can be simplified by your approach as we can easily generate icon pack JARs.
2. Right now we look at each icon in the UI, find out what it is used for and then design the new icon for the dual tone icon pack. This information is lost afterwards and with your approach can be saved in the semantic icon library, which would be a huge time saving for future icon packs.

So from my point of view we gain the advantages you and I mentioned but increase the overhead and thus development time for creating the icon pack. It is hard for me to decide if we should follow your approach.

[laeubi]

@Michael5601 Thanks for sharing your concerns. Let me address each point:

1. Naming Complexity for Similar Use Cases

The naming will be hard for items with a similar use case that should still be handled differently

This is precisely why a semantic style guide is valuable. The "next_nav" example you mentioned (#149) actually illustrates the importance of clear semantic distinctions:

• navigate.within.file - for navigation inside one file
• navigate.between. files - for navigation between files

Yes, semantic names may become specific, but that's a feature, not a bug. Clear, specific names:

• Reduce ambiguity for developers
• Make icon usage self-documenting
• Prevent accidental misuse of similar-looking icons

2. 1:1 Mappings and Path Changes

Most icons only have one usage and no duplicates

While some icons may have 1:1 mappings initially, the semantic approach provides:

• Future-proofing: When we need variations or theming, the semantic layer makes this trivial
• Better organization: Moving from size-specific paths (elcl16, obj16) to semantic paths that work with SVGs
• Clear intent: Even 1:1 mappings benefit from documenting why an icon exists and what it represents

3. Maintenance Overhead

New overhead is added because we need to maintain the semantic icon library

The overhead already exists - it's just invisible and distributed:

Current (Hidden) Overhead:

• Find the right icon file
• Identify its purpose (often unclear from filename)
• Check for duplicates manually
• Hope nothing was missed
• Knowledge lost when contributors leave (bus factor)

Proposed (Visible) Overhead:

• Documented semantic mappings
• Version-controlled configuration
• Automated validation possible
• Knowledge preserved in the system

This isn't adding overhead - it's making existing overhead visible and manageable.

4. Traceability and Documentation

The new metadata files also must be maintained

Yes, but consider the benefits:

• Git history becomes meaningful: Changes to the mapping file clearly show icon usage evolution
• Review process improved: PRs can clearly show "we're changing icon X from Y to Z because..."
• Onboarding simplified: New contributors can understand the icon system without tribal knowledge

5. Development Workflow

Right now it is very easy to copy all icons of a repository to eclipse

Manual copying seems easy but:

• Error-prone (miss files, wrong locations)
• Not reproducible
• Time-consuming when done repeatedly
• No validation

An automated script (one-time setup cost) provides:

• Consistent results every time
• Validation of mappings
• Batch updates across multiple repositories
• Can be integrated into CI/CD

Moving Forward

I strongly believe the initial setup investment will pay dividends. With modern AI tools, we can:

1. Auto-generate initial mappings from existing icon usage
2. Identify duplicates automatically
3. Create the initial semantic taxonomy based on actual usage patterns
4. Generate migration scripts for existing codebases

This isn't just about organizing icons - it's about creating a sustainable, maintainable icon system that scales with Eclipse's needs. The alternative is continuing with the current ad-hoc approach, which will only become more difficult to manage as the icon set grows.

I could offer to help create a proof-of-concept showing how this could work with a subset of icons, I myself using a generator script in my application (where the script is actually some java code) that currently also includes the conversion from SVG>PNG (hopefully soon obsolete) and believe automation is simply a key in that area.

[Michael5601]

@BeckerWdf what do you think?

[azoitl]

I do not know how the implementation plan for the icon packs on the platform side is planned. But we at Eclipse 4diac have an approach with enum and an fragment bundle with the icons and .properties file where the mapping is done. This approach is based on a very nice article presented in the Eclipse magazine in the early 2010s.

We have it now about 10 years and it helped us a lot to have a) different icon sets and b) change icons and icon locations without any change in the code. However I guess the enum based approach is a bit to rigid for the platform. But as part of this implementation there is also an own icon url for plugin.xml and I think this is the real power behind it.

[BeckerWdf]

I do not know how the implementation plan for the icon packs on the platform side is planned. But we at Eclipse 4diac have an approach with enum and an fragment bundle with the icons and .properties file where the mapping is done. This approach is based on a very nice article presented in the Eclipse magazine in the early 2010s.

We have it now about 10 years and it helped us a lot to have a) different icon sets and b) change icons and icon locations without any change in the code. However I guess the enum based approach is a bit to rigid for the platform. But as part of this implementation there is also an own icon url for plugin.xml and I think this is the real power behind it.

Can you explain that in a bit more details?

[azoitl]

Can you explain that in a bit more details?

Sure. I tried to find the original Eclipse Magazine article, but somehow I either lost it or just mix stuff up.

But I can explain how we implemented the concept in 4diac IDE.

The core part are three classes:

• enum FordiacImage: This enum is used for using images from the code. For each Image we have one enum entry. The enum entry name is used as key to find the according image. In the properties files (see below) we map this key to the respective image to be used.
• FordiacImageURLStreamHandlerService: This service registers an own protocol. In our case fordiacimage
• FordiacImageURLConnection: handles the image resolving provision by looking it up in the enum

The images themselves are provided by a fragment bundle which provides the fordiacimages.properties: https://github.com/eclipse-4diac/4diac-ide/tree/develop/plugins/org.eclipse.fordiac.ide.images

With this infrastructure you write in Java code:
FordiacImage.ICON_BASIC_FB.getImage()
or
FordiacImage.ICON_BASIC_FB.getImageDescriptor()

And in a plugin.xml:
image="fordiacimage://ICON_SERVICE"

The great advantage for us as RCP is that we have one single place for all of our icons and one could easily provide a different set of icons by providing a different fragment bundle. Before that we also had the problem that we had icons doubled. Different icons for the same thing.

The drawback is this approach is that in its current implementation it is rather rigid. All icons have to be in one single enum. This works good for us as RCP but for the Platform a more extensible approach would be needed. What I definitely see for the platform is the own URL as this allows to decouple icon file location from icon usage in plugin.xmls, and E4 models.

[BeckerWdf]

@BeckerWdf what do you think?

@laeubi has a point here. So maybe could fix a part of the problem here in the icon pack without the need to touch the "productive" bundles.
What about the following:

1. Create the SVG without duplicate
2. Store them all in one folder with a semantic file name. And as they all reside in the same folder their names have to be unique.
3. Providing a mapping for each icon pack e.g. in some kind of central text file that maps old files usage to the new unique semantic name. The old file usage needs to be given as the complete path from plugin name down to the file name (as only this is unique).

With this we would not duplicate files and with the mapping file we still can automate the exchange from old to new files.
The only issue: If we clean up file usages in the productive bundles we also need to clean up up the mapping file.

[Michael5601]

With this we would not duplicate files and with the mapping file we still can automate the exchange from old to new files. The only issue: If we clean up file usages in the productive bundles we also need to clean up up the mapping file.

I agree on the proposal of @laeubi and the workflow steps you provided. On the weekend I will propose a PR that adresses this, then we can further refine this approach.

[Michael5601]

I agree on the proposal of @laeubi and the workflow steps you provided. On the weekend I will propose a PR that adresses this, then we can further refine this approach.

I proposed the PR now as announced last week. I will close this PR now, so please use the new PR for further discussion.