Add constructor to ImageDescriptor for simple creation based on the bundle

[vogella]

To construct an ImageDescriptor from the same plug-in I have to write a lot of code. Example;:

ResourceManager resourceManager = new LocalResourceManager(JFaceResources.getResources(),
					goToLocationButton);
			Bundle bundle = FrameworkUtil.getBundle(getClass());
			URL goToFolderUrl = FileLocator.find(bundle, IPath.fromOSString("icons/full/obj16/goto_input.png"), //$NON-NLS-1$
					null);
			goToLocationButton.setImage(resourceManager.create(ImageDescriptor.createFromURL(goToFolderUrl)));

Could we add a constructor for this (relatively) frequent use case? Or do we already have easier API and I just didn't notice?

[vogella]

Adding @HannesWell as he has driven lots of API simplifications in the past.

[laeubi]

@vogella why using the bundle/FileLocator here?

You can simply use getClass().getResource("/icons/full/obj16/goto_input.png")

[laeubi]

@vogella there is even a convenience method already:

org.eclipse.jface.resource.ImageDescriptor.createFromFile(Class<?>, String)

[vogella]

@laeubi I use Github search and used the first fitting entry https://github.com/search?q=repo%3Aeclipse-platform%2Feclipse.platform.ui%20resourceManager.create&type=code I will try to simplify ResourceInfoPage.java so that next time, I can copy and paste this code. :-)

[laeubi]

I use Github search and used the first fitting entry

Sadly Platform itsel do not always serve as the best (modern) example so its never bad to look at the class used itself :-)

[vogella]

I use Github search and used the first fitting entry

Sadly Platform itsel do not always serve as the best (modern) example so its never bad to look at the class used itself :-)

:-) Or once we note, we just update the platform code.... I will try to do this for this use case.

[vogella]

Thanks @laeubi for the reminder

[HannesWell]

@vogella there is even a convenience method already:

org.eclipse.jface.resource.ImageDescriptor.createFromFile(Class<?>, String)

We could consider to add another overload that detemines the caller class using StackWalker?

Sadly Platform itsel do not always serve as the best (modern) example so its never bad to look at the class used itself :-)

Indeed, but that applies to almost all TLPs and various API. A lot to clean up. :)

[vogella]

We could consider to add another overload that detemines the caller class using StackWalker?

No, I think the existing method is easy enough to use.

[vogella]

ImageDescriptor.createFromFile would search relative from the provided class file. Should be maybe add a createFromBundle which allows to use the top-level directory?

[ptziegler]

ImageDescriptor.createFromFile would search relative from the provided class file. Should be maybe add a createFromBundle which allows to use the top-level directory?

+1

In WindowBuilder, we already ran into this limitation, which is why partially the reason, we had to create our "own" ResourceManager. Having a dedicated method for this would clean up a lot of boilerplate code.

Four our use case, having a method like this would already help a lot: createFromBundle(String symbolicName, String path)

But I assume variations using a Bundle or Class would also work.

[ptziegler]

I recently worked on a similar problem again and noticed that this functionality is already provided by the ResourceLocator, which provides the following methods:

• imageDescriptorFromBundle(String bundleSymbolicName, String imageFilePath)
• imageDescriptorFromBundle(Class<?> classFromBundle, String imageFilePath)

I only stumbled upon them by accident, so they are easy to miss. Perhaps it makes sense to simply move them to the ImageDescriptor class?

[HannesWell]

* `imageDescriptorFromBundle(String bundleSymbolicName, String imageFilePath)`

* `imageDescriptorFromBundle(Class<?> classFromBundle, String imageFilePath)`

I only stumbled upon them by accident, so they are easy to miss. Perhaps it makes sense to simply move them to the ImageDescriptor class?

Adding the same to ImageDescriptor and referencing ResourceLocator sounds reasonable. Nevertheless it would be interesting to look at the change that introduced them only in ResourceLocator. Mabye there was a reason not ot add it to ImageDescriptor as well (although I don't see one atm.)?

[HannesWell]

there is even a convenience method already:

org.eclipse.jface.resource.ImageDescriptor.createFromFile(Class<?>, String)

Actually there is already such method as it was mentioned above.

[ptziegler]

there is even a convenience method already: org.eclipse.jface.resource.ImageDescriptor.createFromFile(Class<?>, String)

Actually there is already such method as it was mentioned above.

Those methods are not interchangable. In createFromFile the file is relative to the class, while in imageDescriptorFromBundle the file is relative to the bundle root.

Example: ImageDescriptor.createFromFile(IDE.class, "icons/full/obj16/error_tsk.png"); -> platform:/plugin/org.eclipse.ui.ide/org/eclipse/ui/ide/icons/full/obj16/error_tsk.png ResourceLocator.imageDescriptorFromBundle(IDE.class, "icons/full/obj16/error_tsk.png"); -> platform:/plugin/org.eclipse.ui.ide/icons/full/obj16/error_tsk.png

[laeubi]

Example: ImageDescriptor.createFromFile(IDE.class, "icons/full/obj16/error_tsk.png"); -> platform:/plugin/org.eclipse.ui.ide/org/eclipse/ui/ide/icons/full/obj16/error_tsk.png

have you tried ImageDescriptor.createFromFile(IDE.class, "/icons/full/obj16/error_tsk.png"); just currious, I'm asking specifically as usually I always use ImageDescriptor.createFromURL(MyClass.class.getResource(<either relative or absolute) as mentioned above so I never "missed" that directly, but of course one can maybe make it more convenient and then have a method like createAbsoloute / createRelative ....

[ptziegler]

have you tried ImageDescriptor.createFromFile(IDE.class, "/icons/full/obj16/error_tsk.png"); just currious

Color me impressed. I didn't expect it to work, so I take back my previous comment.

In that case, the use most likely can already switch between absolute an relative path, depending on whether the path starts with a slash.