Community
Participate
Working Groups
Currently it is not possible to exchange icons for the platform. We should allow this. Here are some questions from Matthias Becker from Bug 531876. ------- If we implement this via CSS I see some questions: - What is the selector for an existing icon - What is the property for the replacement icon - We must then hook something into the image creation so that when we switch the theme we can replace the existing images with the replacement icons. Any idea on that? -------- A "simple" solution might be to use for the definition of icons preference values. The CSS engine can already configure preferences Other suggestions are also welcome.
New Gerrit change created: https://git.eclipse.org/r/120041
Created attachment 273265 [details] Example showing the POC
Comment on attachment 273265 [details] Example showing the POC Unzip and import in your workspace Needs the following jars as "Referenced Libraries": - org.eclipse.swt (inkl. the platform specific fragment - org.eclipse.equinox.common Needs the org.eclipse.jface project (with the patch from this change) in the workspace and needs to reference this project.
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/120041 This is a POC implementation of the replacement. The main idea is to intercept the factory methods createFromFile and createFromURL in ImageDescripto. When these are called we look up if a replacement is registered and simply return the replacement. Up to now only the interception in createFromFile is implemented. This interception only works at creation time of the ImageDescriptors. Existing ImageDescriptors or already created SWT-Images will not change directly at a theme switch. I think re-drawing already existing images would be quite complex. This also only allows replacement of images that are directly (or indirectly) loaded from a file. Images that are drawn in code using GC cannot be replaced - but this should be clear and should not be an issue. What do you think about this interception idea? Does anybody have concerns about this. What is still completely open is how bundles can provide replacements for icons. Registration could be based on the combination of theme-id, bundle and file path. For registering icon replacements we could: a) provide an extension point. Plugins would provide additional icons (next to the original icons) and could register them based on a theme. In this extension we could reference a themeid like plugins can contribute css files for existing themes with the "themeid" element in the"org.eclipse.e4.ui.css.swt.theme" extension point. b) think about a notation in the css. I don't have an idea on that c) something completely different. I personally would implement a) but I am open for other suggestions here.
(In reply to Matthias Becker from comment #4) > For registering icon replacements we could: > a) provide an extension point. Plugins would provide additional icons (next > to the original icons) and could register them based on a theme. > In this extension we could reference a themeid like plugins can contribute > css files for existing themes with the "themeid" element in > the"org.eclipse.e4.ui.css.swt.theme" extension point. -1 too complex IMHO > b) think about a notation in the css. I don't have an idea on that +1
Jonas, can you describe how image replacement works for HTML with CSS?
(In reply to Lars Vogel from comment #6) > Jonas, can you describe how image replacement works for HTML with CSS? This depends on how the icons are implemented. I heard they are PNG files. The following is how you would "override" an image/icon in HTML/CSS assuming you have an element with the class "icon" and give it the class "new-icon" aswell: .icon { background-image: url(path/to/icon.png); /* There will need to be more additions here for example height or width attributes. Otherwise, this wouldn't be shown at all. */ } .icon.new-icon { background-image: url(path/to/new-icon.png); } This is basically how you replace an image with CSS. I'm not sure what attributes the subset of eclipse has available. But I think the process shouldn't differ that much.
(In reply to Lars Vogel from comment #5) > (In reply to Matthias Becker from comment #4) > > > For registering icon replacements we could: > > a) provide an extension point. Plugins would provide additional icons (next > > to the original icons) and could register them based on a theme. > > In this extension we could reference a themeid like plugins can contribute > > css files for existing themes with the "themeid" element in > > the"org.eclipse.e4.ui.css.swt.theme" extension point. > > -1 too complex IMHO We could even extend the org.eclipse.e4.ui.css.swt.theme extension point by a list or icon replacements. For me this sounds not that complex. > Jonas, can you describe how image replacement works for HTML with CSS I am curious on that.
(In reply to Jonas Hungershausen from comment #7) > (In reply to Lars Vogel from comment #6) > > Jonas, can you describe how image replacement works for HTML with CSS? > > This depends on how the icons are implemented. I heard they are PNG files. > The following is how you would "override" an image/icon in HTML/CSS assuming > you have an element with the class "icon" and give it the class "new-icon" > aswell: > > .icon { > background-image: url(path/to/icon.png); > /* > There will need to be more additions here for example height or width > attributes. Otherwise, this wouldn't be shown at all. > */ > } > > .icon.new-icon { > background-image: url(path/to/new-icon.png); > } > > > This is basically how you replace an image with CSS. I'm not sure what > attributes the subset of eclipse has available. But I think the process > shouldn't differ that much. We use CSS to style SWT-Widgets and not HTML elements. I don't see how this should work together with SWT.
(In reply to Matthias Becker from comment #9) > We use CSS to style SWT-Widgets and not HTML elements. I don't see how this > should work together with SWT. What about: swt-icon-path { url-to-icon: new_path; } And the CSS engine could define a handler for this. The JFace ImageDescriptor could delegate to the CSS engine. We "only" need to ensure that JFace still works standalone (without CSS plug-ins present).
(In reply to Lars Vogel from comment #10) > (In reply to Matthias Becker from comment #9) > > We use CSS to style SWT-Widgets and not HTML elements. I don't see how this > > should work together with SWT. > > What about: > > swt-icon-path { > url-to-icon: new_path; > } > > And the CSS engine could define a handler for this. The JFace > ImageDescriptor could delegate to the CSS engine. We "only" need to ensure > that JFace still works standalone (without CSS plug-ins present). That should work, but you would need to have a "standard theme file" where the icons are initially declared. Then you could add another file that overrides these.
(In reply to Lars Vogel from comment #10) > (In reply to Matthias Becker from comment #9) > > We use CSS to style SWT-Widgets and not HTML elements. I don't see how this > > should work together with SWT. > > What about: > > swt-icon-path { > url-to-icon: new_path; > } > So for my example this would be; /src/copy_edit.png { url-to-icon: /src/cut_edit.png; } Would it be necessary to think about a notation that is similar to the one that is used to style preference values: IEclipsePreferences{ preferences: 'my.color.id=204,120,50' } > And the CSS engine could define a handler for this. The JFace > ImageDescriptor could delegate to the CSS engine. We "only" need to ensure > that JFace still works standalone (without CSS plug-ins present). So a direct call / dependency to the CSS plug-in is not possible. How would we ensure this decoupling? Any example where something similar is done already today?
(In reply to Jonas Hungershausen from comment #11) > That should work, but you would need to have a "standard theme file" where > the icons are initially declared. Then you could add another file that > overrides these. So when someone adds a icon to his bundle his in addition would also need to define it in a separate place (in some CSS file)? Sorry that is not an option. This has multiple reasons: - Bundle authors would not do this because they may simply not know it. And then you cannot exchange it. - In addition this means existing bundles must be adapted so that it is possible to exchange them.
(In reply to Matthias Becker from comment #4) > What do you think about this interception idea? Does anybody have concerns > about this. You did not comment on this question. So you are fine with it?
The question is what icons you want to exchange. If those are coming from the model the job is quite easy because all you need to do there is to grab the CSS-Engine and lookup an ID-Selector there. If you can't find one or the selector has no "icon: url(....)" you just go with the current value from the model.
(In reply to Thomas Schindl from comment #15) > The question is what icons you want to exchange. > > If those are coming from the model the job is quite easy because all you > need to do there is to grab the CSS-Engine and lookup an ID-Selector there. > If you can't find one or the selector has no "icon: url(....)" you just go > with the current value from the model. See my example project attached. There it's only plain old SWT.
(In reply to Matthias Becker from comment #14) > (In reply to Matthias Becker from comment #4) > > What do you think about this interception idea? Does anybody have concerns > > about this. > > You did not comment on this question. So you are fine with it? I like the idea of allowing the CSS engine to be called by JFace. This should really makes it possible to replace all icons without modifiying existing plug-ins.
(In reply to Matthias Becker from comment #12) > So for my example this would be; > > { > url-to-icon: /src/cut_edit.png; > } CSS selector needs to be fix, your example would be: swt-icon-path { plugin://bundle-symbolic-name/path_to_icon: plugin://bundle-symbolic-name/path_to_new_icon; }
(In reply to Lars Vogel from comment #18) > (In reply to Matthias Becker from comment #12) > > So for my example this would be; > > > > { > > url-to-icon: /src/cut_edit.png; > > } > > > CSS selector needs to be fix, your example would be: > > > swt-icon-path { > plugin://bundle-symbolic-name/path_to_icon: > plugin://bundle-symbolic-name/path_to_new_icon; > } okay got it. This could work.
(In reply to Lars Vogel from comment #18) > (In reply to Matthias Becker from comment #12) > > So for my example this would be; > > > > { > > url-to-icon: /src/cut_edit.png; > > } > > > CSS selector needs to be fix, your example would be: > > > swt-icon-path { > plugin://bundle-symbolic-name/path_to_icon: > plugin://bundle-symbolic-name/path_to_new_icon; > } This is not valid CSS!
(In reply to Thomas Schindl from comment #20) > > swt-icon-path { > > plugin://bundle-symbolic-name/path_to_icon: > > plugin://bundle-symbolic-name/path_to_new_icon; > > } > > This is not valid CSS! Yes, its pseudo code to bring the idea across.
(In reply to Lars Vogel from comment #21) > (In reply to Thomas Schindl from comment #20) > > > swt-icon-path { > > > plugin://bundle-symbolic-name/path_to_icon: > > > plugin://bundle-symbolic-name/path_to_new_icon; > > > } > > > > This is not valid CSS! > > Yes, its pseudo code to bring the idea across. I aume we have to "encode" some characters in "plugin://bundle-symbolic-name/path_to_icon"
[...] > I like the idea of allowing the CSS engine to be called by JFace. This > should really makes it possible to replace all icons without modifiying > existing plug-ins. So JFace gets a dependency on the CSS-Engine. This won't work out.
(In reply to Thomas Schindl from comment #23) > > So JFace gets a dependency on the CSS-Engine. This won't work out. Please read the whole thread, we already said this must be an optional dependency.
Set a side that what I see there as proposal abuse CSS I also don't understand why hooking ImageDescriptor would help at all because you need to make all code invoke the setImage()-method on the widget in question in case of Theme-Change. Suppose I have a Part who did that: class MyPart { void init(Composite parent) { Button b = new Button(parent,SWT.PUSH); b.setImage( ImageDescriptor.createFromFile(getClass(),"black.png").createImage() ); } } how would you manage to reload the image, answer impossible.
Tom, feel free to suggest a better solution covering all possible scenarios. We are currently looking to improve the current situation in which there is no way for exchanging icons.
(In reply to Thomas Schindl from comment #25) > Set a side that what I see there as proposal abuse CSS I also don't > understand why hooking ImageDescriptor would help at all because you need to > make all code invoke the setImage()-method on the widget in question in case > of Theme-Change. > > Suppose I have a Part who did that: > > class MyPart { > void init(Composite parent) { > Button b = new Button(parent,SWT.PUSH); > b.setImage( > ImageDescriptor.createFromFile(getClass(),"black.png").createImage() ); > } > } > > how would you manage to reload the image, answer impossible. As I already wrote in comment 4 https://bugs.eclipse.org/bugs/show_bug.cgi?id=532695#c4 I am ware of the limitation that existing Widgets won't change at theme switch. This only works at creation time of the image descriptors. @Tom: Do you have a better idea how to exchange icons that does not have this limitation?
(In reply to Lars Vogel from comment #10) > And the CSS engine could define a handler for this. The JFace > ImageDescriptor could delegate to the CSS engine. We "only" need to ensure > that JFace still works standalone (without CSS plug-ins present). Is there a way to query the theme-id of the currently active theme without a direct dependency on the css plugin?
> As I already wrote in comment 4 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=532695#c4 > I am ware of the limitation that existing Widgets won't change at theme > switch. This only works at creation time of the image descriptors. > @Tom: Do you have a better idea how to exchange icons that does not have > this limitation? No I don't, all I can say (and I don't have more cycles to think about this) is that I think the solution proposed is not a good one.
Just found out that ThemeEngine#sendThemeChangeEvent publishes a theme change event via the OSGi Event Admin service. So we could get the current theme via this without an hard dependency an on the CSS plugin.
(In reply to Matthias Becker from comment #30) > Just found out that ThemeEngine#sendThemeChangeEvent publishes a theme > change event via the OSGi Event Admin service. So we could get the current > theme via this without an hard dependency an on the CSS plugin. But we can also not introduce a hard dependency on the event system. I think the correct approach is: 1.) we need to check if the CSS bundle is available 2.) if not do as before 3.) if available we need to consult the CSS engine if the icon should be replaced or not We have such 1.) checks in several places, once I refind them I post an update here so that you have example coding.
(In reply to Lars Vogel from comment #31) > But we can also not introduce a hard dependency on the event system. I think > the correct approach is: > 1.) we need to check if the CSS bundle is available > 2.) if not do as before > 3.) if available we need to consult the CSS engine if the icon should be > replaced or not So how would we do 3.) ? Via reflection?
(In reply to Lars Vogel from comment #31) > But we can also not introduce a hard dependency on the event system. Just thought about reading the current theme from the preferences. But I am afraid we also cannot create a hard dependency from jface to org.eclipse.ui.workbench. This would be needed when accessing the preferences api.
(In reply to Matthias Becker from comment #33) > (In reply to Lars Vogel from comment #31) > > But we can also not introduce a hard dependency on the event system. > Just thought about reading the current theme from the preferences. But I am > afraid we also cannot create a hard dependency from jface to > org.eclipse.ui.workbench. This would be needed when accessing the > preferences api. Just ignore this org.eclipse.ui.workbench stuff. org.eclipse.jface today has a dependency to org.eclipse.equinox.common and org.eclipse.equinox.bidi. Is it ok to add a dependency to org.eclipse.equinox.preferences? The only additional dependency org.eclipse.equinox.preferences brings with it is org.eclipse.equinox.registry and this is an optional one: org.eclipse.equinox.registry;bundle-version="[3.2.0,4.0.0)";resolution:=optional But it also defines the following additional "import package" dependencies: org.eclipse.osgi.service.environment, org.osgi.service.prefs;version="[1.1.1,1.2)"
(In reply to Lars Vogel from comment #18) > CSS selector needs to be fix, your example would be: > swt-icon-path { > plugin://bundle-symbolic-name/path_to_icon: > plugin://bundle-symbolic-name/path_to_new_icon; > } The parameters of ImageDescriptor's Factory methods are: ImageDescriptor createFromFile(Class<?> location, String filename) Exmaple: location: class org.eclipse.jface.fieldassist.FieldDecorationRegistry filename: images/contassist_ovr.png ImageDescriptor createFromURL(URL url) Example: bundleentry://1128.fwk934223763/eclipse16.png Is there a way to transform these input to the "plugin://bundle-symbolic-name/path_to_icon" format?
See MenuHelper#rewriteDurableURL() for bundleentry: URL rewriting. I think for the interception, you could allow configuring an interceptor using the org.eclipse.jface.util.Policy class?
(In reply to Brian de Alwis from comment #36) > See MenuHelper#rewriteDurableURL() for bundleentry: URL rewriting. Ah I see. That's exactly what I was looking for > I think for the interception, you could allow configuring an interceptor > using the org.eclipse.jface.util.Policy class? I had a look at the class. Can you please explain in more details what you mean with "allow configuring an interceptor using the org.eclipse.jface.util.Policy class"?
I meant augmenting Policy with an Image URL Rewriter, which would be consulted by ImageDescriptor#createFromURL(). The CSS Engine could set this rewriter to consult the CSS model. But it seems to me that you'd want something that works at the E4 model level, such that the resulting image URL is determined with knowledge of the model element. For example, an MToolItem's icon may depend on whether the parent is an MPart or an MTrimmedWindow's trim area.
Not much happened in the past 2 years. If someone plans to work on this, please reopen.
Still relevant
IIRC Rolf implemented the dynamic update of ylroolbars if the icon Uri changes at runtime. With that CSS support for e4 toolbars and views should be possible.
(In reply to Lars Vogel from comment #41) > IIRC Rolf implemented the dynamic update of ylroolbars if the icon Uri > changes at runtime. With that CSS support for e4 toolbars and views should > be possible. I don't think that something is implemented for toolbars, even changing the URI in the E4 model will currently not update the icon. Though implementing that should not be too complex, listening to the right E4 model event (icon changed) and calling update on the relevant org.eclipse.e4.ui.workbench.renderers.swt.AbstractContributionItem should do the trick. That is AbstractContributionItem#updateIcons should be called. To override the image the AbstractContributionItem should also take IPresentationEngine.OVERRIDE_ICON_IMAGE_KEY into account. I think that this would be the proper way to handle overrides from CSS, maybe that is already used for other parts in the model. There have been some changes to get all this logic working for SWTPartRenderer#getImage Note however that many Toolbar items (almost all) are still provided using the 'old' APIs. As a result, most items are 'opaque' items. The icons for these items are not managed by the E4 model, so probably they cannot be changed this way. As many of these items are provided by extension points, it should be possible to use proper E4 API to insert the items directly into the model, but that is out of scope of this bug.
How does the DevStyle plugin handle things? They've got an Icon Designer utility which seems to dynamically change icons in the IDE.
(In reply to Rolf Theunissen from comment #42) > (In reply to Lars Vogel from comment #41) > > IIRC Rolf implemented the dynamic update of ylroolbars if the icon Uri > > changes at runtime. With that CSS support for e4 toolbars and views should > > be possible. > > I don't think that something is implemented for toolbars, even changing the > URI in the E4 model will currently not update the icon. Though implementing > that should not be too complex, listening to the right E4 model event (icon > changed) and calling update on the relevant > org.eclipse.e4.ui.workbench.renderers.swt.AbstractContributionItem should do > the trick. That is AbstractContributionItem#updateIcons should be called. > > To override the image the AbstractContributionItem should also take > IPresentationEngine.OVERRIDE_ICON_IMAGE_KEY into account. I think that this > would be the proper way to handle overrides from CSS, maybe that is already > used for other parts in the model. > There have been some changes to get all this logic working for > SWTPartRenderer#getImage > > Note however that many Toolbar items (almost all) are still provided using > the 'old' APIs. As a result, most items are 'opaque' items. The icons for > these items are not managed by the E4 model, so probably they cannot be > changed this way. As many of these items are provided by extension points, > it should be possible to use proper E4 API to insert the items directly into > the model, but that is out of scope of this bug. How can we go ahead with this bug? It would really be nice to have the possibility so exchange icons in a theme.
> How can we go ahead with this bug? It would really be nice to have the > possibility so exchange icons in a theme. +1, I'm very interested in moving this bug forward. I think once this bug is resolved + flat CtabFolders are used + other small tweaks to the default theme, people won't have many reasons to complain about Eclipse's UI looking dated.
(In reply to Andrew Obuchowicz from comment #45) > > How can we go ahead with this bug? It would really be nice to have the > > possibility so exchange icons in a theme. > > +1, I'm very interested in moving this bug forward. I think once this bug is > resolved + flat CtabFolders are used + other small tweaks to the default > theme, people won't have many reasons to complain about Eclipse's UI looking > dated. I am willing to help creating new dark theme optimized SVGs for the icons
(In reply to Matthias Becker from comment #46) > (In reply to Andrew Obuchowicz from comment #45) > > > How can we go ahead with this bug? It would really be nice to have the > > > possibility so exchange icons in a theme. > > > > +1, I'm very interested in moving this bug forward. I think once this bug is > > resolved + flat CtabFolders are used + other small tweaks to the default > > theme, people won't have many reasons to complain about Eclipse's UI looking > > dated. > > I am willing to help creating new dark theme optimized SVGs for the icons Awesome, thank you so much Matthias! :)
I will have a look....
I will soon push a prototype which allows to change the Icon URI via the ToolBarManagerRenderer. If I I check the new icons URI at runtime with the model spy, I see that the update worked but not all toolbar entries using these new icons. Maybe something wrong in the compatibility layer.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/187323
I'm not sure CSS is the right layer as this capability to change icons via some option would be profitable to any JFace app, even without CSS. In bug 562174, there are proposal about changing the ImageDescriptor to support some "theme" flag when loading resources, similarly to how it appends @2x or how $nl$ parts of the given paths are replaced according to the language. I believe the CSS-less approach discussed there can be simpler to implement, simpler to adopt and be much more powerful.
(In reply to Lars Vogel from comment #49) > I will soon push a prototype which allows to change the Icon URI via the > ToolBarManagerRenderer. If I I check the new icons URI at runtime with the > model spy, I see that the update worked but not all toolbar entries using > these new icons. Maybe something wrong in the compatibility layer. Will this then only work in Toolbars? What about other locations of icons E.g. wizard banners ?
(In reply to Mickael Istria from comment #51) > I'm not sure CSS is the right layer as this capability to change icons via > some option would be profitable to any JFace app, even without CSS. > In bug 562174, there are proposal about changing the ImageDescriptor to > support some "theme" flag when loading resources, similarly to how it > appends @2x or how $nl$ parts of the given paths are replaced according to > the language. I believe the CSS-less approach discussed there can be simpler > to implement, simpler to adopt and be much more powerful. I agree. But we then need a connection between the CSS-Theme and that "theme flag when loading resources".
