Allow icons to be marked "for editor use" during import and automatically handled to match the editor settings

[YuriSizov]

Describe the project you are working on

This is important for editor plugins that either add to the editor UI, or register nodes/resources with custom icons.

Describe the problem or limitation you are having in your project

Currently when you're making a plugin that introduces new editor UI or adds a node or a resources, you can only provide a static, unmodified image for icons. Unlike editor's built-in icons which are dynamically adjusted to match such editor settings as scale or theme. This means that for plugin authors to match the editor's built-in behavior they have to do all sorts of unstable trickery, and more importantly, they have to manually craft icons for every major scale and every editor GUI theme tone.

See also #3422 and #572.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

While we could expose some APIs for the plugin developers to use manually, like #3422 or what I myself suggest in #572 (comment), this would be quite cumbersome to use hindering the experience and slowing the adoption. It would also be completely void of any caching as every time an image would be loaded anew, which would negatively impact the load times for each project that uses these plugins. This is at odds with the fact that the relevant settings (scale and theme) are rarely changed.

So I believe we can make it simpler and more integrated. We can instead expose an import flag that can be configured by the plugin author in the import dock that would mark the icon "for editor use", kind of like scripts are marked with "tool mode". Icons that have this flag, upon being loaded in the editor, would go through the same transformations as the built-in icons go through. If applicable, that is. PNG images would be untouched, but SVG images would be loaded at a correct scale and go through the color replacement.

For further granularity, individual operations may be exposed in the import dock to allow opt-in/out of specific transformations.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I can make a mock-up later, but it would just be a checkbox/section with several checkboxes in the Import dock for image resources, and these checkboxes would enable this new behavior. For the project use the icon would still be imported and cached normally, but for the editor use it would have separate cache and would look at these flags upon being loaded.

[x] For editor use
  [x] Scale with editor scale
  [ ] Convert colors to match editor theme

Relevant editor settings would be used for the cache too, to ensure that when the editor settings change, the icon gets reimported. The whole process should go seamless for the end-user, and would only be visible as a progress bar with resource reimporting upon the editor load.

If this enhancement will not be used often, can it be worked around with a few lines of script?

There are quite a few tricks to work around these limitations in plugin scripts, but all of them are verbose, cumbersome, and require to have all the icon states ready beforehand. For scaling, only the predefined scale factors can be reasonably supported too.

Here's an example from @coppolaemilio with his folder full of icons. A reminder that for the editor all these permutations are handled automatically:

Is there a reason why this should be core and not an add-on in the asset library?

A plugin for plugins to plugin plugins pluginner? Hmmm... But seriously, this boils down to the same shortcomings as described above.

[akien-mga]

Makes sense to me. For the color conversion to work automagically though, users would need to make sure that they use the colors for which we currently do search-and-replace conversions in the SVG:

https://github.com/godotengine/godot/blob/475592a3bc2d2150dcbd9179fff653e3c55505a1/editor/editor_themes.cpp#L152-L254

So we'd need to document these conversions properly, and accept that any change to them is compat breaking (so tweaks for the destination colors are likely fine, but the source color palette should only be added to, not removed from).

[YuriSizov]

So we'd need to document these conversions properly, and accept that any change to them is compat breaking (so tweaks for the destination colors are likely fine, but the source color palette should only be added to, not removed from).

Yes, and I think this should be done regardless as we need to stabilize the color palette in use, and test for regressions regularly. Otherwise engine contributors can break the system unwittingly. See godotengine/godot#56790.

[coppolaemilio]

One thing I do with other icons is that I just set the SVG to be white and I modulate it with the theme color. That way you don't really need to do any search and replace. Of course this doesn't work if the icon has more than one color 😓

If by any chance you are making a plugin and find this issue via google or something like that, this is the code I use to load the proper icon on the tab:

func _get_plugin_icon():
	var _scale = get_editor_interface().get_editor_scale()
	var _theme = 'light'
	if get_editor_interface().get_base_control().get_theme_constant("dark_theme", "Editor"):
		_theme = 'dark'
	return load("res://addons/dialogic/Editor/Images/Plugin/plugin-editor-icon-" + _theme + "-theme-" + str(_scale) + ".svg")

[dploeger]

I don't understand why this is needed for scaling. Isn't this already solved because vector graphics are used in the first place? Aren't they scaled correctly anyway?

[coppolaemilio]

I believe Godot doesn't use vectors. It converts the file to a raster image and it uses that instead.

[YuriSizov]

I don't understand why this is needed for scaling. Isn't this already solved because vector graphics are used in the first place? Aren't they scaled correctly anyway?

SVG icons are converted into texture resources upon import, they aren't vector at this point.

[dploeger]

Oh that is very unfortunate then. I wasn't aware of that. Thanks.

[fire-forge]

The ability to add our own dark -> light theme color mappings would also be really helpful, because there might be cases where the built-in set of colors doesn't work well for an icon.

[AnidemDex]

What I do for now is making big assets, and duplicate them to fit another style, put them all in a theme, create a theme variation from it and applying those for my classes. This proposal really helps me with duplicated assets