Send Desktop Notification via VT Sequence (OSC777)

[skyline75489]

Description of the new feature/enhancement

On macOS there's terminal-notifier. On Linux there's notify-send. But on Windows I don't think there's a similar tool. Adding the support for desktop notification in WT would help scripts/TUI apps to send notification without too much hassle.

Proposed technical implementation details (optional)

The terminal-wg has not finalized a spec for this feature. The issue is here. The implementation is leaning towards using OSC 9/99/777.

[WSLUser]

But on Windows I don't think there's a similar tool

You have Win-Toast (this is what provides Desktop notifications in Win 10) https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/scheduled-toast

[WSLUser]

Also see https://github.com/microsoft/WSL/issues/2466#issuecomment-370681421

[DHowett]

I'd rather leave this as a gap to be filled by third parties than add support for notifications in Terminal. The world is awash with notifications -- websites ask, desktop apps have them, mobile apps spam you with ads even though they shouldn't -- and I don't want to contribute to that.

If a 3rd party wants to write a notifier, they're more than welcome to. :smile:

[skyline75489]

Thansk @WSLUser for the very useful info. @DHowett That is actually a fair point. I'll close this. I think this thread is helpful for those who want the world to be even noisier (I'm not one of them. I'm just interested in those cool VT sequences 😄 )

[j4james]

Just to be clear, if someone came up with a PR adding support for something like OSC 777, would that be rejected? I'm not sure what is meant when you say a 3rd party is welcome to write a notifier. Does that mean it would have to be via a WT extension?

I understand some people may not like notifications, but since Windows lets you disable them on a per-app basis, that doesn't seem like it should be a big deal.

Not that I'm that desperate for this functionality, but I can see how it would be useful. I was about to suggest this as a possible solution for #7955, but that's clearly not an option if it's a definite "wont-fix".

[skyline75489]

I think what Dustin mean is a third party cli app that invokes the notification API of Windows, without the modification from the terminal side.

获取 Outlook for iOShttps://aka.ms/o0ukef

[j4james]

How would that work over a remote connection though? The use case for this is when you've ssh'ed onto a remote machine that's executing a long running job, and you want to be notified when the job completes. It may not even be a Windows machine. You need an interoperable way for your job to let the local machine know that it's done.

Personally I can get by with just outputting a BEL, but I can see the appeal of having something more explicit that lets you know exactly what happened. There are any number of reasons you might hear a BEL, and you could also have multiple jobs that you're waiting on. Anyway, not essential for me. It just seemed weird to outright ban the feature.

[zadjii-msft]

How would that work over a remote connection though?

And that's all I needed to hear to justify this request IMO. I wouldn't reject a PR that implements that. It looks like there hasn't been a lot of progress in terminal-wg#13 unfortunately, and with Egmont out of the terminal game I doubt there will be any. Looks like kitty implemented OSC 9 and the in-progress OSC 99 (see https://github.com/kovidgoyal/kitty/issues/1474#issuecomment-678337744), though, since 99 was a spec in progress, I'd rather stick with the OSC777 / OSC9 implementations, to keep it simple.

---

aside: The Windows 10 notification system is fairly elaborate, and it allows apps to put fairly rich content into the notification. Maybe at some point in the future, we might want to design a sequence for something like letting a user encode an adaptive card in a notification. Adaptive Cards might be a good solution there for x-plat rendering of the notification. That's more of a 2025 dream though - let's focus on the basics for now.

---

This doc was also intriguing, had a good list of OSCs supported by hterm

[j4james]

I'd rather stick with the OSC777 / OSC9 implementations, to keep it simple.

+1 to this. And if we're just going to choose one, I'd have a slight preference for OSC 777, since iTerm2's OSC 9 conflicts with ConEmu, which uses OSC 9 for other purposes (see here). Also I think OSC 777 is a little more widely supported, although I'm not certain of that.

[WSLUser]

we might want to design a sequence for something like letting a user encode an adaptive card in a notification

Doesn't Uno provide something like this for apps? I was thinking we could move this project towards using Uno at some point to allow UI of choice to be used on any platform (even rooted phones). The notification system should be part of that UI framework. The biggest holdup to that is the VT support in Terminal itself but we're slowly getting there.

[skyline75489]

I've done more research and found that OSC 777 is more complicated that I thought.

Per the documentation of urxvt, OSC 777 actually "call the perl extension with the given string, which should be of the form extension:parameters". So to make OSC 777;notify work, you actually need to write a perl script in /usr/lib/urxvt/perl/notify. Then urxvt will call the script once it receives the OSC 777;notify sequence.

I think this is more of a plugin sequence instead of just for notification. However I doubt that hterm would really support such level of extensibility because it only support "notify". But should we also limit 777 to notification? Is it just me, or it feels somewhat wasteful and not faithful to the original design of this sequence?

[j4james]

I don't think you need to get too hung up on the implementation details of urxvt. We're not trying to implement their plugin system - just this particular sequence (much like we're doing the 9;4 command from Conemu's OSC 9). I think the main thing is to make sure we're compatible with the various shells that use the sequence for command completion notification, and to make sure we handle the notifications the same way as other terminals.

I haven't looked at this in much detail, but I believe the sequence is supported by quite a few terminals other than urxvt and hterm, including Terminology, Tilix, Contour, and at least some builds of Gnome Terminal (I know the Fedora/RedHat distribution patched their VTE to support it).

It's also worth mentioning that the notifications are only expected to be displayed when the terminal is in the background (at least that's my understanding). I think what happens is the shell generates a notification after every command, but you obviously don't want to see all of those notifications when you're just doing something like a directory listing. But if you execute a long running command, and switch to another window (or another tab), then you should get a notification when that command eventually completes.

[zadjii-msft]

quick notes:

• The toast notification sample is definitely hard to read, but miles better than it was last time I checked. It works in the scratch app, without another dependency.
• Clicking on a notification spawns a second Terminal instance. We'll have to communicate back to the sender.
• Seems doable with the ToastNotificationActivatedEventArgs and getting the actual startup args the way I did in early #878 experiments.
• We'll need a static method off WindowManager to call to a monarch if one exists, without creating one.

Cause this involves a bunch of Remoting work for trying to activate the original window, I'm pulling good first issue.

see dev/migrie/fhl/7718-notifications

[zadjii-msft]