Moving icon updates to THEME_CHANGED notification

[toger5]

currently icons are updated when on ENTER_TREE + SETTINGS_CHANGED since the controls are not inside the node tree get_icon would return the wrong / no icon. (not part of gui_base).

So in ENTER_TREE the icons (for buttons...) are available and get set. What the user switches to the white theme the icons need to get set again... since the icons color changed.
This was done in SETTINGS_CHANGED.

So a lot of icon update code is duplicated... which sucks... of course.

The proposal is to move everything int THEME_CHANGED since that is called in enter tree. (from default theme to Gui_base theme) and obviously when the theme gets changed in the settings. that also results in icons only updating when the settings change the theme not for every settings change.

one issue with that approach is add_style_override + add_constant_override. these functions themselves trigger the THEME_CHANGED notification. as a result there is an endless loop...

We could keep those functions in enter tree + settings changed. But that would eliminate the performance increase since the than any settings change would again trigger THEME_CHANGED -> and the icons update...

those functions (add_style_override + add_constant_override) could also have a property to trigger theme_changed or not... but I don't know if that would work than... most style overrides are loaded in draw methods anyways so there it does not matter.

Maybe there could be THEME_WILL_CHANGE + THEME_CHANGED.
Will change gets called before and changed after...

I don't know what the best approach is. moving them into THEME_CHAGNED seems like a good idea, but how to handle overrides ?

ping @djrm

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!