* 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>
* feat(notification): report actions on desktop
A click on a notification (tap) or on one of the actions of its action
type now reaches the JavaScript onAction listeners on desktop, and the
new Rust Notification::on_action on every platform. On Linux and the
BSDs the click comes from the notification server's ActionInvoked
signal; on Windows and macOS from notify-rust's wait_for_response,
which needs notify-rust 4.18.
register_action_types, remove_active (Linux and the BSDs) and the
listener commands are implemented for desktop, so they no longer fail
with "command not found".
The api example sends a notification with two actions and shows the
action it hears.
Closes#2150, closes#1903.
* fix(notification): complete desktop action API
* cleanup
---------
Co-authored-by: Haex <hexxx@ok.de>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* Add WebviewWindow to code docs
* Shorten the WebView Name
* Apply suggestions from code review
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
