Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Notification API #15

Open
jag-k opened this issue Jun 4, 2023 · 11 comments
Open

Feature Request: Notification API #15

jag-k opened this issue Jun 4, 2023 · 11 comments

Comments

@jag-k
Copy link

jag-k commented Jun 4, 2023

Please, add a Notification API support 🙏

@SKaplanOfficial
Copy link

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
Copy link
Member

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

@jag-k
Copy link
Author

jag-k commented Jun 19, 2023

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
Copy link
Member

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

@SKaplanOfficial
Copy link

SKaplanOfficial commented Jun 19, 2023

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
Copy link
Member

mathieudutour commented Jun 19, 2023

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
Copy link

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
Copy link

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
Copy link
Member

mathieudutour commented Jun 19, 2023

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
Copy link

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants