08df660f6c
Sliced files previewed through a vendored copy of PrettyGCode in an iframe. It drew each move as a screen-space line -- a line has no thickness in the scene, so it cannot occlude the layer behind it, which is why prints came out stringy and shimmered where layers crossed. Being a separate app in a frame, it could be neither themed nor translated, and carried its own machinery for detecting a proxy refusing the embed. Now built on libvgcode, the renderer OrcaSlicer draws its own preview with, vendored from three-slicer (AGPL, same as us). It takes the THREE namespace as an argument and imports nothing, so it runs on our 0.181 rather than the 0.160 its package pins. The parser is ours; upstream renders its own kernel's output and ships no G-code parser at all. Two things it has to get right, both found by checking a real plate rather than assuming: - BambuStudio does not use the OrcaSlicer/PrusaSlicer annotations. It writes "; FEATURE:", "; LINE_WIDTH:", "; CHANGE_LAYER" and "; Z_HEIGHT:", not ";TYPE:", ";WIDTH:" and ";LAYER_CHANGE". Reading only the latter showed a 52-layer print as 23,165 layers in one colour, because with no layer marker recognised every travel Z-hop split a layer and every segment took the fallback feature. - It emits a tenth of its moves as G2/G3 arcs -- 706 extruding ones in a single plate. Ignoring them punched holes through curved walls and tree supports. Arcs with no X/Y are the helical travel lift and lay down nothing, so they interpolate as travels. Four colour modes: filament (default, from the AMS slots the file was sliced with), feature, layer height, line width. Speed, fan and temperature are deliberately absent -- upstream derives those from settings rather than the toolpath, and guesses dressed as measurements are worse than an honest omission. The parser now carries the data to do them properly later. Legend entries are switches. Hiding removes the records before the mesh is built rather than recolouring them: the shader packs colour into a single float with no alpha, so there is no transparent to set, and removal is the useful behaviour anyway -- a hidden support stops occluding what it covered. The scene is built once and only the toolpath rebuilds. Doing otherwise constructed a new WebGLRenderer on every render, because the buildVolume default is an object literal and so a fresh identity each time; browsers cap live WebGL contexts and drop the oldest, which blanked the canvas after a few interactions. utils/framing.ts goes with the iframe, along with six now-orphaned strings in all 13 locales. src/lib/vendor is excluded from eslint -- acting on findings in vendored code makes it impossible to re-copy on the next upstream release. |
||
|---|---|---|
| .. | ||
| service | ||
| vendor | ||
| .gitignore | ||
| bambuddy.ico | ||
| bambuddy.iss | ||
| build.py | ||
| README.md | ||
Bambuddy Windows Installer
Builds a self-contained Windows installer (.exe) for Bambuddy: embedded
Python 3.13 distribution + pre-built frontend + NSSM-supervised Windows
service. No Python or Node installation required on the target machine.
Architecture
- Install target:
C:\Program Files\Bambuddy\ - Data target:
C:\ProgramData\Bambuddy\data\(preserved on uninstall by default) - Logs target:
C:\ProgramData\Bambuddy\logs\ - Service: registered via NSSM, runs as
LocalSystem, autostart on boot - Service command:
python.exe -m uvicorn backend.app.main:app --host 0.0.0.0 --port 8000 --loop asyncio(--loop asyncioavoids a uvloop TLS bug that can truncate VP FTP uploads, #1896) - Bundled binaries: Python 3.13 embeddable, NSSM, ffmpeg static build
Browser is the UI. Start Menu shortcut opens http://localhost:8000.
Why these choices
See memory/windows-installer-decision.md for the full reasoning. Short
version: PowerShell install scripts can't survive environmental drift
across the Windows host fleet, so we ship a self-contained bundle that
depends on nothing on the host. Inno Setup + embedded Python is the
lowest-maintenance path that delivers native-app UX. No Tauri/Electron
launcher in v1 — browser-as-UI matches every other Bambuddy platform.
Build prerequisites
The build runs on Windows (or in a Windows GitHub Actions runner). Cross- building from Linux is possible via Wine but not officially supported.
- Windows 10/11 x64 (or
windows-latestGitHub Actions runner) - Python 3.11+ (for running
build.py; the embedded Python that ships in the installer is downloaded fresh by the build script) - Node.js 22 LTS + npm (for building the frontend bundle)
- Inno Setup 6 (for compiling
bambuddy.iss→.exe)
The build script downloads everything else automatically (embedded Python, NSSM, ffmpeg).
Build steps
:: From the repo root on a Windows machine
cd installers\windows
python build.py
:: Then open bambuddy.iss in Inno Setup Compiler and click Build → Compile
:: (or invoke ISCC.exe directly:)
"C:\Program Files (x86)\Inno Setup 6\ISCC.exe" bambuddy.iss
Output: installers\windows\build\output\bambuddy-windows-setup.exe
Testing without signing
The installer can be built and run unsigned. Windows SmartScreen will show "Windows protected your PC" on first run. Click More info → Run anyway to proceed. This is expected and harmless for testing. Production builds will be signed via SignPath OSS (application in flight as of 2026-06-10) and won't show this warning after reputation accrues.
CI build
See .github/workflows/windows-installer.yml for the automated build.
The workflow runs on every tag matching v* and uploads the installer
as a release asset.
Known limitations / open questions
- VP feature on Windows: the Virtual Printer needs to bind 322/990/8883 (privileged ports). Service runs as LocalSystem which can bind these ports, but the user's Windows Firewall will prompt on first VP enable. Documenting this is TBD.
- Spoolman: explicitly NOT bundled in v1. Users who want Spoolman install it separately. Bambuddy internal-inventory mode is the default on Windows.
- Bundle size: estimated 250–350MB installed (mostly opencv + ffmpeg + matplotlib). Acceptable for a v1; can investigate slimming later if users complain.
- Updates: v1 ships as a fresh install / uninstall + install cycle. In-place upgrade via the same installer is supported by Inno Setup but needs end-to-end testing before we promise it.