Skip to content

Kiro/cross platform mascot fixes - #40

Merged
AlleyBo55 merged 2 commits into
masterfrom
kiro/cross-platform-mascot-fixes
Jul 29, 2026
Merged

AlleyBo55 merged 2 commits into
masterfrom
kiro/cross-platform-mascot-fixes

Conversation

@AlleyBo55

Copy link
Copy Markdown
Owner

No description provided.

Three separate defects, all in code that only runs off macOS, which is why
local testing never caught any of them.

Windows rendered a blank white window. wry maps custom protocols onto a
different origin per platform: `dora://localhost` on macOS and Linux, but
`http://dora.localhost` on Windows. Three places named the macOS form
outright, and the worst was the script tag in companion.html, so on Windows
the renderer never loaded at all and the window painted empty. The renderer
now uses origin-relative paths, which makes the platform difference stop
mattering, and only the Rust side picks a per-platform entry URL.

Linux showed nothing whatsoever. wry documents `build` as X11 only and
requires `build_gtk` to also support Wayland, which is the default on
current Ubuntu, Fedora and GNOME. We called `build` unconditionally, so on
any Wayland session the webview failed and no mascot ever appeared.

Windows also flashed a window open and shut every few seconds. The parent
watchdog shells out to `tasklist`, and a GUI-subsystem binary owns no
console, so each spawn made Windows allocate one and flash it. Every child
process now passes CREATE_NO_WINDOW, the watchdog and the powershell call
that raises the IDE alike.

Wayland will not let a client position its own window, so even once visible
the mascot animates in place rather than walking. That is a protocol
restriction rather than something to fix, so the Linux caveat now says it
instead of leaving it to look like a bug.

Verified on macOS: typecheck, build, 34 smoke checks, 4 quarantine checks,
the binary still starts at 792 KB, no hardcoded origin survives in either
shipped asset, and the new relative paths resolve to real files on disk.

Not verified: this machine has only the two darwin targets installed, so
the cfg(windows) and cfg(linux) branches are unproven beyond parsing. A
successful macOS build shows they are syntactically valid Rust, not that
their APIs resolve. CI compiles all four. Whether the pet now genuinely
draws on Windows and Wayland still needs a person on those machines.
The marketplace description still said the pet "lives in your sidebar",
written before desktop mode existed. Sidebar is the last-resort fallback for
platforms with no companion binary, so the one line shown in search results
and the Extensions list was selling the weakest of the three surfaces.

It now leads with what the extension actually is and names the signals it
reacts to, since "reacts to how you code" tells a reader nothing. Adds kiro,
agent-status and floating as keywords.

Two stale factual claims in the README went with it. It still said only
darwin-arm64 had been built, which four published platform binaries make
untrue, and it did not mention that Wayland forbids an application from
positioning its own window, so the mascot animates in place there. Both are
things a user would otherwise read as a defect.

Verified: package.json parses, the edit stayed surgical at two lines rather
than reformatting, typecheck, build and 34 smoke checks pass.
@AlleyBo55
AlleyBo55 merged commit 80725c2 into master Jul 29, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant