Make settings_changed signal less emitted

[KoBeWi]

When testing another PR it kind of annoyed me that changing project's title will update 3D editor's viewports with every letter you type. I looked into it and discovered that:

• ProjectSettings will try to emit the signal at launch for every defined setting (fortunately it's limited to once per frame)
• The signal is emitted every time you change a setting, potentially many times per second
• The signal is emitted after a timeout from changing settings
• The signal is emitted every time you save

The last two actually have the same cause (reminder #100244), i.e. the settings are "changed" when saving, which emits changed signal needlessly.

I added a way to block emitting the signal and applied it in GLOBAL_DEF and in ProjectSettings' inspector. Now the signal is only emitted on the save Timer's timeout and when settings are changed from code. The downside is that when you change a setting in the editor, you may not see the effect immediately (e.g. when changing project title).

EditorSettings have similar problem, but almost nothing uses its equivalent signal. Most of the editor uses the notification, which is emitted by the settings dialog.

[lawnjelly]

Great that you are working on this, I wasn't aware that #100244 didn't lead to a fix.

I'll try and review and test soon, and check there isn't a similar problem in 3.x. 👍

[lawnjelly]

Could this lead to order of construction bugs?

If the aim is to avoid signals during setup, could we alternatively set_block_changed explicitly during setup? (Or will this not deal with delayed loading)

My first thoughts would be, explicitly block during setup, then when starting the main loop, remove the block and send out a changed signal, to ensure all parts are up to date and no order of construction issues.

Also if a user intends to add their own ProjectSetting later, they may want to receive the signal on the first change.

[KoBeWi]

The problem is that GLOBAL_DEFs are scattered all over the code, so it's more reliable to disable them here.

[lawnjelly]

When I add a print_line() just before emitting the signal, I only see one signal when loading both a game, and the editor (for trucktown), suggesting it is working correctly already at startup for these.

Is there a particular scenario where this problem occurs at startup / loading?

[KoBeWi]

Is there a particular scenario where this problem occurs at startup / loading?

The signal should not emit at startup at all, because the settings are being initialized, not changed. Unless something relies on this behavior, but I don't know anything like that.

[lawnjelly]

The signal should not emit at startup at all, because the settings are being initialized, not changed. Unless something relies on this behavior, but I don't know anything like that.

Disagree here, I think:

• When initializing, the settings have changed. Initialization is a type of change. Put another way, if there was no change, we would never need to initialize. 😛
• The signal is a convenient place to update local stuff after all initialization is complete, and avoiding any order of construction issues

It is likely useful for third party code to just put their settings update code in one place and have it done like this, and without it, users are likely to end up scratching their heads thinking "why isn't it called? is this a bug?".

For the main engine, it should imo be tolerant to at least a single settings_changed signal at startup. Anything heavy should already have a noop check for cases where the setting has not changed (e.g. changing shadow atlas sizes etc). If this operation is not slick, then we have bigger problems to worry about.

Also, removing this signal at initialization is compat breaking I think.

[KoBeWi]

The launch signal would be useful if it was guaranteed to be emitted for every node. If you enable a plugin after the editor has loaded, you won't receive it. So realistically user plugins can't rely on it, and core plugins risk having bugs if they happen to load too late (or too early).