Alt+F2 spawns new wsltty window as a separate window stash in the task bar

[ksze]

wsltty 1.8.4 Windows 10 Professional 64-bit version 1709, build 16299.248

Just like the title says.

I use the unmodified "WSL Terminal" shortcut (without "%"), which launches bash of my default Linux flavour (Ubuntu).

Once the first wsltty window has been opened, if I press the Alt+F2 combo, I get a new window. But this second window and any subsequent ones become a separate window stash in the task bar:

It's slightly annoying. Sometimes I check the window previews in the task bar and don't find one window that I expect in the stash (because the first window is not in the stash), and it confuses me for a moment.

If I check the process tree in Process Explorer (from the SysInternals Suite), I see that the first mintty has explorer.exe as parent, while the second and subsequent mintty processes have "no" parent:

[mintty]

There were some bothersome tweaks about taskbar behaviour in mintty quite a while ago (before wsltty) and I hoped this trouble would not occur again... It will take a while until I find some time to check this out.

[mintty]

I wonder why this only happens in WSL mode. No idea how to prevent it.

[willpower232]

I use a custom shortcut where the only difference is that I start in a different directory to avoid near constant cd's. The shortcut is copied from the ubuntu one so it has the same icon.

When I press Alt+F2 I get a new stash of windows too, in the same custom directory, without the ubuntu icon so it appears as the tux icon instead (as expected from above).

However when I middle mouse button click the ubuntu logo, I get another window in the same stash with the same icon and path so apparently theres a difference between middle mouse button and Alt+F2. I'd assume the only reason it isn't grouped is the icon.

HTH

[mintty]

Workaround: add -o AppID=wsltty to the target command line in the shortcut, as a mintty option (i.e. before wslbridge). Any AppID will do.

[mintty]

The shortcut is copied from the ubuntu one

The shortcut may have its own "AppID" which is then inherited by mintty. Please try another shortcut, maybe a freshly-created one.

[willpower232]

Workaround: add -o AppID=wsltty to the target command line in the shortcut, as a mintty option (i.e. before wslbridge). Any AppID will do.

That seems to solve the keyboard issue but also stops the middle mouse button from opening a new window. FWIW I can't see any AppID's on the existing shortcuts.

[mintty]

?? What keyboard issue? We were dealing with taskbar icon stacking. And which mouse function exactly would not work anymore? Confused.

[willpower232]

I referred to the original issue as the keyboard issue because the same feature of opening a new window can also happen on middle mouse click.

Without an AppID, I can open a new window in the same stack no problems using the middle mouse button.

With an AppID, I can't open a new window at all using the middle mouse click but Alt+F2 works fine as you described.

[mintty]

Released 1.9.0.

[sagarrabadiya]

i am using 1.9.0 still it shows multiple windows in task bar once i pin the shortcut to task bar clicking on it, will always create new icon for ex.

[mintty]

The original issue was about Alt+F2, does that work now for you? Taskbar pinning is another issue, as Microsoft designed a completely separate, insane concept for its configuration.

[sagarrabadiya]

yes with Alt + F2 it doesn't show multiple icon, so i think problem is with pin to task bar, can we have any work around or solution for that?

[mintty]

You may try to follow the hints given in the manual page for options TaskCommands and AppID. This crap only works if you make it irreversibly persistent...

[mintty]

Released wsltty 1.9.2 with new option AppID=@.

[mintty]

Planning to improve the situation for the next release in two ways:

• Alt+F2 in a window started from a shortcut could invoke the shortcut rather than just the binary (.exe), thus inheriting the same AppID from the shortcut as the running instance.
• Add placeholders to option AppID to be able to use it but distinguish various deployments, invocations etc as preferred (somewhat covered by value AppID=@ already but more flexible).

[ksze]

Wow. The lengths you go to to fix the quirks.

[mintty]

Released 1.9.4.

[mintty]

Released 1.9.5.

[mintty]

I've uploaded a patch that derives the AppID from the desktop shortcut if mintty is started from a shortcut (desktop, taskbar or start menu). Currently it takes precedence over an explicitly defined AppID option. Please test if possible (building mintty in cygwin and replacing the binary in %LOCALAPPDATA%/wsltty/bin).

[mintty]

Released 1.9.6.

[DanKaplanSES]

Apologies, I'm not sure if this is the right place to write this comment, but I saw you direct someone else here when they were having similar symptoms. Here's what's happening for me:

When all wsltty terminals are closed, clicking on the taskbar shortcut icon opens a new taskbar icon instead of using the shortcut icon. Probably easier to show than describe:

Subsequent clicks on the shortcut open new tabs within that new taskbar icon. I'm not sure how to check what version of wsltty I'm using, but I just downloaded the latest so I know it's 3.7.0.2.

It didn't always work like this: usually the same taskbar icon is used by both, as I prefer.

This was my shortcut's target: %LOCALAPPDATA%\wsltty\bin\mintty.exe --tabbar=4 -o "KeyFunctions=t:new-window-cwd;w:close" --WSL="Ubuntu" --configdir="%APPDATA%\wsltty" -.

Adding AppID=wsltty to the -o option fixed this issue for me: %LOCALAPPDATA%\wsltty\bin\mintty.exe --tabbar=4 -o "KeyFunctions=t:new-window-cwd;w:close;AppID=wsltty" --WSL="Ubuntu" --configdir="%APPDATA%\wsltty" -

(Originally, the reason I wrote this comment was to ask if I am supposed to do that or if I shouldn't need to. It's hard for me to tell the current status of this symptom.)

But here's the strange thing: As I wrote this comment, I removed AppID=wsltty from my shortcut to confirm I could reproduce the issue, then, when I put AppID=wsltty back, it no longer fixed the problem like it had the first time. The "double icon" problem still occurred even after a restart.

Eventually I fixed this the way I think I always do (this isn't my first rodeo): I pinned the new icon and unpinned the original shortcut. Now wsltty uses one taskbar icon for everything.

PS:

C:\Windows\system32>wsl --version
WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3930

[mintty]

Taskbar icon configuration is one of the extremely obscure areas of Windows, handled by insanely obfuscated APIs. I'm not surprised about erratic behaviour here.