A plain `go build` links no icon resource, so Explorer and the Start menu
draw the generic executable glyph. Inno's SetupIconFile only skins
setup.exe, so the fix has to happen at build time: `fyne package` turns
cmd/haul/Icon.png into a .syso and links it in, and adds -H=windowsgui
itself.
Documents the installer build alongside it, since the two steps are only
useful together.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Double-clicking the bare binary in Finder opens a Terminal window alongside
the app: Finder has no better idea what to do with a Mach-O executable than
hand it to Terminal.app, and the terminal stays up as long as the process
does. macOS has no counterpart to -H=windowsgui, so the only fix is to ship
an application bundle, which Finder launches directly.
Add `make package-darwin`, which runs a pinned `fyne package --target
darwin` to produce ./haul.app. Its metadata comes from cmd/haul/FyneApp.toml
— the app ID there must stay in step with the one app.NewWithID uses, or
macOS treats the bundle and the running app as separate applications. The
icon is a placeholder; `fyne package` will not run without one.
Note that `fyne package` rewrites FyneApp.toml in place on every run, so the
file is left in that tool's canonical formatting rather than a commented
version it would only strip again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
haul compiles cleanly on Windows and then fails at startup inside an RDP
session, because Remote Desktop's display driver provides no usable OpenGL and
Fyne needs 2.1+. Same for Hyper-V, VMs without 3D, and Microsoft Basic Display
Adapter.
Documents deploying Mesa's llvmpipe renderer beside haul.exe, and two things
that are easy to get wrong: all ~19 DLLs from x64 are needed rather than just
opengl32.dll, since that file is now only a front-end for the others; and a
local opengl32.dll shadows the system one, so it forces software rendering even
on machines with a working GPU.
Also adds OpenGL to the runtime requirements table, which only mentioned
needing a display server.
Verified in an RDP session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Windows previously got one line pointing vaguely at MSYS2, while every other
platform got real commands — and the README's main instruction is `make build`,
which stock Windows cannot run at all.
Covers the three ways Windows actually differs: cgo needs a GCC-style compiler
(MSVC will not do), there is no make, and a GUI build needs -H=windowsgui or
Windows opens a console window behind the app on every launch. The Makefile
does not pass that flag since it targets Unix, so the section gives the direct
go build command and names the .exe output explicitly.
Also notes that Windows, unlike Linux, needs no graphics dev packages because
OpenGL ships with the OS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Building needs both Go and a C toolchain, but only the C toolchain had install
commands — so the macOS path read as though `xcode-select --install` was the
whole job. Running it and being told the tools are already present looks like
success right up until `make build` fails with `go: command not found`.
Splits Prerequisites into two numbered steps with install commands for each,
`brew install go` on macOS, and says plainly that both are required.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers what haul is, how to build it, and how to use it.
The build section is deliberately detailed about cgo: haul needs a C compiler
and the platform graphics headers, unlike dial, and cross-compiling needs a
per-target toolchain rather than just GOOS/GOARCH. Documents fyne-cross as the
practical route to Windows and macOS builds.
Claims are limited to what the code actually does — SFTP only, resume within a
session only, and ~/.ssh/config treated as read-only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bsncubed