Summary
Some settings take effect immediately; others cannot, because what they
influence is consumed once when the target process starts. Nothing distinguishes
them in the UI. I'd like a per-setting annotation — $requiresRestart: true —
so the settings UI can say so after a change.
Why
Wh_ModSettingsChanged lets a mod re-read its settings live, and for most
settings that is genuinely all it takes. But a mod often has a handful that
can't work that way, and from the outside the two look identical: same control,
same Save button, same silence afterwards.
The user changes a value, sees nothing happen, and has no way to know whether
the setting is broken, the mod is broken, or a restart is needed. The author's
only recourse is prose in a $description or the readme — which is exactly the
place people don't look when a control appears to have done nothing.
This is a small UI affordance, but it converts an invisible failure into a
visible instruction.
Evidence
My mod's settings split cleanly across the line:
| Setting |
Behaviour |
| CSS directory contents, inline snippets, variables, theme mode |
hot-apply, open windows restyle within seconds |
FixedPort (the DevTools port) |
cannot hot-apply |
The port is baked into the target's command line by a GetCommandLineW hook at
process start. Once Chromium has parsed it, no amount of re-reading settings
moves it. Today the only warning is a sentence in the setting's description and
a line in the mod's log — the settings UI itself gives no hint.
The contrast within a single mod is what makes this awkward: users correctly
learn that changes here apply instantly, which makes the one setting that
doesn't behave more surprising, not less.
Suggested shape
- FixedPort: 0
$name: Fixed DevTools port
$requiresRestart: true
The UI could then, after a change to such a setting, show a note along the lines
of "Restart the affected applications for this to take effect." Even a small
static hint next to the control would help.
If distinguishing which targets need restarting is more than is wanted, a
mod-level flag ("changing this mod's settings may require restarting targets")
would still be an improvement over nothing.
Related
Pairs with a startup-vs-injected signal for mods (separate request): that one
lets a mod detect the situation at runtime, this one lets it declare the
situation ahead of time so the UI can warn before the user is confused.
Tested on 2.0.0-alpha.2.
Summary
Some settings take effect immediately; others cannot, because what they
influence is consumed once when the target process starts. Nothing distinguishes
them in the UI. I'd like a per-setting annotation —
$requiresRestart: true—so the settings UI can say so after a change.
Why
Wh_ModSettingsChangedlets a mod re-read its settings live, and for mostsettings that is genuinely all it takes. But a mod often has a handful that
can't work that way, and from the outside the two look identical: same control,
same Save button, same silence afterwards.
The user changes a value, sees nothing happen, and has no way to know whether
the setting is broken, the mod is broken, or a restart is needed. The author's
only recourse is prose in a
$descriptionor the readme — which is exactly theplace people don't look when a control appears to have done nothing.
This is a small UI affordance, but it converts an invisible failure into a
visible instruction.
Evidence
My mod's settings split cleanly across the line:
FixedPort(the DevTools port)The port is baked into the target's command line by a
GetCommandLineWhook atprocess start. Once Chromium has parsed it, no amount of re-reading settings
moves it. Today the only warning is a sentence in the setting's description and
a line in the mod's log — the settings UI itself gives no hint.
The contrast within a single mod is what makes this awkward: users correctly
learn that changes here apply instantly, which makes the one setting that
doesn't behave more surprising, not less.
Suggested shape
The UI could then, after a change to such a setting, show a note along the lines
of "Restart the affected applications for this to take effect." Even a small
static hint next to the control would help.
If distinguishing which targets need restarting is more than is wanted, a
mod-level flag ("changing this mod's settings may require restarting targets")
would still be an improvement over nothing.
Related
Pairs with a startup-vs-injected signal for mods (separate request): that one
lets a mod detect the situation at runtime, this one lets it declare the
situation ahead of time so the UI can warn before the user is confused.
Tested on 2.0.0-alpha.2.