Closed ksze closed 5 years ago
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.
I wonder why this only happens in WSL mode. No idea how to prevent it.
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
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.
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.
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.
?? What keyboard issue? We were dealing with taskbar icon stacking. And which mouse function exactly would not work anymore? Confused.
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.
Released 1.9.0.
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.
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.
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?
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...
Released wsltty 1.9.2 with new option AppID=@.
Planning to improve the situation for the next release in two ways:
Wow. The lengths you go to to fix the quirks.
Released 1.9.4.
Released 1.9.5.
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).
Released 1.9.6.
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
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.
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: