feat(settings): expose external-wall/solid/top/travel speeds + crossing-perimeters retraction

[lvjonok]

What

Exposes five goosli slicing settings as editable form widgets in the spycer settings panel (Material group):

Key	Widget	Default	Meaning
print_speed_external_wall	int spinbox (0–9999 mm/s)	0	0 = fall back to inner-wall speed
print_speed_solid	int spinbox (0–9999 mm/s)	0	0 = fall back to infill speed
print_speed_top	int spinbox (0–9999 mm/s)	0	0 = fall back to solid speed
travel_speed	int spinbox (0–9999 mm/s)	130	travel move speed
only_retract_when_crossing_perimeters	checkbox	false	restrict retraction to perimeter crossings

How

Mechanical additions mirroring the existing print_speed_wall (int) and retraction_on (bool) widgets:

• settings.yaml — 5 defaults added to the slicing: block.
• src/settings_widget.py — keys added to GROUPING["material"] (membership is what renders the widget), plus 5 new with_sett() elif branches (4 QSpinBox copied from print_speed_wall, 1 QCheckBox copied from retraction_on).
• src/locales.py — EN class attrs + RU dicts["ru"] entries for each label.

These mirror the goosli keys added in goosli #276 / #278 (merged to goosli master). Keys are under the goosli slicing: block and are not renamed.

Version field intentionally NOT bumped

common.version in settings.yaml is left untouched — per the repo owner it is auto-bumped during the build process, which also handles existing-project migration.

⚠️ RELEASE ORDERING WARNING — read before shipping

spycer does not bundle goosli. The ./lib/goosli binary is supplied out-of-band at release assembly. goosli strict-decodes its settings YAML (KnownFields), so an unknown key makes every slice fail.

This UI must not ship until the bundled ./lib/goosli is new enough to know all 5 keys (i.e. built from goosli master including #276/#278). If a release pairs this spycer UI with an older goosli, slicing will break for every user the moment any of these settings is present in the YAML payload.

Verification

Qt/vtk are not installable in the dev sandbox, so verification was static + a standalone serialization round-trip:

• python3 -c "import ast; ast.parse(...)" on settings_widget.py, locales.py, settings.py — all parse.
• settings.yaml parses; all 5 keys present with correct defaults; common.version unchanged (v1.0.0).
• Standalone reproduction of the goosli-bound path (Settings → to_plain_data → yaml.safe_dump → base64, copied verbatim from src/settings.py): set all 5 keys via the same assignments the on_change handlers use, confirmed they round-trip into the serialized YAML payload.
• Cross-check: each new key has exactly 1 GROUPING entry, 1 elif name == branch, and 2 locale attrs (EN + RU).

Bead: goosli_v2-81o

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0b43c4239f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Gate new slicer settings on compatible goosli

When this Spycer build is paired with a goosli binary from before the changes that added these fields, adding this default and the other new slicing defaults makes every slice send unknown YAML keys: src/settings.py's PathBuilder.get_cmd_with_path serializes all of sett() into --data, and I checked .github/workflows/build.yaml/build-linux.yaml only package Spycer/settings rather than updating or validating ./lib/goosli. Because the slicer strict-decodes its settings, users in that release/runtime context fail before touching the new controls; please guard these keys behind a slicer-version check or make the goosli upgrade atomic with this settings change.

Useful? React with 👍 / 👎.