Applying a num_ctx change to a model that is currently loaded does nothing visible: num_ctx is allocated when the model loads, so the running instance keeps the window it was loaded with. Today the only thing that says so is a Known-limitations paragraph in README.md.
Raised by @dchristensen8 on #6 ("it's not a live change on a running model"), and correct.
Proposal. When apply succeeds for a model that appears in snap.loaded, offer the reload inline — an "unload to apply" affordance on the apply row. Everything needed is already present: Service.qml holds the loaded set, and the unload verb is already wired for the ✕ button.
Why it is worth doing. This is the one place where the feature silently appears not to work. The user did the right thing, got a success, and sees no change.
Acceptance. Applying to a loaded model surfaces the reload path; applying to an unloaded one does not. The README limitation shrinks to a note rather than a warning.
Applying a
num_ctxchange to a model that is currently loaded does nothing visible:num_ctxis allocated when the model loads, so the running instance keeps the window it was loaded with. Today the only thing that says so is a Known-limitations paragraph inREADME.md.Raised by @dchristensen8 on #6 ("it's not a live change on a running model"), and correct.
Proposal. When
applysucceeds for a model that appears insnap.loaded, offer the reload inline — an "unload to apply" affordance on the apply row. Everything needed is already present:Service.qmlholds the loaded set, and theunloadverb is already wired for the✕button.Why it is worth doing. This is the one place where the feature silently appears not to work. The user did the right thing, got a success, and sees no change.
Acceptance. Applying to a loaded model surfaces the reload path; applying to an unloaded one does not. The README limitation shrinks to a note rather than a warning.