Desktop notifications (OSC 9/99/777)

[hhirtz]

Hi!

I would like to add support for desktop notifications to tcell and allow applications to trigger notifications via the terminal.

Motivation

Would be nice to lift off the keyboard focus logic from the application/end user to the terminal (i.e. let the terminal not send the notification if it has focus).

Specs and implementations

There are several OSC for this (of course..) and each terminal implement the one it wants..

OSC 9

ITerm Growl notifications

Implementors: ITerm (need ref), kitty, foot libvte swallows the escape

ESC ] 9 ; [message] \a

NB: it conflicts with ConEmu's specific OSC but it shouldn't be a problem for tcell

OSC 99

Comes from terminal-wg but since they wouldn't decide kitty went and implemented its thing.

Implementors: kitty

ESC ] 99 ; d=0 ; [title] \a ESC ] 99 ; p=body ; [body] \a

OSC 777

Comes from this little urxvt perl extension (yes), more context in this article.

Implementors: urxvt (with the notify extension), foot, contour libvte swallows the escape

ESC ] 777 ; notify ; [title] ; [body] \a

Users

These OSCs are already exploited in the wild:

• TODO, I haven't looked much :s

Design proposal

This depends on a ((hopefully) upcoming) refactor of TParm to allow string parameters in escapes: https://github.com/gdamore/tcell/pull/468#discussion_r716229050

Add a member in terminfo, e.g.:

        Notify:  "\x1b]777;notify;%p1;%p2",

and two methods to Screen:

type Screen interface {
        // ...

        // HasNotifications returns true when the terminal accepts
        // desktop notifications from applications.
        HasNotifications() bool

        // Notify send a desktop notification to the terminal. Note
        // that the terminal may refuse to show this notification
        // (e.g. if it has keyboard focus).
        Notify(title, body string)
}

[dnkl]

Note that foot supports OSC-9 as well (in addition to 777, as already mentioned above).

[hhirtz]

Updated

[gdamore]

It sure would be nice if these various terminals -- many of which simply leverage xterm-256color or something -- could come up with some common standards.

It's hard to keep up with all the various local escape sequences that each terminal either does or does not support.

[WSLUser]

So I think the biggest consensus is with OSC 777. Windows Terminal plans on supporting it at some point just based on sheer fact that more terminals support it than the other niche OSC sequences for the same result. Also ConEmu is incompatible with OSC9 due to re-using it for another purpose. So the trend really is "stick with OSC 777 for desktop notifications". See https://github.com/microsoft/terminal/issues/7718#issuecomment-723319227

[gdamore]

I'll probably do this as an OSC 777... Hopefully there won't be surprises for other terminals.

It's easier to be generous on the input, but I would prefer to be more cautious when emitting things that are not standardized in case it breaks someone terminal.

[gdamore]

Note that iTerm puts LC_TERMINAL into its environment. I have mixed feelings about this -- one the one hand it's very helpful since it discriminates iTerm from the rest. But on the other hand, the "right" solution is IMO to define a $TERM properly and not keep relying on xterm-256color. But I also understand the pragmatic reasons that they have done this -- it's hard to get everyone to update their terminfo/termcap databases....

[gdamore]

Given that, if more of these xterm256-colors "pretenders" would use the LC_TERMINAL hack to identify the specific flavor, I'd find it very helpful.

[delthas]

Is there a way to dynamically know about OSC 777 support by looking at the dynamic/on-disk terminfo?

[bjorndm]

This feature would probably be better in a separate library like: https://github.com/martinlindhe/notify. Then it doesn't depend on the capabilities of the terminal at all.

[WhyNotHugo]

On Tue, 15 Aug 2023, at 09:58, bjorndm wrote:

This feature would probably be better in a separate library like: https://github.com/martinlindhe/notify. Then it doesn't depend on the capabilities of the terminal at all.

What you’re suggesting shows a notification on the host where the application is running. The approach in this issue shows a notification on the host where the terminal is running.

These may be different hosts (eg: when running an application over ssh).

[bjorndm]

That's true, I didn't consider the remote case. Sorry for missing the point.

[gdamore]

For the record, ConEMU is so bad right now that I cannot use it in vte mode. I don't recommend it. I'm not going to implement any improvements for ConEmu until they fix their bug with automargin wrapping causing the colors (but not the text!) to scroll when updating the last cell in the terminal.

I will consider the rest of these -- I have made some significant enhancements to tcell lately and these might fall in scope.

[gdamore]

Well, experimentally I'm finding this really not very useful on pretty much any of the terminal emulators I use the most.