-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for "Icon Packs" #13
Comments
I think a preference would be a good idea in any case to prevent excessive lookups, even if they are fast they are not for free.
There is already |
While it's good to reuse it if possible, I think it's important that this particular issue of "icon packs" can be built-in JFace without dependency of e4 or higher-level platform. |
JFace don't need to depend on e4, just reading that preferences with that ID, I actually won't care much about that in contrast to inventing another "icon pack id" that then must match the themeId or similar ... Actually it makes most sense to have a icon pack for a theme than having different icons with the standard theme. |
I disagree here. Also SWT/JFace do not apply only to Eclipse IDE nor workbench, there are other apps that may want icon/image theme without dragging the e4 stuff. |
You don't need to drag in anything. This is just a preference and we can access it in any bundle we like without any dependency. As SWT does not allow for any theming, it might then even be better to not do this in swt/jface but in the eclipse theming framework to handle that case. |
These are obviously not Image-Icons :-) |
Will this new feature allow plugin developers to use different icons for the light and the dark theme? Currently it's quite hard to design icons that have good contrast on light and dark background. So providing alternative icons for the dark theme is a much needed feature.
So if the answer to the above question is yes: We might also want to provide different versions of these "none-image-icons". What would you propose as as solution for this? Having IFs in the drawing code that check for theme-names or brightness of the background color? |
Not in its current form, thats why I requested cahnges and suggested to better integrate this with the theming framework instead of an additional soloution just for SWT.
none-image-icons are custom painted components as as such are best supporting CSS styling instead of loading alternative images. see: |
👍 |
Ultimately yes, but it will also require change in the theme support once we're done with SWT part. The theme would be able to define an icon set to use and configure SWT; so SWT would then load different images. |
@AObuchow what would it take to get this supported for icon packs? I can look for budget to sponsor this. |
See also here for some thoughts how to have "icon theming support": |
@becph01 I actually think @laeubi would be a much better candidate to sponsor for developing this feature :) @laeubi hopefully this is something you're allowed to do? I'm not sure if your work has some conflict-of-interest clause regarding sponsored development for the Eclipse IDE? |
Eclipse Foundation does not limit me regarding other agreements, especially if its in the best interest for the Eclipse IDE itself :-) |
This is a continuation/migration of Bug 562174 - Add support for "icon packs" in Eclipse IDE.
It'd be nice for to have an officially supported way to replace the icons used in Eclipse.
There is a lot of discussion to be held on how this should be handled (and there was already a lot of discussion on the original BZ thread), so I'm going to leave this relatively open-ended.
IIRC the approach I had initially tried was:
There are probably some limitations to this approach, for instance:
It might be nicer to set some JFace preference which points to a specific plugin path (where the plugin is the icon pack provider plugin), and then alternative icons are checked from that plugin before loading the default icon.
I am going to submit a WIP PR that shows my current implementation, as well as an example plugin fragment that provides icon replacements.
The text was updated successfully, but these errors were encountered: