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>
Inno Setup script for a per-user x64 install, plus the icon it uses for
setup.exe. The Mesa DLLs are an optional component rather than a default:
a local opengl32.dll beats the system one for everything in the same
folder, so shipping them unconditionally would force software rendering
on machines with a working GPU.
Ignore Output/ so the compiled installer stays out of the repo.
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>
Ben wants this shared across projects rather than living inside haul, so the
plan now describes a standalone module with its own repo.
The consequence that shapes the whole API: it can do no UI of its own.
ShippingTracker called MessageBox directly, but haul is Fyne (widgets only from
the UI thread via fyne.Do) and dial is a Bubble Tea TUI. So the module is pure
logic plus an onProgress callback, and each consumer supplies its own prompts.
Also reorders the work. dial goes first: it is pure Go, already cross-compiles,
and release 0.2.0 already has all five platform binaries and SHA256SUMS
attached — so it can adopt this immediately, whereas haul still can't build its
own release assets. dial using SHA256SUMS where ShippingTracker uses
checksums.txt is why the checksum asset name has to be configurable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Modelled on ShippingTracker's Updater.vb: gitea releases API, silent startup
check vs. loud manual one, SHA256 verification, and the rename-swap with .old
cleanup on next launch.
Records the research so it doesn't need repeating — haul's repo is readable
anonymously, so the updater needs no token, and the 404 on releases/latest is
just an empty release list.
Also records the two blockers: the release pipeline has to exist first (cgo
means make dist can't cross-compile), and dynamically linked Linux binaries may
not run on the machine that downloads them.
Not started; four open decisions listed at the end of the doc.
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>
A two-pane local/remote file browser over SSH, split out of dial so file
transfer lives in its own tool. The two share ~/.ssh/config as their base.
- internal/sshconf: ~/.ssh/config parsing, for the saved-host list.
- internal/sshx: dialling and auth — agent, keys, password, host-key
verification, ProxyJump.
- internal/vfs: the FS interface both sides are driven through, implemented
over the local disk and over SFTP.
- internal/xfer: recursive copy engine with progress reporting, cancellation,
conflict policy, and resume of partial transfers.
- internal/ui: the Fyne GUI — connect window (saved hosts plus quick connect)
and the two-pane browser session.
Build with `make build`; the Makefile locates the Go toolchain at ~/.local/go,
which is deliberately kept off PATH. Cross-compiling needs a per-target C
toolchain because Fyne is cgo, so `make dist` builds the native binary only —
the alternatives are documented in the Makefile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bsncubed