mirror of
https://github.com/tauri-apps/plugins-workspace.git
synced 2026-10-18 23:07:27 +02:00
* experimenting... Signed-off-by: BestCodes <106822363+The-Best-Codes@users.noreply.github.com> * omit unconfirmed fact from .changes Signed-off-by: BestCodes <106822363+The-Best-Codes@users.noreply.github.com> * fix(notification): send untracked Linux notifications on the shared connection Holding notify-rust's handle with `on_close` blocked an async runtime worker until the server closed the notification, and opened a D-Bus connection per notification. Since GNOME keeps notifications in its tray, a handful of them could stall every async task of the app. Send every notification on the connection the plugin already keeps open for its action listener instead: it keeps the sender's name alive for GNOME at the cost of a single connection and thread, and the listener runs the `on_close` callbacks. * fix(notification): offer `on_close` on the BSDs too The BSDs share the D-Bus implementation with Linux, including the GNOME issue, so gate `NotificationBuilder::on_close` like the rest of that implementation and document when the callback runs. * fix(notification): run `on_close` without the tracker lock held The callback ran on the listener thread while the guard of the callback map was alive, and a panic in it ended that thread, which then reported no action of any notification for the rest of the app's life. Take the callback out of the map before running it and contain its panics. * fix(notification): use the covector package names in the change files `tauri-plugin-notification` and `@tauri-apps/plugin-notification` are not packages of .changes/config.json, so covector refused the change file. Use `notification` and `notification-js`, and record the new `on_close` API as a feature of its own. Also let `on_close` take an `FnOnce`, since it runs at most once. --------- Signed-off-by: BestCodes <106822363+The-Best-Codes@users.noreply.github.com> Co-authored-by: Lucas Nogueira <lucas@tauri.app>