Two behaviours that live in the same function, appExit() in MarkdownViewer.svelte. They are one product decision, so one issue.
1. ⌘Q and the red X disagree about the session
With Restore session on reopen enabled and 5 saved files open:
- Red X → all 5 come back next launch.
- ⌘Q / File ▸ Quit → nothing comes back.
appExit() calls discardPersistedWindowState() and sets isForceExiting, which makes onCloseRequested return before persistWindowState().
This looks deliberate rather than accidental, and I'd like to check that reading before proposing anything:
- the discard is gated on
settings.restoreStateOnReopen — an odd condition to write by accident;
- the confirm dialog says "All unsaved tabs and local history will be lost", which is a promise someone wrote on purpose;
isForceExiting skips the persist step in a second place, so two pieces cooperate.
So the intent seems to be red X = put it away, ⌘Q = I'm done, start clean next time.
The problem is the threshold: that dialog only appears when a tab is dirty. With everything saved, ⌘Q shows nothing and the session vanishes silently — the sentence explaining the design never appears on the path most people take. On macOS ⌘Q is the normal way to quit.
Options: (a) align ⌘Q with the red X; (b) keep it and surface it — a setting, or show the confirm even when clean; (c) keep as is.
2. Quit only closes the focused window
menu-app-quit is emitted to a single window, and appExit() ends with appWindow.close(). Other windows are neither asked nor closed, so ⌘Q with two windows open does not quit the app. No data is at risk — each window still runs its own close checks — but the command does not do what it says.
Happy to implement whichever way you'd like both to go.
Two behaviours that live in the same function,
appExit()inMarkdownViewer.svelte. They are one product decision, so one issue.1. ⌘Q and the red X disagree about the session
With Restore session on reopen enabled and 5 saved files open:
appExit()callsdiscardPersistedWindowState()and setsisForceExiting, which makesonCloseRequestedreturn beforepersistWindowState().This looks deliberate rather than accidental, and I'd like to check that reading before proposing anything:
settings.restoreStateOnReopen— an odd condition to write by accident;isForceExitingskips the persist step in a second place, so two pieces cooperate.So the intent seems to be red X = put it away, ⌘Q = I'm done, start clean next time.
The problem is the threshold: that dialog only appears when a tab is dirty. With everything saved, ⌘Q shows nothing and the session vanishes silently — the sentence explaining the design never appears on the path most people take. On macOS ⌘Q is the normal way to quit.
Options: (a) align ⌘Q with the red X; (b) keep it and surface it — a setting, or show the confirm even when clean; (c) keep as is.
2. Quit only closes the focused window
menu-app-quitis emitted to a single window, andappExit()ends withappWindow.close(). Other windows are neither asked nor closed, so ⌘Q with two windows open does not quit the app. No data is at risk — each window still runs its own close checks — but the command does not do what it says.Happy to implement whichever way you'd like both to go.