Conversation
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
electrobun 1.18.1's rcedit resolution is broken on Windows (its Bun
bundle records a build-machine path for require.resolve("rcedit/package.json")),
so build.win.icon converts the PNG to ICO but never embeds it into the
launcher, bun runtime, or Setup exe. Work around it with two hooks that
use the rcedit + png-to-ico devDependencies:
- postBuild (embed-windows-icon.ts): embeds the icon into every exe in
build/<channel>-win-x64/<App>/bin/ before electrobun compresses the
bundle into the installer archive, so the installed app carries it.
- postPackage (post-package.ts): embeds the icon into the Setup exe,
re-creates the distribution zip with electrobun's layout, and refreshes
the artifact copy.
Both no-op off Windows and are removable when upstream fixes the
resolution.
Co-Authored-By: Claude <noreply@anthropic.com>
electrobun compresses the Windows bundle with the system `tar` (GNU tar on Windows), which emits GNU LongLink entries for paths over 100 chars — Vite's geist-mono font asset is 102 chars. Its own zig extractor rejects LongLink with TarUnsupportedFileType, so install fails. The extractor does support the ustar prefix field, so the postWrap hook (fix-windows-tar.ts) rewrites both the build-dir archive and the wrapper bundle's inner archive in ustar format, splitting long names across name[100] + prefix[155]. postWrap is now a dispatcher (post-wrap.ts) running fix-x64-headerpad.ts then fix-windows-tar.ts. Windows-only; removable when upstream fixes the writer or extractor. Verified: local install simulation with the rebuilt archive completes "Installation completed successfully!" (extraction, shortcuts, updater tar). Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
electrobun deletes the app bundle folder after tarring (buildEnvironment
!== "dev"), leaving only the self-extracting wrapper (extractor stub +
inner tar.zst) at build/<channel>-win-x64/LLMSpace-<channel>/; the wizard
hook compiled ISCC from the wrapper, so the installer shipped a bundle
without bin/launcher.exe and failed to launch. At postPackage the only
complete copy is the channel tar.zst: decompress it (helpers moved to a
shared win-tar module), strip the tar's bundle-folder root component so
{app}\bin\launcher.exe lands flat, compile ISCC from a dot-prefixed
staging dir, and clean up after. Channels without a tar.zst (dev) skip.
Co-Authored-By: Claude <noreply@anthropic.com>
…rames Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
…blur The app processes were DPI-unaware, so at any system DPI != 96 Windows rendered the whole window at 96 DPI and bitmap-scaled it up (e.g. 1280x800 logical -> 1920x1200 physical at 150% scaling), blurring every glyph. Declare PER_MONITOR_AWARE_V2 via bun:ffi as the first statement of the bun entry, before any window or WebView exists, so the WebView2 renders at the real device scale factor. Windows-only; macOS handles Retina natively. Verified on a 150%-scaled RDP session: process reports DPI-aware, text renders crisp at 144 DPI, layout size unchanged. Co-Authored-By: Claude <noreply@anthropic.com>
|
Friendly ping for review — happy to iterate on anything. Quick context on how this was validated beyond CI: it's in daily use on real Windows 11 hardware (WebView2 renderer, per-monitor V2 DPI awareness, window-state restore, deep-link cold-start launcher, trash/reveal, GitHub auth through the system proxy). Packaging runs through the in-repo hooks (icon embed → ustar-safe tar rewrite → Inno Setup wizard with en/zh-CN installer UI, per-user, no UAC), and the auto-update path stays off on Windows until the update feed can serve it. This is one of three open PRs from us (#151 SearXNG, #152 i18n) — independent of each other, so they can be reviewed and merged in any order. If merging #152 first causes textual conflicts here (both touch |
|
Sorry for the delayed follow-up. We currently don't have enough people available to test Windows support, so we're unable to properly validate and maintain it at the moment. I'll close this PR for now, but thank you for the contribution and the time and effort you put into it — I really appreciate it! |
What
Windows 11 support for the desktop app: the app now builds, runs, and installs on
Windows, packaged as a standard GUI wizard installer (Inno Setup). macOS behavior
is unchanged — every change is guarded by
process.platform === "win32".Highlights
hiddenInsettitle bar / traffic lights onWindows; native application menu only on macOS; WebView2 default context menu
suppressed on Windows
auto-update is disabled and the manual check surfaces an explicit
"updates not supported" error instead of failing silently
electrobun.config.tsand embedded intothe exes at build time via
rcedit(no new runtime dependencies)L/K)entries broke the electrobun extractor; rewritten in pure ustar format
minimized window saves the Windows minimized-rect
(-32000,-32000,<icon>)asits frame; the next launch restores it verbatim → off-screen 1px window →
WebView2 container attach fails ("flash quit"). Saving minimized/invalid
frames is now skipped, and restored frames are validated against sane bounds
mise run pack:winproduces a standardWindows GUI installer (
PrivilegesRequired=lowest, per-user install;uninstall removes the app but keeps
~/.llm-spaceuser data)Notes
untouched (this PR's macOS diff is limited to the shared app-code guards)
png-to-ico/rceditare devDependencies used only by the Windows buildhooks; the wizard installer itself (Inno Setup / ISCC) is a machine-level
tool detected at build time
expected)
eb4fb64) — happy to rebase if upstream has moved