starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Send Desktop Notification via VT Sequence (OSC777) #10742

New Issue
Open
opened 2026-01-31 02:29:09 +00:00 by claunia · 14 comments
claunia commented 2026-01-31 02:29:09 +00:00
Owner
Copy Link

Originally created by @skyline75489 on GitHub (Sep 24, 2020).

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.

Originally created by @skyline75489 on GitHub (Sep 24, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement On macOS there's [terminal-notifier](https://github.com/julienXX/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. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) The terminal-wg has not finalized a spec for this feature. The issue is [here](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/13). The implementation is leaning towards using OSC 9/99/777. <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeatureHelp WantedIn-PRArea-VTProduct-Terminal labels 2026-01-31 02:29:09 +00:00
claunia commented 2026-01-31 02:29:10 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 24, 2020):

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 commented on GitHub (Sep 24, 2020): > 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
claunia commented 2026-01-31 02:29:10 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 24, 2020):

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

@WSLUser commented on GitHub (Sep 24, 2020): Also see https://github.com/microsoft/WSL/issues/2466#issuecomment-370681421
claunia commented 2026-01-31 02:29:11 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 25, 2020):

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. 😄

@DHowett commented on GitHub (Sep 25, 2020): 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:
claunia commented 2026-01-31 02:29:11 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Sep 25, 2020):

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 😄 )

@skyline75489 commented on GitHub (Sep 25, 2020): 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 😄 )
claunia commented 2026-01-31 02:29:11 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 17, 2020):

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".

@j4james commented on GitHub (Oct 17, 2020): 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".
claunia commented 2026-01-31 02:29:11 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Oct 18, 2020):

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

@skyline75489 commented on GitHub (Oct 18, 2020): 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 iOS<https://aka.ms/o0ukef>
claunia commented 2026-01-31 02:29:11 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 18, 2020):

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.

@j4james commented on GitHub (Oct 18, 2020): 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.
claunia commented 2026-01-31 02:29:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 18, 2020):

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

@zadjii-msft commented on GitHub (Oct 18, 2020): > 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](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/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. <hr> _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](https://adaptivecards.io/) 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. <hr> [This doc](https://chromium.googlesource.com/apps/libapps/+/master/hterm/doc/ControlSequences.md#OSC) was also intriguing, had a good list of OSCs supported by `hterm`
claunia commented 2026-01-31 02:29:12 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 18, 2020):

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.

@j4james commented on GitHub (Oct 18, 2020): > 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](https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC)). Also I _think_ `OSC 777` is a little more widely supported, although I'm not certain of that.
claunia commented 2026-01-31 02:29:12 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Oct 18, 2020):

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.

@WSLUser commented on GitHub (Oct 18, 2020): > 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.
claunia commented 2026-01-31 02:29:12 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Nov 6, 2020):

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?

@skyline75489 commented on GitHub (Nov 6, 2020): I've done more research and found that OSC 777 is more complicated that I thought. Per the [documentation](https://manpages.debian.org/testing/rxvt-unicode/urxvt.7.en.html) 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?
claunia commented 2026-01-31 02:29:13 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 6, 2020):

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.

@j4james commented on GitHub (Nov 6, 2020): 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.
claunia commented 2026-01-31 02:29:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 23, 2022):

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 commented on GitHub (Sep 23, 2022): 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`
claunia commented 2026-01-31 02:29:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 21, 2022):

fhl-7718-prototype-000

fhl-7718-prototype-001

@zadjii-msft commented on GitHub (Nov 21, 2022): ![fhl-7718-prototype-000](https://user-images.githubusercontent.com/18356694/203159786-108b2e4b-1a75-4728-ae1d-fba26fe672e0.gif) ![fhl-7718-prototype-001](https://user-images.githubusercontent.com/18356694/203173211-e83b6bdf-3eb8-46c5-bc2f-25a69a119722.gif)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Help Wanted In-PR Issue-Feature Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#10742
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?