deno

gpt luna: Environment OS: Fedora Linux 44 Architecture: x86_64 Deno: 2.9.3 / 2.9.6 Desktop backend: Output format: Linux RPM repo: https://github.com/sigmaSd/aiuse Configuration Reproduction Build the RPM: Install it: The RPM installs successfully and contains the expected executable and icon: However, contains: The application launcher therefore displays instead of . Expected behavior should be used as the human-readable desktop entry name: The RPM/package name, executable name, value, and icon basename should remain derived from the output/package stem: This is consistent with the Deno documentation, which says that is used for the Linux entry name: https://docs.deno.com/runtime/desktop/configuration/#app.name Suspected cause In , is only used as an output fallback when no output is explicitly configured: When an explicit output such as is provided, the configured display name is not retained separately. Later, Linux package metadata derives from the staged app directory name, which is . The generated desktop entry then uses that value for . Relevant functions: Suggested fix Keep the configured as a separate human-readable display name. Continue deriving the package and executable names from the output path, but use the configured display name for the desktop entry's field. This should apply consistently to: Linux app-directory builds packages packages AppImage desktop entries

Summary Two parts: bring raw in line with CEF / WebView, and add Web-shaped viewport getters that every backend was missing. Align raw with CEF / WebView Mouse events now fill and /, fire on a real double-click, and report wheel with the DOM sign (positive = down). / use the content-view origin (), so the title bar is included. On Windows a press can be dequeued before the move that preceded it, so the matching laufey change re-reads the pointer before dispatching. , , , and / use logical pixels, matching CEF / WebView and the constructor. Opening no longer fires twice. On Windows the OS also emits a burst of intermediate sizes before the requested one; those are withheld until the event loop goes idle. reports the real frame origin after the window exists, not a consumed request. during the constructor offsets by the window chrome on Windows and macOS instead of returning a point on the title bar. Shift / Control / Alt / Meta emit / . Super maps to . The matching laufey change also does this on macOS WebView () and keeps at 1. New getters These are new on every backend (raw, CEF, and WebView), not raw-only fixes. is a live getter, the same ratio as . The constructor already reports the real scale (seeded from the primary display, not ), and a window that moves to another monitor updates on the next read. WebGPU surfaces configured from or / should use . and are live getters for the same logical viewport as , like / . Depends on https://github.com/littledivy/laufey/pull/80 (ABI 35, including ). Until that lands and a laufey release is cut, this branch pins: After the laufey change is on crates.io, that pin should be replaced with the published crate version. AI Disclosure This PR was drafted and filed by an AI assistant (Grok). I reviewed and edited it myself.

I noticed when I installed chatgpt rpm from their site, that it kept receiving updates with dnf, I didn't know its possible and I thought it would be a nice addition to deno desktop rpm build , so here is a claude summary: Problem statement builds a real native package, but it's a one-shot artifact — there's no story for the next release beyond "user re-downloads and re-installs manually," while solves updates only for the non-packaged (AppImage/raw-binary) distribution path. Distro-package users get neither integration nor the native updater (which would fight 's bookkeeping if enabled anyway). Proposed shape 1. New config block (mirrors the existing pattern from ): This is the config surface that turns the plain package-builder into a package-builder-plus-repo-client. 2. Build-time: embed repo metadata into the package payload When is set, the pure-Rust RPM/DEB assembler (already writing , symlink, entry) additionally writes: RPM: + DEB: + a keyring dropped under No spec-file/ involvement needed — same "assemble the payload tree directly in Rust" approach they already use for the rest of the package. 3. Package signing at build time Sign the built (-equivalent, or pure-Rust RPM signing since they've avoided shelling out elsewhere) and the (/-equivalent) using the key referenced in . This is the part that actually makes / trust the repo without a manual step each release (still needed once, on first install — same chicken-and-egg bootstrap OpenAI's has). 4. New repo-maintenance command: (or folded into ) Takes a directory of already-built / artifacts across versions and (re)generates the actual repo index — (RPM: primary.xml, repomd.xml, etc.) and the Debian / files. Implemented as a pure-Rust equivalent of / so no system tooling dependency, consistent with the rest of the toolchain's philosophy. Uploading the resulting directory to wherever points is left to the user (S3, GH Pages, etc.) — same boundary already draws for its own release server. 5. Mutual exclusion with ** At runtime, /a new flag like () lets the app detect it was installed via the system package manager (e.g. its binary path is under ). Apps should be encouraged (docs, maybe a runtime warning) to call in notify-only mode — surface "update available, run " — rather than apply-in-place, when . This avoids the corruption/ mismatch problem from earlier. Open questions worth flagging in the issue itself Key rotation story — how does a compromised/rotated signing key get distributed to already-installed repo files? Channel support (/) mapping onto separate repo paths or a single repo with priority pinning? Whether should support incremental updates to / or always full-regenerate (matters at scale, less so for smaller projects). ARM64 + x86_64 in the same repo (multi-arch repodata is standard for RPM/APT, just needs to be modeled).