"Open dashboard" in the tray did nothing reliable, and there is a Mac build

Reported from the shipped Windows app. Three faults in one call, and the
first is why it failed rather than merely misbehaved.

runtime.Show is implemented by Wails as a bare mainWindow.Show(), while
runtime.WindowShow wraps the identical work in runtime.LockOSThread. Win32
window operations have to run on the thread owning the window's message
pump, and the tray's handler runs on the SYSTRAY's goroutine, which is
never that thread. An unlocked Win32 call from an arbitrary goroutine is
the bug.

Two more that would each have been enough on their own:

- Showing is not un-minimising. Hidden and minimised are different states
  and Show only fixes the first, so a window the user minimised stayed
  minimised.
- Windows refuses the foreground to a process that does not already hold
  it, so the window came back BEHIND whatever was being looked at.
  Clicking a tray icon is by definition a moment when this app is not in
  front, so that is not an edge case here - it is every time. The
  always-on-top flip is the ordinary way to ask, and it is why this now
  runs in a goroutine rather than on the menu loop, which must not sleep.

The same four calls fix OnSecondInstanceLaunch, which had the same shape
and is reached far more often: double-clicking the desktop icon while the
app is already running.

OnBeforeClose used runtime.Hide against a reopen that used WindowShow -
different calls on Windows, one thread-locked and one not. Paired now.

And a Mac build, because the question came up and the answer turned out
to be yes. Wails' darwin frontend references UTType without linking
UniformTypeIdentifiers, so the build failed at the LINK step after
compiling everything - which reads like a broken toolchain rather than
one missing flag. There was no Mac version because of that, not because
of a design limit. darwin_link.go declares the framework in source rather
than leaving it as a CGO_LDFLAGS incantation, for the same reason
deploy.sh now finds Go itself. Verified: plain `go build` produces a
16 MB arm64 binary on this Mac, and the Windows build is unchanged.

Worth knowing for whoever edits that file: the comment directly above
`import "C"` is cgo's C preamble, not documentation. The first attempt put
the explanation there and the prose was compiled as C.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj

desktop/tray.go

@@ -99,7 +99,9 @@ func (t *tray) onReady(ctx context.Context) {
 		case <-t.quit:
 			return
 		case <-t.mOpen.ClickedCh:
-			runtime.Show(ctx)
+			// In a goroutine, like Start and Stop: this sleeps, and a menu
+			// loop that sleeps is a tray that ignores the next click.
+			go openWindow(ctx)
 		case <-t.mStart.ClickedCh:
 			// Never on the menu loop itself: a stop waits for the process to
 			// exit, and a menu that is deaf for the duration looks broken.
@@ -214,3 +216,36 @@ func firstLine(s string) string {
 	}
 	return s
 }
+
+// openWindow brings the dashboard back, and it takes four calls rather than
+// the one that was here.
+//
+// `runtime.Show` was wrong three times over, and the first is the one that
+// made it fail rather than merely misbehave:
+//
+//  1. WRONG THREAD. Wails implements Show() as a bare `mainWindow.Show()`,
+//     while WindowShow() wraps the same work in runtime.LockOSThread. Win32
+//     window operations have to run on the thread owning the window's message
+//     pump; this is called from the SYSTRAY's goroutine, which is never that
+//     thread. An unlocked call from an arbitrary goroutine is why clicking
+//     "Open dashboard" did nothing reliable.
+//
+//  2. Showing is not un-minimising. A hidden window and a minimised one are
+//     different states and Show only fixes the first, so a window the user
+//     minimised stayed minimised.
+//
+//  3. Windows will not let a process that is not already in the foreground
+//     take it - the shell refuses, and the window comes back BEHIND whatever
+//     is being looked at. Clicking a tray icon is by definition a moment when
+//     this application is not in the foreground, so that is not an edge case
+//     here, it is every time.
+//
+// The always-on-top flip is the ordinary way to ask for the foreground anyway.
+// It is brief and it is why this cannot run on the menu loop.
+func openWindow(ctx context.Context) {
+	runtime.WindowUnminimise(ctx)
+	runtime.WindowShow(ctx)
+	runtime.WindowSetAlwaysOnTop(ctx, true)
+	time.Sleep(200 * time.Millisecond)
+	runtime.WindowSetAlwaysOnTop(ctx, false)
+}