Suggestion: ability for terminals to set their tab icon #2633

@DHowett-MSFT commented on GitHub (Jul 8, 2019):

OSC I seems fine; in the general case there is no “shortcut to the application” in unixen, so it must be referring to the window icon.

I don’t think we need to engineer a push/pop for it, though, because there isn’t one for SGR DECCOLM DECSCUSR (and so on)

@DHowett-MSFT commented on GitHub (Jul 8, 2019): `OSC I` seems fine; in the general case there is no “shortcut to the application” in unixen, so it must be referring to the window icon. I don’t think we need to engineer a push/pop for it, though, because there isn’t one for SGR DECCOLM DECSCUSR (and so on)

claunia commented

@zadjii-msft commented on GitHub (Jul 8, 2019):

@DHowett-MSFT Good point about the push/pop thing - maybe we just need a "restore to default" value too.

How about: WTSICO - Windows Terminal Set Icon

OSC Ps ; Pt ST            
            Ps = 10000  -> Change tab Icon to the file specified by absolute path in Pt. If Pt is omitted, restore the icon to its default value.

Anyone know if OSC 10000+ is taken by anything? @Jaykul @j4james may know.

@zadjii-msft commented on GitHub (Jul 8, 2019): @DHowett-MSFT Good point about the push/pop thing - maybe we just need a "restore to default" value too. How about: `WTSICO` - Windows Terminal Set Icon ``` OSC Ps ; Pt ST Ps = 10000 -> Change tab Icon to the file specified by absolute path in Pt. If Pt is omitted, restore the icon to its default value. ``` Anyone know if OSC 10000+ is taken by anything? @Jaykul @j4james may know.

claunia commented

@egmontkob commented on GitHub (Jul 8, 2019):

"icon name" is indeed a pretty misleading terminology; it should probably be called "icon title". It's the string shown next to the icon whenever the window is iconified. In traditional Unix desktops, a window can have two different titles: one shown when in normal state, and another when iconified. OSC 1 sets the latter, OSC 2 sets the former, while OSC 0 sets both. Icon title is an ancient concept not really existing in modern environments. For this reason, VTE (gnome-terminal) dropped support for the icon title (icon name) feature recently.

I'm not aware of any extension regarding a graphical icon, although the idea is nice and there should be one. However, I dislike the idea of referring to the file with its path, this by design cannot work (or can even lead to incorrect result) over ssh. The icon itself should be transmitted (which raises a bunch of new questions).

For push/pop: there's CSI 22t and CSI 23t although CSI ... t has a pretty bad design: any number from 24 means to resize to that many rows, that is, it cannot be extended to allocate new numbers for saving/restoring the icon. Maybe 22/23 could also save/restore them, although it's probably not a wise idea.

@egmontkob commented on GitHub (Jul 8, 2019): "icon name" is indeed a pretty misleading terminology; it should probably be called "icon title". It's the string shown next to the icon whenever the window is iconified. In traditional Unix desktops, a window can have two different titles: one shown when in normal state, and another when iconified. OSC 1 sets the latter, OSC 2 sets the former, while OSC 0 sets both. Icon title is an ancient concept not really existing in modern environments. For this reason, VTE (gnome-terminal) dropped support for the icon title (icon name) feature recently. I'm not aware of any extension regarding a graphical icon, although the idea is nice and there should be one. However, I dislike the idea of referring to the file with its path, this by design cannot work (or can even lead to incorrect result) over ssh. The icon itself should be transmitted (which raises a bunch of new questions). For push/pop: there's CSI 22t and CSI 23t although CSI ... t has a pretty bad design: any number from 24 means to resize to that many rows, that is, it cannot be extended to allocate new numbers for saving/restoring the icon. Maybe 22/23 could also save/restore them, although it's probably not a wise idea.

claunia commented

@j4james commented on GitHub (Jul 9, 2019):

Anyone know if OSC 10000+ is taken by anything?

I know mintty has one documented OSC above 10000 (77119), but I don't know of anyone using the 10xxx range specifically. I don't have that wide a knowledge of terminal implementations, though, so I couldn't say with any certainty.

@j4james commented on GitHub (Jul 9, 2019): > Anyone know if OSC 10000+ is taken by anything? I know mintty has one documented OSC above 10000 ([77119](https://github.com/mintty/mintty/wiki/CtrlSeqs#wide-characters)), but I don't know of anyone using the 10xxx range specifically. I don't have that wide a knowledge of terminal implementations, though, so I couldn't say with any certainty.

claunia commented

@mikemaccana commented on GitHub (Jul 11, 2019):

It would be worth finding out if/how modern Unix desktops and macOS implement OSC I. Ideally software authors could use the same escape sequence everywhere, rather than separate ones for Windows/Mac/Linux etc.

@mikemaccana commented on GitHub (Jul 11, 2019): It would be worth finding out if/how modern Unix desktops and macOS implement `OSC I`. Ideally software authors could use the same escape sequence everywhere, rather than separate ones for Windows/Mac/Linux etc.

claunia commented

@Jaykul commented on GitHub (Jul 11, 2019):

Right now we've implemented 0, 1, and 2 all the same way (based on xterm's implementation of Tektronix 4014 mode)

There's no purpose in doing it that way. Windows doesn't support the "icon title" notion, so I've been meaning to write up an issue asking permission to change it.

I was going to ask if we can change it to:

0 - window title
1 - icon uri
2 - tab title (may also set the window title, depending on configuration)

If we do that, then the natural thing would be to implement CSI 22 and 23 as enhancements to that, riffing on xterm's implementation:

    Ps = 2 2 ; 0  -> Save window title on stack.
    Ps = 2 2 ; 1  -> Save icon uri on stack.
    Ps = 2 2 ; 2  -> Save tab title on stack.
    Ps = 2 3 ; 0  -> Restore window title from stack.
    Ps = 2 3 ; 1  -> Restore icon uri from stack.
    Ps = 2 3 ; 2  -> Restore tab title from stack.

I think using xterm's icon "title" for the icon uri is pretty safe:

We're not exactly pretending to be xterm-compatible anyway
I can't imagine anyone's setting the icon title separately these days (I know DisplayFusion has an icon mode for apps, but does this actually exist in any mainstream desktops these days?)
If we treat it as a uri, and fail to change when we can't resolve it, then it won't matter if some app tries to set it -- and what we're doing now is wrong, because we're changing the (tab and) window title when the source of the message explicitly avoided doing that.

Oh, and regarding SSH, I think calling this a URI makes it acceptable. I don't want to try to implement transporting base64-encoded image formats in text 😉 and the icon already supports URIs as it is, and although file paths may be part of that, it also supports web URIs like https://www.powershellmagazine.com/wp-content/uploads/2011/11/pscowboy_icon_250x250.jpg as well as portable uri references like ms-appdata:///roaming/Powershell_av32.png and internal icon references like (the horribly named) ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png

@Jaykul commented on GitHub (Jul 11, 2019): Right now we've implemented 0, 1, and 2 all the same way (based on [xterm's implementation of Tektronix 4014 mode](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Tektronix-4014-Mode)) There's no purpose in doing it that way. Windows doesn't support the "icon title" notion, so I've been meaning to write up an issue asking permission to change it. I was going to ask if we can change it to: - 0 - window title - 1 - icon uri - 2 - **tab** title (may also set the window title, depending on configuration) If we do that, then the natural thing would be to implement CSI 22 and 23 as enhancements to that, riffing on xterm's implementation: ``` Ps = 2 2 ; 0 -> Save window title on stack. Ps = 2 2 ; 1 -> Save icon uri on stack. Ps = 2 2 ; 2 -> Save tab title on stack. Ps = 2 3 ; 0 -> Restore window title from stack. Ps = 2 3 ; 1 -> Restore icon uri from stack. Ps = 2 3 ; 2 -> Restore tab title from stack. ``` I think using xterm's icon "title" for the icon uri is pretty safe: - We're not exactly pretending to be xterm-compatible anyway - I can't imagine anyone's setting the icon title separately these days (I know DisplayFusion has an icon mode for apps, but does this actually exist in any mainstream desktops these days?) - If we treat it as a uri, and fail to change when we can't resolve it, then it won't matter if some app tries to set it -- and what we're doing now is _wrong_, because we're changing the (tab and) window title when the source of the message _explicitly **avoided** doing that_. Oh, and regarding SSH, I think calling this a URI makes it acceptable. I don't want to try to implement transporting base64-encoded image formats in text 😉 and the icon already supports URIs as it is, and although file paths may be **part** of that, it also supports web URIs like `https://www.powershellmagazine.com/wp-content/uploads/2011/11/pscowboy_icon_250x250.jpg` as well as portable uri references like `ms-appdata:///roaming/Powershell_av32.png` and internal icon references like (the horribly named) `ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png`

claunia commented

@egmontkob commented on GitHub (Jul 12, 2019):

0 - window title, 2 - tab title

I'm firmly against this idea, for multiple reasons.

One is that existing applications pretty randomly choose to emit OSC 0 or 2 (or 1+2) for changing the title, expecting to overwrite the previous one. This would no longer be the case, resulting in user-perceived broken behavior when an application fails to replace the previous one's title. If separating window and tab titles is desired (which I strongly doubt) then one of them needs to get a brand new escape sequence. There are plenty of free OSC numbers to choose from.

My other concern is: Is this really a desired possibility? Even if applications immediately adapted to the new semantics, would I want this as an app developer (how should I decide what to put where) and would I want this as a user? As a user, my expectation is the window to have the active tab's title (maybe with a fixed prefix or suffix such as "Windows Terminal"). Allowing apps to deviate from this would not help me in any way, but would totally confuse me. I don't think this pattern is seen elsewhere, e.g. documents, web pages etc. all have a single title which becomes the tab and window title (the latter only if this tab is focused, obviously). If a single title per document is good enough for the web, it should good enough for terminal emulation. Furthermore: Many terminals hide the tab bar if only a single tab is present, this would no longer be possible, or a potentially important piece of information (tab title) would be hidden then from the user. Yet furthermore: A natural consequence of introducing the concept of "window title" is the user request that they want to see all the tab's "window titles" at once because that would help them quickly locate the one they're looking for, that is, some implementations would sure override the semantics and make it another line of "tab title".

And, if a by-product of this "tab icon" feature request (the original issue here) is really to separate "window title" from "tab title", then why don't we also need a separate "window icon" and "tab icon"?

I think using xterm's icon "title" for the icon uri is pretty safe

I disagree. OSC 1 is sure still supported in some terminal emulators and still being emitted by some applications. Why conflict with them when there are thousands (if not billions or quintillions) of free OSC numbers to choose from?

I don't want to try to implement transporting base64-encoded image formats in text

I, on the other hand, don't want to see a protocol extension emerging that doesn't work across serial line, telnet, ssh, login on the console of a virtual machine, etc. Remember: Terminal emulation, by its very definition and its history, emulates a world where remote communication takes place. It's only a frequent special case nowadays when it runs locally and has access to the local file system.

I especially don't get the "try to" bits in your sentence, and I could even quote Yoda. base64 is not a heuristic experimental technology that you try and perhaps succeed, perhaps fail. If the decision is to go for base64 (as a technical necessity for embedding binary data), so be it, it's easily implementable, I see no problem with it.

@egmontkob commented on GitHub (Jul 12, 2019): > 0 - window title, 2 - tab title I'm firmly against this idea, for multiple reasons. One is that existing applications pretty randomly choose to emit OSC 0 or 2 (or 1+2) for changing the title, expecting to overwrite the previous one. This would no longer be the case, resulting in user-perceived broken behavior when an application fails to replace the previous one's title. If separating window and tab titles is desired (which I strongly doubt) then one of them needs to get a brand new escape sequence. There are plenty of free OSC numbers to choose from. My other concern is: Is this really a desired possibility? Even if applications immediately adapted to the new semantics, would I want this as an app developer (how should I decide what to put where) and would I want this as a user? As a user, my expectation is the window to have the active tab's title (maybe with a fixed prefix or suffix such as "Windows Terminal"). Allowing apps to deviate from this would not help me in any way, but would totally confuse me. I don't think this pattern is seen elsewhere, e.g. documents, web pages etc. all have a single title which becomes the tab and window title (the latter only if this tab is focused, obviously). If a single title per document is good enough for the web, it should good enough for terminal emulation. Furthermore: Many terminals hide the tab bar if only a single tab is present, this would no longer be possible, or a potentially important piece of information (tab title) would be hidden then from the user. Yet furthermore: A natural consequence of introducing the concept of "window title" is the user request that they want to see all the tab's "window titles" at once because that would help them quickly locate the one they're looking for, that is, some implementations would sure override the semantics and make it another line of "tab title". And, if a by-product of this "tab icon" feature request (the original issue here) is really to separate "window title" from "tab title", then why don't we also need a separate "window icon" and "tab icon"? > I think using xterm's icon "title" for the icon uri is pretty safe I disagree. OSC 1 is sure still supported in some terminal emulators and still being emitted by some applications. Why conflict with them when there are thousands (if not billions or quintillions) of free OSC numbers to choose from? > I don't want to try to implement transporting base64-encoded image formats in text I, on the other hand, don't want to see a protocol extension emerging that doesn't work across serial line, telnet, ssh, login on the console of a virtual machine, etc. Remember: Terminal emulation, by its very definition and its history, emulates a world where remote communication takes place. It's only a frequent special case nowadays when it runs locally and has access to the local file system. I especially don't get the "try to" bits in your sentence, and I could even quote Yoda. base64 is not a heuristic experimental technology that you try and perhaps succeed, perhaps fail. If the decision is to go for base64 (as a technical necessity for embedding binary data), so be it, it's easily implementable, I see no problem with it.

claunia commented

@zadjii-msft commented on GitHub (Jul 12, 2019):

I concur, I'd be pretty strongly against using an existing sequence to do something specific to the Windows Terminal. While the icon name doesn't really mean anything to us, there are systems where it does do something specific.

Your point about the uri not working over network connections is a good point, I hadn't considered that. I kinda wanted to avoid having developers need to load the images and convert them to base64 themselves. Say you're writing some sort of shell script, you'd need another utility to be able to set the tab icon from your script. Though I'm having a hard time thinking of another possibility that'll work over a network.

@zadjii-msft commented on GitHub (Jul 12, 2019): I concur, I'd be pretty strongly against using an existing sequence to do something specific to the Windows Terminal. While the icon name doesn't really mean anything to us, there are systems where it _does_ do something specific. Your point about the uri not working over network connections is a good point, I hadn't considered that. I kinda wanted to avoid having developers need to load the images and convert them to base64 themselves. Say you're writing some sort of shell script, you'd _need_ another utility to be able to set the tab icon from your script. Though I'm having a hard time thinking of another possibility that'll work over a network.

claunia commented

@egmontkob commented on GitHub (Jul 12, 2019):

I'd expect that extremely few applications want to have a dynamic image, and if they dynamically create it, base64'ing is pretty cheap compared to that. The vast majority of apps would display a fixed "favicon" which is an artwork shipped by the app. In that case, especially for shell scripts that don't get compiled, IMO inlining the already base64'd string in the script is a perfectly reasonable solution (and results in the best runtime performance).

@egmontkob commented on GitHub (Jul 12, 2019): I'd expect that extremely few applications want to have a dynamic image, and if they dynamically create it, base64'ing is pretty cheap compared to that. The vast majority of apps would display a fixed "favicon" which is an artwork shipped by the app. In that case, especially for shell scripts that don't get compiled, IMO inlining the already base64'd string in the script is a perfectly reasonable solution (and results in the best runtime performance).

claunia commented

@Jaykul commented on GitHub (Jul 15, 2019):

Sure. There's already a standard for base64 images as data:URIs.
They don't work in the terminal right now...

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4wUJBB8dQLnJ7QAAAlhJREFUOMulk02IjlEUx3/3Pvc+zzvveM07ZnxlSkNGsrHDhiaSZEFKSsJCKB/5iJISC7spE2lqWFCS1SxkIcrnylIWFhKSUIzBmI/n3nMsnvd536ydzV38z/n/z//cc+A/wwCsOfyIp5f7WXvkyVxjLMYmmMRhTQLWYROHMRaTeIwpMGMTfKVjzJRMG8+93TSjq/eeiBBiwEpANKAxRyWgEpDYeCWgMWCsw5YELqsdUxFUAjcOpMxqny6KY0RibBarBDRGVCIYHrUIXGW9SCvp+sE6nW2FGhpQiQ312MxJfNuwBVh/5lWvdZUmsPvKT36MB24cnUt7mhctS6ToMDZtSD753AJUqt1LSvUyedelr4yN59w83kNC/o/3kqTaufC7BVCVzSp5AcSGQozsGvhAxScM7pvP5FTLnkjEpe1jIycq4xbA2GRHy18kxsiyHs+d072AMnT3HS4p2i9n4LLaEIBbvW9khk387BKYnM7Zu24mO9d28Pr9KKeG3/AnT0Fa36ka8dV6QVBfsGKlasFey5Sh/fPo6fbcfviOW09+0d1Roy4BFfjwZQojEVDNx0c/bxsUnLF+lUrAErh9cgFjv6fYfv4F3ybauXpoMUt7qs21PXvtJc9efsdar12LFk/f2mswmy58vG8MG2IMdKa/+TQqpM6iEpiazgl5ObiczBmMgaw25/GDi8v7ARwSUzVEo8LoREaWlltmSb3DOwNiUXWN6zE6c3bfnuYCfvvyqr/e1Wesr5JWqyS+jcRnuAwSD96DrYBpXI1NYHiL0a0DE4ycaOO/4y9T/nYLtgWe7wAAAABJRU5ErkJggg==

Neither github nor Stack Exchange seem to allow them ... 😉
PowerShell Blue Icon

@Jaykul commented on GitHub (Jul 15, 2019): Sure. There's already a standard for base64 images as data:URIs. They don't work in the terminal right now... ``` data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4wUJBB8dQLnJ7QAAAlhJREFUOMulk02IjlEUx3/3Pvc+zzvveM07ZnxlSkNGsrHDhiaSZEFKSsJCKB/5iJISC7spE2lqWFCS1SxkIcrnylIWFhKSUIzBmI/n3nMsnvd536ydzV38z/n/z//cc+A/wwCsOfyIp5f7WXvkyVxjLMYmmMRhTQLWYROHMRaTeIwpMGMTfKVjzJRMG8+93TSjq/eeiBBiwEpANKAxRyWgEpDYeCWgMWCsw5YELqsdUxFUAjcOpMxqny6KY0RibBarBDRGVCIYHrUIXGW9SCvp+sE6nW2FGhpQiQ312MxJfNuwBVh/5lWvdZUmsPvKT36MB24cnUt7mhctS6ToMDZtSD753AJUqt1LSvUyedelr4yN59w83kNC/o/3kqTaufC7BVCVzSp5AcSGQozsGvhAxScM7pvP5FTLnkjEpe1jIycq4xbA2GRHy18kxsiyHs+d072AMnT3HS4p2i9n4LLaEIBbvW9khk387BKYnM7Zu24mO9d28Pr9KKeG3/AnT0Fa36ka8dV6QVBfsGKlasFey5Sh/fPo6fbcfviOW09+0d1Roy4BFfjwZQojEVDNx0c/bxsUnLF+lUrAErh9cgFjv6fYfv4F3ybauXpoMUt7qs21PXvtJc9efsdar12LFk/f2mswmy58vG8MG2IMdKa/+TQqpM6iEpiazgl5ObiczBmMgaw25/GDi8v7ARwSUzVEo8LoREaWlltmSb3DOwNiUXWN6zE6c3bfnuYCfvvyqr/e1Wesr5JWqyS+jcRnuAwSD96DrYBpXI1NYHiL0a0DE4ycaOO/4y9T/nYLtgWe7wAAAABJRU5ErkJggg== ``` Neither github nor Stack Exchange seem to allow them ... 😉 <img alt="PowerShell Blue Icon" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4wUJBB8dQLnJ7QAAAlhJREFUOMulk02IjlEUx3/3Pvc+zzvveM07ZnxlSkNGsrHDhiaSZEFKSsJCKB/5iJISC7spE2lqWFCS1SxkIcrnylIWFhKSUIzBmI/n3nMsnvd536ydzV38z/n/z//cc+A/wwCsOfyIp5f7WXvkyVxjLMYmmMRhTQLWYROHMRaTeIwpMGMTfKVjzJRMG8+93TSjq/eeiBBiwEpANKAxRyWgEpDYeCWgMWCsw5YELqsdUxFUAjcOpMxqny6KY0RibBarBDRGVCIYHrUIXGW9SCvp+sE6nW2FGhpQiQ312MxJfNuwBVh/5lWvdZUmsPvKT36MB24cnUt7mhctS6ToMDZtSD753AJUqt1LSvUyedelr4yN59w83kNC/o/3kqTaufC7BVCVzSp5AcSGQozsGvhAxScM7pvP5FTLnkjEpe1jIycq4xbA2GRHy18kxsiyHs+d072AMnT3HS4p2i9n4LLaEIBbvW9khk387BKYnM7Zu24mO9d28Pr9KKeG3/AnT0Fa36ka8dV6QVBfsGKlasFey5Sh/fPo6fbcfviOW09+0d1Roy4BFfjwZQojEVDNx0c/bxsUnLF+lUrAErh9cgFjv6fYfv4F3ybauXpoMUt7qs21PXvtJc9efsdar12LFk/f2mswmy58vG8MG2IMdKa/+TQqpM6iEpiazgl5ObiczBmMgaw25/GDi8v7ARwSUzVEo8LoREaWlltmSb3DOwNiUXWN6zE6c3bfnuYCfvvyqr/e1Wesr5JWqyS+jcRnuAwSD96DrYBpXI1NYHiL0a0DE4ycaOO/4y9T/nYLtgWe7wAAAABJRU5ErkJggg==" />

claunia commented

@mikemaccana commented on GitHub (Jul 18, 2019):

Say you're writing some sort of shell script, you'd need another utility to be able to set the tab icon from your script. Though I'm having a hard time thinking of another possibility that'll work over a network.

+1 base64. I think it'd be reasonable for pwsh or whatever shell to include a png (or whatever) to base64 tool.

@mikemaccana commented on GitHub (Jul 18, 2019): > Say you're writing some sort of shell script, you'd need another utility to be able to set the tab icon from your script. Though I'm having a hard time thinking of another possibility that'll work over a network. +1 base64. I think it'd be reasonable for pwsh or whatever shell to include a png (or whatever) to base64 tool.

claunia commented