notify-rust
notify-rust copied to clipboard
hoodie
Notification Listeners for Mac and Windows
Problem
We are building a Slack/Discord like chat client (linen.dev) with Tauri. The problem is we don't have any notification listeners for Mac and windows so that we know which notification they click on so we can show the proper channel/thread.
Describe the solution you'd like
According to this windows and mac listeners are not implemented https://docs.rs/notify-rust/latest/notify_rust/#notificationhandle
Additional context
https://github.com/tauri-apps/tauri/issues/3698
For mac we ran into issue with https://github.com/h4llow3En/mac-notification-sys because was blocking which spiked cpu usage to 100% when we received a notification and it would stay at 100% until we closed the notification.
💎 $300 bounty created by @cheeseblubber 👉 To claim this bounty, submit your pull request on Algora 📝 Before proceeding, please make sure you can receive payouts in your country 💵 Payment arrives in your account 2-5 days after the bounty is rewarded 💯 You keep 100% of the bounty award 🙏 Thank you for contributing to hoodie/notify-rust!
Full Disclaimer: this library can only do what the underlying operating-system primitives actually provide.
@cheeseblubber can you show what you were doing that cause the 100% CPU usage on macOS? AFAIK the sending should not block already.
hi @hoodie, this is what we were doing https://github.com/Linen-dev/linen.dev/blob/51406feb8f27c95081d36f4ee2cc9139caec25c0/packages/spa/src-tauri/src/notifications.rs#L29 with was with the mac_notification_sys lib not notify-rust.
CPU went to 100% until we dismiss the notification. This is how we call the function https://github.com/Linen-dev/linen.dev/blob/51406feb8f27c95081d36f4ee2cc9139caec25c0/packages/spa/src-tauri/src/main.rs#L75
This was the only workaround we find to know in which notification the user clicked.
Windows implementation blocked on this pull request to tauri-winrt-notification, a dependency of notify-rust.
mac-notification-sys is using the old foundation user notifications API which deprecated. Updating this crate is a huge change and breaking the BC. So I decided to write a crate by my own using the new User Notifications framework. I hope to manage notifications using a Stream like api. Currently the mac-notification-sys is using a loop to listen for notification changes.
Also the new notification framework is only supporting action buttons for notification categories. But I think we can internally manage those categories without changing the existing API of notify-rust.
UPDATE:- Updating to the new notification framework was already in the TO DO list of mac-notification-sys. So I decided to send a PR instead creating a new crate.
@whizsid that sounds great. Looking forward to that. I was actually starting to rejuvenate mac-notification-sys a little. But I'm afraid we really ought to implement the new UNNotificationCenter api finally. Since I'm not a very experienced objective-c, nor macOS Desktop developer I appreciate any help and contribution I can get.
Looked into this one and it's very hard to do this without uprooting the whole library. For this to work on macOS, we would need to somehow ensure execution on the main thread, which is difficult without knowing whether the dependent project uses Tokio or not. It'd add a whole lot of hassle to using this library.
Can we at least document a recommended alternative for Windows and macOS users?
@mogery that's why I've avoided tackling this for so long. It's a tiny bit to complex to do on an on/off after-work kind of timeplan. Interestingly enough though it seems like the zed editor's implementation (native macos) might contain some good references on how to interact with the mac runtime in an async fashon.