fatalBox off Windows was a single println. That goes to stderr, and a
binary started from a file manager or a .desktop launcher has no stderr
anyone will read — so a carefully worded refusal ("the folder OpsLog
keeps everything in cannot be written to…") reached the operator as "I
click it and nothing happens", which is the least useful thing a program
can say.
It now opens a dialog through zenity or kdialog when either is present —
both ship with every distribution's desktop task — and writes to stderr
either way. Neither is required: the startup log already carries the
same text, and nothing here may stop OpsLog from exiting.
Reported from a Windows 10 machine: the process appears, no data folder
is created, nothing starts. There was nothing to read because the only
log OpsLog has lives inside the folder that was never created.
Three exits happen before any window or log exists, and all three were
silent. Another instance already running — correct to refuse, since two
would fight over the rig, but indistinguishable from a crash. The data
folder unwritable — it is created BESIDE the executable, so a copy
dropped into Program Files is refused by Windows outright. And wails.Run
failing, which is where a missing WebView2 runtime lands; its error went
to println, which in a GUI-subsystem program goes nowhere at all.
Each now writes to %LOCALAPPDATA%\OpsLog\startup.log — a folder Windows
guarantees the user can write to, whatever OpsLog was installed into —
and shows a message box naming the fault and what to do about it.
rouggy