How to establish external timeout for notify-rust - rust

Question

I'm trying to use notify-rust library on Ubuntu 20.04, but the notifications that are emitted have unpredictable timeouts. Also, if I send several notifications with short delays between them, the results may vary (sometimes I see all notifications, sometimes only several of them).
The workarounds I applied:
Critical Urgency, so the notifications would stay displayed forever.
Wait for an action before displaying the next notification, so no notifications would be lost.
// add `notify-rust = "4"` to dependencies for this code to work
use notify_rust::{Notification, Urgency};
use std::{thread, time};
fn main() {
let summaries = ["one", "two"];
for summary in summaries {
let handle = Notification::new()
.summary(summary)
.urgency(Urgency::Critical)
.show()
.unwrap();
// helps displaying all the notifications
handle.wait_for_action(|_action| ());
// delay might vary
thread::sleep(time::Duration::from_millis(10));
}
}
I also experimented with the lib's timeout, but didn't get any good results.
The primary issue with the wait_for_action approach, is that sometimes no notification is seen on the screen after it was sent, so the main thread is waiting for an action on that notification that would never happen (nothing to click on).
I want to try a watchdog approach: start a thread, send the notification handler into it, and close the notification after some timeout:
let handle = Notification::new()
...
let thread_handle = handle.clone();
thread::spawn(move || {
thread::sleep(time::Duration::from_secs(60));
thread_handle.close();
});
handle.wait_for_action(|_action| ());
I'm not sure how to do that part. I can't use handle both for the thread and for wait_for_action, because the thread takes the ownership. Cloning doesn't work properly, instead of NotificationHandle it produces Notification.
Is there any way to solve this without dip dig into notify-rust library internals?
I think I can resolve this using the whole different approach that won't involve calling blocking wait_for_action, but I wonder if there is any more elegant solution?

Answer 1

I came up with another algorithm for notifications and timeouts: instead of relying on wait_for_action being able to catch an event of a notification being closed, I created two threads:
one with the same wait_for_action that on completion sends a message through a channel
another thread that waits for some time and then sends the same message through the same channel
The main thread waits for the message and continues as the first message arrives.
use notify_rust::{Notification, Urgency};
use std::sync::mpsc;
use std::{thread, time};
fn main() {
let summaries = ["one", "two"];
for summary in summaries {
// establish the channel and a second transmitter for `timeout` thread
let (handler_tx, rx) = mpsc::channel();
let timer_tx = handler_tx.clone();
// no changes here
let handler = Notification::new()
.summary(summary)
.urgency(Urgency::Critical)
.show()
.unwrap();
// `wait_for_action` is wrapped into a thread
thread::spawn(move ||
handler.wait_for_action(|_action|
handler_tx.send(()).unwrap_or(())
)
);
// another thread that waits and then sends the same message
thread::spawn(move || {
thread::sleep(time::Duration::from_secs(7));
timer_tx.send(()).unwrap_or(());
});
// the main thread that waits for a message from any of senders
rx.recv().unwrap();
thread::sleep(time::Duration::from_millis(10));
}
}
Results of message sending are ignored on purpose: only one of those messages could be sent successfully, then the channel goes out of scope and another sender gets an error, and that's fine.
The solution has a disadvantage: it's possible that after the timeout, another notification would be sent without waiting for the previous one to be closed. I saw those notifications still can be displayed after the first one be closed even if the main thread finished, so they were waiting on the notification bus.
I also noted that there is another method implemented for NotificationHandler that probably suits better this task: on_close, but it is implemented using wait_for_action, so it's also blocking, and I can't implement notification close after timeout using this method.