Items pinned to Windows' task bar are supposed to launch the relevant application, and any windows from that application should be grouped with the pin entry. This isn't working properly for the ThinLinc client, and in some cases you get a second icon on the task bar when the client is running. The method to break things is to find the client in the start menu, and select "pin to taskbar" from there. This seems to break on every Windows 10 system we've tried. It works fine on our test Windows 11, though. But we have one Windows 11 with the same symptoms, but it is unknown how the pinning was done. If you pin a running client, then the pinning is set up correctly, and you don't get double entries. It is unknown whether this is a regression or not. One would hope that this was tested on bug 2805 when this feature was first added, but there is no such testing documented. I tried running the 4.0.0 client on a current Windows 10, and it had the same issue. So, either this bug has always been present, or something has changed in Windows since then.
Reasonably, we would need to set our "AppUserModelID" on the shortcut, so that Windows knows how to associate our windows with this shortcut. But I cannot see any attempt to do so by our installer. Perhaps we should do so? There are some examples for how to do this in NSIS: https://github.com/safing/nsis-shortcut-properties OTOH, why should our shortcut be special? Shouldn't this be mapped via the .exe the shortcut points to somehow? Otherwise, things would just break if the user pins some shortcut they've created themselves (or via some other tool). Perhaps there is some attribute on the .exe we aren't setting?
