Closed denispeplin closed 3 months ago
The current way this is implemented is not ideal. You're thread solution is basically state-of-the-art of what is possible right now I'm afraid. We could add a mechanism that uses channels to notify-rust, but ultimately that would also require a thread. Alternatively there is an experimental async version on a branch somewhere, but that's not done yet unfortunately.
The only thing I really miss here is an ability to close the notification on timeout. But for now, I can live without it.
but that should be the default behaviour of .timeout()
If I wanted to close a notification from my "external timeout" thread, I would need a handler, which is unavailable because it's being used by on_close
.
The whole reason why I'm using the external timeout is that I wasn't able to reliable set up .timeout()
.
Do you need the critical
urgency btw? I think that is specified to make the notification stick around. I only just noticed that in your SO post
Yep, I need it. Otherwise, notifications are being closed pretty quickly with random timeouts (and using .timeout()
doesn't help).
Maybe it's just my OS that behaves so weird, but critical
helped to resolve that.
I found that on Ubuntu 20.04 I can't really control timeouts and to control timeouts better I have to use
Urgency::Critical
and thenwait_for_action
. I also found, that on the same system, a notification sometimes could be sent but not being displayed, so my program stuck waiting for an action on a notification that was never displayed. Bothwait_for_action
andon_close
are blocking (means the issue is related a bit to #36), and also I can't cloneNotificationHandler
. My partial solution to those issues it's not a perfect one, since while I introduced an external timeout, I can't close a notification after my process times out. My attempt to ask on Stackoverflow didn't give any results apart from the solution I was able to find myself.Any thoughts?