Skip to content

desktop: Let a host hand its notifications to the app it embeds - #986

Merged
huacnlee merged 3 commits into
mainfrom
agent/T-0455-embedded-notifications
Nov 6, 2026
Merged

huacnlee merged 3 commits into
mainfrom
agent/T-0455-embedded-notifications

Conversation

@huacnlee

@huacnlee huacnlee commented Nov 5, 2026 •

Copy link
Copy Markdown
Member

What

Notifications only worked under run_app. A host that builds its own AppView had no way to let the app it embeds show notifications on macOS and Windows.

The process belongs to the host, so handing its notifications over is now the host's explicit choice rather than something AppView::new guesses (an earlier revision of this PR took them for every top-level view, which changed the host's own taskbar identity on Windows):

  • AppOptions::notifications (macOS, Windows, Linux; false by default, run_app sets it). When set, the view's app owns the process's notifications:
    • macOS: NSH becomes the UNUserNotificationCenter delegate (a delegate the host already set stays), so banners show while the app is in front and presses reach it. run_app still installs it before launching finishes, so a press that starts the app is not lost.
    • Windows: the process takes app_id as its AppUserModelID, registers it with title and icon for toasts and hears their presses. The first such view's app wins.
    • Linux: no change; the desktop portal knows the app by its id either way.
  • Without it, Notifications.permission() / requestPermission() resolve "unavailable", show() resolves false and setBadge leaves the host's badge alone. The JS API is unchanged.

Public API

  • nsh_platform_macos::AppOptions::notifications: bool — the view's app owns the process's notifications.
  • nsh_platform_windows::AppOptions::notifications: bool — same, on Windows.
  • nsh_platform_linux::AppOptions::notifications: bool — same field for one shape on the desktops; run_app sets it.

Behavior change (not API): on macOS and Windows, an AppView a host makes no longer has notifications unless it sets the field.

Docs: docs/dev/embedding.md, the macOS / Windows guides (en, zh-CN) and the Notifications platform table.

Not covered

  • The GPUI backend has no notifications at all; separate work.
  • No tests/compat case: the field is embedder (Rust host) API, not something apps use.

Verification

  • Linux: cargo clippy on the Linux crates, fmt.
  • macOS / Windows: compiled by CI. Runtime check on Windows (Omarchy's Windows VM) and on a Mac still to do.

🤖 Noop (rust-maintainer) · AI agent acting for @huacnlee

🤖 Generated with Claude Code

huacnlee and others added 3 commits November 5, 2026 20:23
An app that makes its own AppView instead of calling run_app had no
notification delegate on macOS (no banners in front, lost presses) and no
AppUserModelID or activator on Windows (nothing showed). macOS now installs
the delegate when an AppView is made, keeping one the host set; Windows
starts toasts for a top-level AppView unless the process has an id of its
own.

Agent: rust-maintainer
…-notifications

# Conflicts:
#	crates/nsh-platform-windows/src/app.rs
An AppView a host makes used to take the process's notifications on its
own: on Windows it set the process's AppUserModelID (and with it the
taskbar grouping of the host's own windows), on macOS it took the
notification center's delegate. The process is the host's, so that is
now its choice: AppOptions::notifications hands them to the view's app,
and run_app sets it. Without it the permission is unavailable, show
resolves false and the badge stays the host's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@huacnlee huacnlee changed the title notifications: Work in a host's own AppView on macOS and Windows desktop: Let a host hand its notifications to the app it embeds Nov 6, 2026
@huacnlee
huacnlee marked this pull request as ready for review November 6, 2026 03:25
@huacnlee
huacnlee merged commit 6fb3a08 into main Nov 6, 2026
11 of 12 checks passed
@huacnlee
huacnlee deleted the agent/T-0455-embedded-notifications branch November 6, 2026 03:26
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