Activity

1. Daniel Marczin (dim5)

   added

   Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.Complex enough to require an in depth planning process and actual budgeted, scheduled work.

   on Oct 1, 2019
2. ghost added

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Oct 1, 2019
3. ghost added

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Oct 1, 2019
4. zadjii-msft commented on Oct 1, 2019

   

   Mike Griese (zadjii-msft)

   on Oct 1, 2019

   Last edited by zadjii-msft

   Member

   More actions

   I could have sworn we had an internal issue for this feature, but it never got migrated to github it appears....

   FOUND IT! MSFT:18258406. Here are the relevant notes:

   sequence	description
   ESC ] 9 ; 4 ; st ; pr ST	Set progress state on Windows 7 taskbar and ConEmu title. When st is 0: remove progress. When st is 1: set progress value to pr (number, 0-100). When st is 2: set error state in progress on Windows 7 taskbar

   Also related documentation: ITaskbarList3::SetProgressValue

   We should probably also make sure that we support the TBPF_INDETERMINATE state - for something like our own bcz.cmd, where we don't know how long the operation will take.

   In conpty mode, we should just pass these sequences through. There's a good amount of precedent for such sequences in the code already.

   EDIT:
   We should probably also have a couple settings for controlling this behavior:

   • showProgressInTaskbar (default true) to show the progress in the taskbar entry
   • showProgressInTab (default true) to show the progress in the tab itself.

   showProgressInTab can probably be a follow up once microsoft/microsoft-ui-xaml#1386 is complete

   👍React with 👍5Reacted by Daniel Marczin, Luan Vitor Simião Oliveira, Jean Gautier, Troels Wiberg Jensen and David Refoua

   ❤️React with ❤️2Reacted by Travis Spomer and David Refoua
5. Mike Griese (zadjii-msft)

   added

   Area-VTVirtual Terminal sequence supportVirtual Terminal sequence support

   Product-ConhostFor issues in the Console codebaseFor issues in the Console codebase

   Product-TerminalThe new Windows Terminal.The new Windows Terminal.

   on Oct 1, 2019
6. ghost removed

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Oct 1, 2019
7. Mike Griese (zadjii-msft)

   added

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   and removed

   Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.Complex enough to require an in depth planning process and actual budgeted, scheduled work.

   on Oct 1, 2019
8. ghost removed

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Oct 1, 2019
9. Mike Griese (zadjii-msft)

   added this to the Terminal Backlog milestone on Oct 1, 2019
10. Mike Griese (zadjii-msft)

    added

    Help WantedWe encourage anyone to jump in on these.We encourage anyone to jump in on these.

    Issue-TaskIt's a feature request, but it doesn't really need a major design.It's a feature request, but it doesn't really need a major design.

    on Oct 1, 2019
11. Dustin L. Howett (MSFT) (DHowett-MSFT)

    removed

    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

    on Oct 23, 2019
12. 20 remaining items

    Load more
13. ghost added

    Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

    on Nov 18, 2020
14. mixmastamyk commented on Feb 2, 2021

    

    mixmastamyk

    on Feb 2, 2021

    Last edited by mixmastamyk

    More actions

    This unfortunately conflicts with iterm2 and kitty use of OSC 9. Not the end of the world since neither supports the others notification, but definitely problematic.

    • https://iterm2.com/documentation-escape-codes.html
    • https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/29
15. mintty commented on Feb 2, 2021

    

    mintty

    on Feb 2, 2021

    Last edited by mintty

    More actions

    Both could coexist as long as messages do not begin with "4;"...
16. j4james commented on Feb 2, 2021

    

    James Holderness (j4james)

    on Feb 2, 2021

    Collaborator

    More actions

    This unfortunately conflicts with iterm2 and kitty use of OSC 9.

    This was discussed in the PR and the terminal-wg issue that you linked. We reached the conclusion that WT probably wouldn't need to support iterm2's use of OSC 9, because if we did decide to implement notifications, we'd be more likely to go with OSC 777, since that's more widely supported.
17. mixmastamyk commented on Feb 2, 2021

    

    mixmastamyk

    on Feb 2, 2021

    More actions

    Ok, but what about from the app developer's point of view? I just implemented the progress reporting in my library, and it's nice, thanks.

    However, when I run my python script on kitty (and presumably iterm and others?) I get a ton of bogus desktop notifications "4;0;10", "4;0;20", etc.... instead. I had to put this BS in my code to work around it:

    if os.name = 'nt':
        # impl 1 ...        
    else:
        # impl 2 ...
    

    The least bad solution was probably using another number. As I read the discussion I realized Mr. Kovid is difficult, but I think he was right, we're not running out of integers any time soon.

    It's a shame that iterm and conemu chose conflicting sequences ~ten years ago, and there's nothing we can do about that. But now that folks are at least in some communication there's no reason to double down on them. ;-)
18. j4james commented on Feb 2, 2021

    

    James Holderness (j4james)

    on Feb 2, 2021

    Collaborator

    More actions

    As I read the discussion I realized Mr. Kovid is difficult, but I think he was right, we're not running out of integers any time soon.

    If he really cared about the conflict, though, he didn't have to implement OSC 9 as a notification sequence - kitty already supports notification through another OSC sequence. And while I can sympathise with iTerm2, gnachman didn't seem particular attached to OSC 9 when the subject of notifications was being discussed, so it's quite possible he might drop it one day.
19. DHowett commented on Feb 2, 2021

    

    Dustin L. Howett (DHowett)

    on Feb 2, 2021 · Hidden as off-topic

    show commentMore actions
20. mintty commented on Feb 2, 2021

    

    mintty

    on Feb 2, 2021

    More actions

    mintty also implementes CSIN%q as an alternative sequence;
    see https://github.com/mintty/mintty/wiki/CtrlSeqs#progress-bar but note the different numbering
21. mixmastamyk commented on Feb 3, 2021

    

    mixmastamyk

    on Feb 3, 2021

    More actions

    As an application developer, I'd like one sequence that works as many places as possible without conflicts…
22. zadjii-msft commented on Feb 3, 2021

    

    Mike Griese (zadjii-msft)

    on Feb 3, 2021

    Member

    More actions

    If you want consistency, I don't think the interpretation of escape sequences is a good place to be 😆

    There's just already so much fragmentation in this space, especially with OSC sequences. No one really standardized them in the first place, so everyone just went wild west claiming whatever they wanted. Not much we can do about it now unfortunately.

    Curious to me that iTerm2 chose OSC 9. Looks like the sequence must be very old in iTerm2: kovidgoyal/kitty#1474 (comment). Plus, ConEmu has been using OSC 9 as their prefix for years. So it really doesn't make sense to me to double down on OSC9 -> notification. It seems like it was an oversight when it was authored, the current author isn't attached to it, and there are better (non-conflicting alternatives).

    We could also support the mintty version of the sequence if that doesn't conflict too bad. Don't see why not.

    👍React with 👍2Reacted by Shmueli Englard and David Refoua
23. j4james commented on Feb 4, 2021

    

    James Holderness (j4james)

    on Feb 4, 2021

    Collaborator

    More actions

    We could also support the mintty version of the sequence

    If the point is to have a sequence that won't break kitty, then that probably isn't going to help. The last version I tested had issues with intermediates (at least some of them), which caused the sequences to be misinterpreted as something else. You may not get a notification popup, but you'll probably get some other weird breakage.
24. shmuelie commented on Feb 4, 2021

    

    Shmueli Englard (shmuelie)

    on Feb 4, 2021

    More actions

    When in doubt, offer the option to change which OSC is used in settings?
25. DHowett commented on Feb 4, 2021

    

    Dustin L. Howett (DHowett)

    on Feb 4, 2021

    Member

    More actions

    That only complicates the feature matrix, though. For mixmastamyk's "application developer" case, now it's just unreliable rather than "consistently different from iTerm2."
26. shmuelie commented on Feb 4, 2021

    

    Shmueli Englard (shmuelie)

    on Feb 4, 2021

    More actions

    That is true, would need a way to tell Terminal "this application uses OSC 9 for notifications, please do..."
27. zadjii-msft commented on Feb 4, 2021

    

    Mike Griese (zadjii-msft)

    on Feb 4, 2021

    Member

    More actions

    Man if only there was some sort of database that an app could use to look up "this is how you emit progress bar updates, this is how you send notifications, this is how you set the colors" for various different terminals 😝

    😄React with 😄2Reacted by Shmueli Englard and mixmastamyk