mirror of
https://github.com/storytold/photocraft.git
synced 2026-10-25 09:34:40 +01:00
IvanandClaude Opus 5.5
0d5b7f6b39
Step 5 of the issue: launch_args' hand-written loop, USAGE and LaunchArgs become a clap derive, which flattens photocraft-automation's ControlArgs and AutomationArgs. `photocraft --help` comes from the doc comments; `--version` prints the same `photocraft <long version>` line (build_info::long_version_static), and `-V` now does too. --control uses photocraft_automation::args::control_port instead of a local copy. The cases the loop handled by hand are kept: - An old macOS Finder's -psn_... argument is dropped before clap, unless it comes after `--`, where it is a file name. - The per-process options for the single-instance hand-off come from ArgMatches::value_source, in a fixed order. A PerProcess enum names each (and PHOTOCRAFT_GPU_ADAPTER): id() gives a flag's clap id, Display the flag or the variable, so single_instance's log line reads as before. As since #7242, a flag's variable counts as the flag: one clap reads (PHOTOCRAFT_IN_WINDOW_MENUS when it turns the menus on, an automation root that isn't blank) is counted here, as clap read it; env_launch_options keeps #7242's rules for the three read elsewhere (present mode, frame latency, stroke trace) and returns PerProcess. - A file name that isn't valid Unicode is still reported in a notice instead of being opened (#1108); file_names returns FileNames { openable, unreadable }. - Windows release builds still have no console: help, version and usage errors show only when redirected, as since #6435. clap's Error::exit, like print_stdout, never panics on a closed stream. The variables are now declared on their flags: PHOTOCRAFT_CONTROL_PORT on --control, the token variables through ControlArgs (so security::token_inputs, which nothing else used, is removed), and PHOTOCRAFT_AUTOMATION_*_ROOT added on the desktop's Command only, so photocraft-cli still ignores them (#1551). Behaviour changes, as step 0 of the issue decided: - A bad or missing --present-mode, --frame-latency or --stroke-trace value is a usage error (exit 2) instead of a warning. Their variables stay lenient (logged and ignored); presentation's value checks serve both, and the flags refuse a value with a ValueError. - A repeated flag is a usage error, and a value can't start with `-` unless it is a negative number (write --opt=-value). - clap reports the first usage error, not all of them. On an unknown argument clap resolves the pending option value but drops its error, so `--control nope --safegpu` names `--safegpu`. - An empty or blank variable counts as unset; before, only an empty PHOTOCRAFT_CONTROL_PORT did, and an empty token or root was passed on as given. PHOTOCRAFT_IN_WINDOW_MENUS also reads false, no and off as off (FalseyValueParser). A variable that isn't valid Unicode where text is expected is a usage error instead of being ignored. - With --control (or its variable), a token together with a token file, from flags or variables, is clap's either/or usage error at parse time, before the server's own check. Without it no token is read, so a stale exported pair stops nothing, as before. - With --control given, PHOTOCRAFT_CONTROL_PORT is not read, so a bad value there is no longer reported too. The CPU-compatibility relaunch puts --safe-gpu before the original arguments, so a `--` among them can't turn it into a file name. The launch_args unit tests now check clap's errors instead of the error list. The process tests put a late usage error (--control 0 with the token pair) where they used a bad port, so stderr still shows how the other arguments were taken, and cover the variables. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>