Community
Participate
Working Groups
Created attachment 128193 [details] Patch on JFace I had the requirements to change the complete icon set by selecting the set in a preference page. After evaluating the possibility to play around with fragments and equinox transforms, I decided to patch JFace in order gain the wanted behavior. The patch involves an extension of the ImageDescriptor.createFromURL() method. The methods asks an OSGi Service called IImageLocationTransformer for transforming the URL to a new location before the ImageDescriptor is made. The service implementation can be registered by a custom plugin and have custom behavior. A disadvantage is that the client must be restarted in order the get the changes. But this would also be true with equinox transforms and fragments. I would like to provide the patch, if you think that it could be useful for the platform.
(In reply to comment #0) > Created an attachment (id=128193) [details] > Patch on JFace Would you mind respinning a new patch that doesn't include so many changes? I see a lot of lines that are being removed and subsequently added back because of whitespace changes and/or word wrapping effects.
Created attachment 128215 [details] Patch on JFace - Without formatting changes
New patch without formatting changes is uploaded. Which formatter settings are used in JFace? I formatted it with the built-in eclipse-formatter settings of Eclipse 3.4.1. Sorry for that.
(In reply to comment #3) > New patch without formatting changes is uploaded. Which formatter settings are > used in JFace? I formatted it with the built-in eclipse-formatter settings of > Eclipse 3.4.1. Sorry for that. No need to apologize. It's all kind of disorganized right now. We hope to resolve this with bug 258729.
See also bug 250432 and bug 246224, which is optional hooks supported in org.eclipse.ui.plugin.AbstractUIPlugin.imageDescriptorFromPlugin(String, String) PW
The Problem with org.eclipse.ui.plugin.AbstractUIPlugin.imageDescriptorFromPlugin(String, String) is, that it is not called for images declared by the commandImages extension point.
Good idea. This would have to be tested to work even when running JFace standalone (i.e. without OSGi). A simpler way to do this would be to expose API in Policy.java through which you can set the IImageLocationTransformer using a normal method call. Also, should we allow transforming the other ways of creating an ImageDescriptor as well?
An OSGi independent implementation is a good point. I did not mind about that, because we use JFace within a RCP Client. So the better way would be to set the IImageLocationTransformer by calling Policy.setIImageLocationTransformer() in my custom plugin, right? Or should Policy.getIImageLocationTransformer() checks an IImageLocationTransformer extension point? The problem with that would be that you can not know which IImageLocationTransformer is taken, when more than one custom plugin set or register own transformer. In the current solution you have some kind of control by setting the service priority. What about the idea to provide a transform() method in the Policy.java (?) which calls the IImageLocationTransfomer.transform() method of all registered transformers by extension points? So you would have a pipe of transformers which can react on the given path/url. Make this approach sense? As I see there is also a ImageDescriptor.createFromFile() method which should be involved in the transformation. Therefore the IImageLocationTransformer interface could be extended by transform(String path).
This is for RCP apps that would like to re-use existing views, toolbar items, etc but use different icons. Why would it be a problem to decide which transform to use? It's an RCP application, so you should know who is calling that method, and be able to make sure it only gets called once, presumably from your application class. To make it "safer", we could allow it to be set only once, preventing arbitrary plug-ins from overwriting it later. Using an extension point would not work for those people who just put the SWT and JFace jars on their class path but don't run it inside Equinox.
Ok. My suggestions were born because I have seen that the Policy class already imports eclipse specific classes (IStatus and Status). So it seems for me that JFace is at this place not really independent from the Eclipse RCP Platform. Further the JFaceUtil class imports more specific classes (Preferences). So the extension point check could happen in an IImageLocationTransformer implementation set by the JFaceUtil to the Policy class. The default state would be, that no transformer is set (for standalone swt/jface). But that are only some thoughts about that. I do not really have an insight view about the integration of JFace in RCP.
http://wiki.eclipse.org/JFace#Using_JFace_outside_the_Eclipse_platform
(In reply to comment #6) > The Problem with > org.eclipse.ui.plugin.AbstractUIPlugin.imageDescriptorFromPlugin(String, > String) > is, that it is not called for images declared by the commandImages extension > point. This is fixed in 3.5 PW
Hello, summaring the comments, the best way would be to remove OSGi dependencies from JFace and create a setter and getter in Policy.java. Further, the interface should be extended by a method for transforming a file path. In RCP the set IImageLocationTrasformer implemetation could be one which consider an extension point or any other needed mechanism (perhaps in ui.workbench?). Okay? Any other suggestions? Adam
Why not do this with shared images? Every RCP app gets the opportunity to add to the shared image cache using org.eclipse.ui.internal.WorkbenchConfigurer.declareImage(String, ImageDescriptor, boolean) on startup. Swapping images would be easy. PW
Hi, are the images declared in the plugin.xml (action and commands) also managed via shared images? So these images could also be replaced? Adam
(In reply to comment #15) > Hi, > > are the images declared in the plugin.xml (action and commands) also managed > via shared images? So these images could also be replaced? org.eclipse.ui.commandImages are managed by the CommandImagesManager. All other images are managed by whatever local extension point does. But most images that come in this way come through org.eclipse.ui.plugin.AbstractUIPlugin.imageDescriptorFromPlugin(String, String) (which is how we added ISharedImages support to most plugin.xml images). PW
see also bug 299717 which discusses this problem from an e4 perspective. I'm wondering if we can close that bug as a duplicate of this one? (Boris, this bug is currently assigned to you and marked for 3.6????)
Removed from 3.6. Owners can re-assess. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
