- Rich toasts set a WinRT Tag (hash of the web notification tag, since
room:thread tags exceed the 64-char limit) in a fixed Group, so a newer
toast for the same room/thread replaces the older one instead of
stacking; the replaced toast's keep-alive entry is dropped (#16).
- The bridge passes tag, roomId and threadId separately. The reply target
is the real room id (+ thread), never the coalescing tag, which was
`room:thread` for threads and `lotus-invites` for invites, so those
replies failed silently. Toasts with no room id (invites) get no reply
box (#17).
- New `get_focus_assist` command serves the latest Focus Assist poll so
the web hook can hydrate on mount; the setup-time first emit was lost
before the page listened (#15).
- Bump cinny to 3b6de2fd (the matching web-side hooks).
Closes#15, #16, #17
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
- toast.rs: Windows.UI.Notifications rich toast (reply input + Send action);
in-process Activated event → emit lotus-notification-activate {path} (click) /
lotus-notification-reply {roomId,text}. Falls back to tauri-plugin-notification
(WinRT error / non-Windows). The NOTIFICATION_BRIDGE now routes notifications
carrying a roomId (tag) to show_rich_toast. Features: UI_Notifications,
Data_Xml_Dom, Foundation_Collections.
- focus_assist.rs: SHQueryUserNotificationState poll thread → emit
focus-assist-changed {active} on QUNS_QUIET_TIME/PRESENTATION/D3D_FULLSCREEN/BUSY.
No new Cargo features.
CI Windows compile pending (no local Rust toolchain). Runtime caveat: WinRT toasts
need a Start-menu shortcut + matching AppUserModelID (org.lotusguild.lotus-chat);
without it CreateToastNotifier errors and the code falls back to the plugin.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>