Expose Expand All icon through ISharedImages API

[deepika-u]

This change exposes the existing Expand All toolbar icon through the shared workbench image API, similar to the already available Collapse All image.

Currently, collapseall is accessible via ISharedImages, while expandall requires bundle-specific image loading or direct resource access. This leads to duplicated image handling and inconsistent usage across the workbench.

This PR:

• Adds shared image constants and registrations for the existing expandall icon
• Makes the icon accessible through PlatformUI.getWorkbench().getSharedImages()
• Aligns Expand All usage with the existing Collapse All API pattern
• Avoids fragile programmatic bundle resource lookups in downstream consumers

The intent is to provide a reusable, centralized API for any component that needs standard Expand All toolbar imagery.

This arises from #3968 (comment)

[deepika-u]

@BeckerWdf : Can you take a look at it when you get some time please?

[merks]

I think you removed a registration and you changes an @SInCE for something you didn't add.

[merks]

Given your comments, the changes look good!

[github-actions]

Test Results

   858 files  ±0     858 suites  ±0   57m 39s ⏱️ -8s
 7 977 tests ±0   7 734 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 433 runs  ±0  19 778 ✅ ±0  655 💤 ±0  0 ❌ ±0 

Results for commit f698aba. ± Comparison against base commit e85df0e.

♻️ This comment has been updated with latest results.

[merks]

Thank you!

[deepika-u]

Thanks for your time :)

[deepika-u]

I am still confused in 1 context which is again conveyed by the UT failures,

Here should it be not 3.5 or 4.0 and where from this 5 ideally routes from? And not 3.139(this comes from plugin.xml i agree) in this file. Hope i am still not too late. Sorry to ask but still.

[merks]

Sorry, sorry. The API tools are really fussy and consider an addition a constant to an API class or interface an API breaking change. But we don't want that so each of them needs to be suppressed, preferably with a commented suppression All the new added things (public constants) should be marked @since 3.139 including the thing Lars added.

Do you see these errors in your IDE? That's the best place to added the suppression via quick fixes.

I do see this one (after some refreshing and forced builds):

I guess asking you to remove the filter was bad advice. Sorry. 😢

[merks]

I'm not a big API tools expert. I'm not sure if both of these are needed

    <resource path="META-INF/MANIFEST.MF">
        <filter comment="See https://github.com/eclipse-platform/eclipse.platform.ui/pull/3981" id="923795461">
            <message_arguments>
                <message_argument value="3.139.0"/>
                <message_argument value="3.138.0"/>
            </message_arguments>
        </filter>
    </resource>
    <resource path="eclipseui/org/eclipse/ui/dialogs/FilteredItemsSelectionDialog.java" type="org.eclipse.ui.dialogs.FilteredItemsSelectionDialog">
        <filter comment="See https://github.com/eclipse-platform/eclipse.platform.ui/pull/3981" id="336658481">
            <message_arguments>
                <message_argument value="org.eclipse.ui.dialogs.FilteredItemsSelectionDialog"/>
                <message_argument value="JOB_FAMILY"/>
            </message_arguments>
        </filter>
    </resource>

[merks]

I think this one is sufficient:

[deepika-u]

I think this one is sufficient:

Reverted this change. Let me see the UT how it goes.

[merks]

Sorry we are all strapped for time and then give advice simply by looking at a web page which doesn't always tell the whole story. But I'm glad you are doing this in the best way for future flexibility! 🏆

[deepika-u]

Sorry we are all strapped for time and then give advice simply by looking at a web page which doesn't always tell the whole story. But I'm glad you are doing this in the best way for future flexibility! 🏆

Thanks for the encouragement! I agree that the full context isn’t always obvious from a quick look, so I’m trying to optimize for future flexibility and fewer constraints later on.

[akurtakov]

Fastest path forward IMO is having separate/dedicated PRs that do the cleanups (e.g. remove the duplicated initialization, fix apitools, etc.) . These can get merged fast/unquestioned making the later PR easier to review.

[deepika-u]

Hope we are good to go to merge this pr, thanks for all the inputs from everyone :)