Feature Request: Notification API

[jag-k]

Please, add a Notification API support 🙏

[SKaplanOfficial]

This is an overall good idea, imo, but it might be more worthwhile to point people toward node-notifier. Apple’s UserNotifications framework has some annoying limitations, such as not being able to (easily) customize the notification icon, which node-notifier/terminal-notifier have already overcome. A custom implementation for Raycast would probably use the same tactics in the end (i.e. using a separate app bundle for the notification system and dynamically updating the icon within that app’s bundle).

Perhaps a reasonable solution would be to build an interface on top of node-notifier so that developers can use Images and Colors from the Raycast API.

[mathieudutour]

What would be the use case for it, and how would it differ from the Toast/HUD API that we provide?

[jag-k]

In my case(s) it’s useful for sending notifications about new messages from background tasks like updating menu bar or no-ui command.

I’ve tried to use node-notifier/terminal-notification, but them not working perfectly (not opening Raycast command or I can’t handle reply from the message).

And this solutions needs extra installation for working and giving them rights to excecute (ctrl+click on app -> Open -> Open Anyway). This workflow is not user friendly

[mathieudutour]

What kind of messages? Why are the HUD not enough?

[SKaplanOfficial]

One use case for me would be to provide actionable updates on async/long-running tasks, for example in my Image Modification extension I'd like to provide notifications when conversion/filter application/etc. is finished, allowing users to click the notification and open the result, copy it to the clipboard, and so on. Would also be useful to provide ways to recover from failures without requiring the user's constant focus on the Raycast window.

HUD doesn't provide the interactivity I'd like, and Toast isn't viable in the situation I'm envisioning, where users are not actively looking at the Raycast window. Native notifications seem like a good solution as they don't require re-inventing the wheel, users are already familiar with how they function, and using them aligns well with Raycast's emphasis on being a native macOS app.

[mathieudutour]

The issue with notification is with regards to the lifecycle of the extensions. We would have to keep the context of the extension in memory until the notification is cleared (or you'd have to deal with some sort of notification ID/payload and the API would be a pain). And that's not something we want to do.

Something we could envision is being able to click on the HUD to "transform" it (eg. open raycast and show it as a toast) to be able to add actions and more details

[SKaplanOfficial]

I see your point, though I wonder if Deeplinks with Launch Context already provide a way to avoid some of those headaches -- i.e. instead of keeping the extension loaded in memory, offload it and have notifications start a new session of the extension with data communicated via launch context, and maybe a new notification launch type.

That said, I'd be happy with an updated HUD as you mentioned. I mostly just want a way to intuitively surface available options to users.

[KevinBatdorf]

I use notifications in a background command to notify the user when something happens (in this case when their code is deploying). Notifications are expected behavior for something like this and arent as distracting in my opinion as the HUD notice appearing.

Currently I fire a notification like this, but something native with a custom icon and actions would be nice (or even without the actions): https://github.com/KevinBatdorf/laravel-forge-raycast/blob/44fa7f97be4c69736578ef1ce9b075eda3b36755/src/check-deploy-status.tsx#L36

But yeah, I have no idea the technical challenges in supporting that at the OS level. Just giving feedback.

[mathieudutour]

Ideally, we don't want the dev to worry about what kind of mechanism they use to give feedback to the user. It should be a implementation detail and Raycast should take care of showing what's the most appropriate.

Notifications are expected behavior for something like this and arent as distracting in my opinion as the HUD notice appearing.

That's exactly what we don't want to happen, 1/3 of the extensions using toast, 1/3 using HUD, 1/3 using notifications - without the user knowing what to expect.

What we will probably end up doing is deprecating showHUD in favour of a single showToast which will handle the presentation mode under the hood

[KevinBatdorf]

Raycast provides two different experiences though, one with user interaction, and another in the background.

The toast and HUD make sense when the user is interacting with Raycast. It's there in front of them and they took action to open the application. They expect the feedback to be in the context of the application itself (toast, HUD, etc). In my opinion the HUD should only be used when you take an action with Raycast that closes the application (the user is done interacting with Raycast). And Toast is for when Raycast is to remain open (the user is still doing stuff).

With the background process, in contrast, the user hasn't interacted with Raycast (perhaps not even for weeks/months), so the experience is different. A toast or HUD notice is out of context here. A native notification, or some sort of red dot (to indicate activity) on the menubar icon are more useful in this context.

What we will probably end up doing is deprecating showHUD in favour of a single showToast which will handle the presentation mode under the hood

Just my two cents here, but I'd suggest having a showNotification that combines the HUD and native notifications, and knows which to show based on context. Then separately replace showToast with something more like setStatus or something to indicate it's updating the status area in Raycast. Maybe this is where you were going with that already though.

[mathieudutour]

Raycast provides two different experiences though, one with user interaction, and another in the background.

Yeah but from a dev point of view, it shouldn't matter - Raycast should know better what to do to be consistent