Warn that settings changed while node is running will not take into affect until the next startup

[jarolrod]

When a user makes changes to a setting after onboarding and when the node is running, those settings will not take into affect until the next node restart. The UI should provide a clear warning about this to the user.

In the Qt Widgets GUI this is accomplished like so, notice the red warning at the bottom of the screenshot:

I think we could do something like the following in the screenshots below. Whenever a setting is changed, the main node setting page will display a warning at the bottom. And the gear icon in the setting screen can show a warning icon.

gear warning	node setting page warning

[GBKS]

Here's a mock-up. I would not use red, seems too much like an error. I think it's also important that the copy makes it clear that it's about the changes the user has just made. It should not be passive or indirect ("...this change would require...", "Changes to settings...").

A slightly unrelated question here. Should there be 3 options for the mode: Light, Dark, and Automatic (= based on OS settings)?

[yashrajd]

A few suggestions:

• the warning should appear when & where the user changed the setting, not just on the main settings page.
• the changed setting should be highlighted/greyed until the change the applied on restart.
• additionally, the warning could also contain a restart button so the user can take the action immediately (is this possible

For mobile: what does the restart requirement mean? Most users rarely/never quit an app on their phone. Can we relaunch the app for the user?

Happy to do mockups as needed...

[GBKS]

Good suggestions. Let's start with the logic.

1. Which specific changes require a restart?
2. Can we trigger a restart via a button press, both on desktop and mobile?

[rabbitholiness]

In short: any changes that touch Bitcoin :-)

[yashrajd]

Yes, and it makes total sense. Wonder if there are any exceptions/additional settings...

@jarolrod /@johnny9 will also look into the restart query and get back.

I'd like to work on this issue...

[yashrajd]

If I recollect correctly, @jarolrod said today that restart is possible but that would require some reworking of the codebase. So for now, we design for & communicate manual restart. Please correct if this is inaccurate in any way.

[GBKS]

While we're at it, let's design both versions, and keep the one we want eventually as a future issue to tackle. That way we don't have to come back to thinking through this specific issue months down the road.

[yashrajd]

• Uses the same pattern as values updated from elsewhere (CLI). See Settings that are overridden  #44.
• For when user edits a setting that needs restart to apply, shown immediately when the user does it, on the same page as the setting.
• With and without Restart buttons.

[jarolrod]

@GBKS do we want to go with @yashrajd suggestion here? If so can this go in the main design file? I'm working on a rework of optionsmodel to be able to take into account:

1. All configuration values, and where they come from -> so we can show where a value is overriden from
2. If a setting is modifable or not - a setting is modifiable if it is not overridden by bitcoin.conf or a terminal parameter
3. Knowledge of when a value has changes, but a restart is required for the value to be applied

Will look something like this: