Windows 11 taskbar icon twitching

[mkq]

So some genius at Microsoft thought it would be a great idea to make the Windows 11 taskbar twitch every time a command starts or ends in my zsh configuration (because that changes the window title and thereby often the taskbar button width).

I tried to counter that by simply adding lots of spaces and a dot at the end of the title, enough to make the button width static and the dot to be hidden. But then the mintty tab title is abbreviated near the beginning, i.e. something like "z… .".

Two possible remedies come to mind. Could you please add one of those? Or is there a better solution?

1. Add an option to make the tab title the window title truncated at the end.
2. Support new control sequences to set the tab title independently of the window title.

(1 sounds easy and is sufficient IMHO.) Thanks!

[mintty]

2 would break existing workflows, 1 would break expectations about the title.
I'd rather add an option (switchable in the extended context menu) so that the control sequence to set the window title only changes the tab title if there is a tabbar. And maybe a control sequence to sync or clear the window title.

[mkq]

Thanks. Can you please elaborate, as I understand neither of your points.

1 would break expectations about the title

I don't see how anything would break if you added an option and kept the current behavior the default.

2 would break existing workflows

You mean it would break users which only use the current control sequences and would now get empty tab title? In that case, couldn't the tab title equal the window title until the new ctrl seq occurs for the first time?
Or: The existing ctrl seq keeps changing both titles, and the new one just the tab title. So when used in the correct order, that would effectively give me "independently".

I'd rather add an option (switchable in the extended context menu) so that the control sequence to set the window title only changes the tab title if there is a tabbar.

So a non-settable window title if there is a tabbar? That's not a solution to my problem, as I still want a meaningful window title, not just any fixed length one.

And maybe a control sequence to sync or clear the window title.

As soon as I'd sync, would I be back at my initial abbreviation problem then?

[mintty]

ad 1: The control sequence OSC 2 is described to set the title to the given string, not part of it. People may wish to keep that but still get the remedy to be agreed.
ad 2: Scripts like shell profiles use OSC 2 and would all need to be changed to support the remedy. It should work automatically, keeping existing profiles portable. I don't want a solution that only works for power users.

A sequence that sets the actual window title (e.g. the sync sequence) could be sent less frequently, for example only when the working directory is changed in the shell. Or, with the "tab title only" mode enabled, a new sequence could be used to set the window title.

[mkq]

ad 1: In my suggestion 1, I don't mean any change to window title setting at all. Only tab title (which is not covered by standard OSC 2, I assume, and is already being abbreviated) would be abbreviated in a different way. (Plus keeping the old behavior as default should mean that nothing breaks. And even if the new abbreviation mode is used, the "break" is purely visual, since there is no way to programmatically read the tab title anyway.)

ad 2: Yeah, extra effort to use the new feature. That's why I prefer solution 1.

A sequence that sets the actual window title (e.g. the sync sequence) could be sent less frequently, for example only when the working directory is changed in the shell.

My window title changes twice per entered command, and I want to keep it that way. (That's why the "re-layouting" of the Windows 11 taskbar is so annoying.)

Or, with the "tab title only" mode enabled, a new sequence could be used to set the window title.

IIUC, for everyone who wants both titles, this would mean as much extra effort as my suggestion 2 (keep OSC 2 unchanged [window title and middle truncated tab title], add new CtrlSeq for tab title), just in a more confusing way.

How about a solution "4"?

• Add a new "post-processing" window title format string option which can contain a placeholder (say "%t") for the OSC-set window title and would default to just that. I'd set it to "%t many spaces .", others might set it to "mintty - %t". When someone runs a command which sets a title he doesn't like, he'd use a string without "%t".
• All control sequences only set or copy the "%t" part.

[mintty]

I've meanwhile tried to reproduce the original issue on Windows 11 but I don't see any effect of title changing to the taskbar.
Please describe what you mean by "taskbar twitch" and how to reproduce an effect.

[mkq]

I'm currently not at my Windows 11 work computer, but I'll try:

1. Taskbar settings: enable window titles
2. Have some more windows open besides mintty
3. Ensure that mintty is not the rightmost taskbar button; drag it to the left if necessary
4. Call a command like termtitle s; sleep .4; termtitle looooooooooooooooooong; sleep .4; termtitle s assuming a script termtitle to set the title. (Simulates real world use case: shell prints a short title like "zsh [~]" when prompting, a prefix plus the command like "zsh> find "$APPDATA/" -newermt ..." (whatever - some long command) when starting a command.)

=> The mintty taskbar button gets temporarily wider, causing the buttons to the right to move right. When that happens often and quickly, it almost feels like the taskbar is flickering.

[j4james]

@mintty Assuming it's possible to set the taskbar icon label separately from the window title, have you considered using OSC 1 for this? The Windows taskbar icons aren't exactly equivalent to iconified applications in Unix, but they serve a similar purpose, and they both have a need for a shorter label, which is essentially what the OSC 1 sequence was intended to provide.

[mintty]

set the taskbar icon label separately from the window title

As far as I know this is not possible. (Otherwise I would have implemented distinct OSC 0/1/2)
If anyone finds how to achieve that, please inform us.

[mintty]

Taskbar settings: enable window titles

I do not see this option in Windows 11. How are taskbar icon titles enabled?

[mkq]

Personalization / Taskbar / Taskbar behaviors / Combine taskbar buttons and hide labels must be set to "When taskbar is full" or "Never".

[mintty]

I don't have that option in my taskbar behavior menu. Maybe with 23H2 which is just downloading?

[mintty]

OK, I could now enable taskbar icon labels. The label is changed along with the window title as expected, clipped to some maximal length. I still do not see what you mean by "twitching". Everything looks fine for me.

[mintty]

OK, I've now seen the difference to Windows 10. I had misunderstood the issue to be related to long labels but it's about short labels of different length (as long labels are clipped anyway), right?
So you do not want the width of taskbar icons to get changed so often, I assume.
A simple workaround would be to pad the label with blank space (using a non-breaking space U+A0) but then the width would always be the maximum which you might not like either.

I'm pondering to offer the following solution, fitting into existing definitions of OSC sequences (but slightly tweaking them which might be considered unsuitable by some):
OSC 0 "Change Icon Name and Window Title to Pt." would set both window and tab title.
OSC 1 "Change Icon Name to Pt." would set the tab title only.
OSC 2 "Change Window Title to Pt." would set the window title only.
This would however break as a solution if Windows ever introduces an API to set the taskbar icon label distinctly from the window title...

[mintty]

The proposed design would be the reverse of what @j4james suggested, so apparently it's a matter of preference (and could be tweaked by an option). Still leaving open how to extend handling if one day we might have 3 distinct labels (window, tab, icon).

[mintty]

It was further confusing the issue to relate it to the tab title as it arises alike without tabbar, at least as I now understand it.

[mkq]

Sorry for the confusion. Yes, I'd like to have all taskbar buttons the same width, and that should be the maximum width or similar (except when the taskbar is full, causing all to shrink as needed). I'd like to get rid of short window titles and their shrinking taskbar buttons.

It was further confusing the issue to relate it to the tab title as it arises alike without tabbar, at least as I now understand it.

As far as the variable taskbar button width is concerned, you are right. The tab title comes into play when I pad the window title to get wide taskbar buttons, and then mintty abbreviates the relevant part of the title instead of the padding.

A simple workaround would be to pad the label with blank space (using a non-breaking space U+A0) but then the width would always be the maximum which you might not like either.

I'd like that max width.
I had not tried U+A0. Unlike a simple space, this is not trimmed by Windows, so it works to get a nice taskbar button width.
But it has the same problem as my workaround (simple spaces plus a trailing dot): The mintty tab title is abbreviated in the middle. For example, a padding with 39 U+A0 chars seems to be necessary to get maximum taskbar button width for the extreme case that the unpadded title is just "i". I have tried that with different values of variable w in

w=39; for t in i a 'aaa bbb ccc' 'aaa bbb ccc ddd' 'aaa bbb ccc ddd eee' 'aaa bbb ccc ddd eee fff' 'aaa bbb ccc ddd eee fff ggg' 'aaa bbb ccc ddd eee fff ggg hhhhhhhhhhh iiiiiiiiiiii jjjjjjjjjj'; do t2=$t; while [ ${#t2} -lt $w ]; do t2="$t2"$'\u00A0'; done; printf '(%s)\n' "$t2"; printf '\033]0;%s\007' "$t2"; sleep 3; done

But for the unpadded title "aaa bbb ccc", for example, the tab title gets abbreviated to "a…". (And unpadded "a" yields tab title "a…", so no information loss there, but not ideal either.)

But now that you pointed me to non-breaking space, if mintty would simply set the tab title to the right-trimmed window title before doing it's (center) abbreviation, the U+A0 workaround would be all that I'd need. I don't think that that would break any reasonable expectations.

[mintty]

I've uploaded a workaround for the taskbar icon twitching as discussed. The window title (which is also used as the taskbar icon label) is padded with 50 non-break spaces. Note that 39 is likely not enough as I also made the taskbar font configurable and you could use a narrower font.
Please build mintty for testing.

About the original request to separate window and tab title, this would need to add title management to mintty which is currently not available (the title contents is simply maintained as the Windows title and retrieved from it when needed).

[mintty]

On Windows 10, the same procedure has a bad effect, so applying it only on Windows 11.

[mkq]

Thank you very much!

I have built master. But Windows Security doesn't let me execute it on my work computer, which is currently my only computer with Windows 11. I will try again in the next days. Sometimes, Windows Security changes its mind.

[mkq]

I could now run the self-built mintty. When I run my test loop from #1263 (comment), with sufficiently large w, it looks good. But small w values still yield slim taskbar buttons.

I.e. I still need to pad with U+00A0 myself, which is not a problem for me, but your comment sounds like it should not be necessary on the user's side anymore.

[mintty]

I see no such effect from your script, provided I run it from an updated mintty instance.

[mkq]

Hmm, strange.

The about dialog in my self-built mintty.exe shows "mintty 3.7.1 (x86_64-pc-cygwin) [Windows 22631]" just like my installed version. Is that expected?

Can Windows Security not only block, but also silently replace programs??

[mintty]

The version stays the same until the next release. (Something I already wanted to enhance for a while...)
If you start from ../bin, the self-built version should be running.

[mkq]

I tried again with the self-build exe, and checked in Task Manager that that one is really running. I still need to pad the title myself:

Unpadded ⇒ slim button:

Padded in my printf '\033]0;x\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\007'; sleep 5 ⇒ wide button:

[mkq]

I do notice the improved tab title: printf '\033]0;x\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\007'; sleep 5 gives tab title "x…" in the release version and centered "x" in the self-built.

So that's another confirmation that I'm running the self-built version.

[mintty]

Excuse the question, your self-build was based on which sources? Did you get a fresh git pull?

[mintty]

I guess a found an error in the patch, hold on. I wonder though, how I could test it successfully on Windows 11...

[mkq]

OK, I'll answer anyway, in case it helps:
Yes, I think it must have been commit d8594d2 which I built. (When I re-build that commit now, I get a mintty.exe with size 1734637, but Windows Security doesn't even let me diff it with the backup mintty.exe with which I tested yesterday. But the sizes match.)

[mintty]

The fix should now be fixed. Sorry for the confusion.

[mkq]

No problem. Thank you very much!

I've built commit 18d63f9. Let's see when Windows Security is ready to allow me run it…

[mkq]

I can now confirm that mintty's padding works for me, e.g. unpadded printf '\033]0;i\007' gives me a full width taskbar button.

Thanks a lot!

[mintty]

Released 3.7.2.