Override automatic Win7 taskbar grouping

[GoogleCodeExporter]

> What steps will reproduce the problem?

1. Create a shortcut running "c:\cygwin\bin\mintty -" (the default shortcut 
from the cygwin package)
2. Create a copy of this shortcut running "c:\cygwin\bin\mintty ssh hostname" 
(actually, for some reason needs a wrapper that sources .bashrc; otherwise 
openssh fails)
3. Start mintty with both scripts.
4. Run "mintty ssh hostname" from the cygwin command line.

> What is the expected output? What do you see instead?

All three mintty windows should appear grouped together in the Windows7
taskbar (so, pinned, all mintty windows can be cycled though with Win+number). 
In actuality, the mintty instance started with the ssh shortcut is not grouped 
together with the others.

> What versions of mintty, Cygwin/MSYS, and Windows are you using?

Windows 7. Cygwin 1.7 and mintty from there.

Original issue reported on code.google.com by tuomov.i...@gmail.com on 16 Oct 2010 at 3:31

[GoogleCodeExporter]

Taskbar grouping is all Windows' doing, I'm afraid. Apparently it's deciding 
that one of those is a separate application.

I don't know whether this will make a suitable replacement, but Ctrl+Tab and 
Ctrl+Shift+Tab can be used to switch between mintty windows.

The .bashrc wrapper can hopefully be avoided by invoking '/bin/ssh' instead of 
'ssh'. Keep in mind that the Cygwin /bin directory isn't normally part of the 
Windows path. For a default Cygwin install, it's /etc/profile that adds it to 
the path. The Windows-wide path can be set in the System control panel.

Original comment by andy.koppe on 16 Oct 2010 at 3:47

[GoogleCodeExporter]

Unfortunately you can't switch to a specific mintty window from another 
application with Ctrl+Tab.

And, yes, the same multiple-shortcut issue affects putty as well. (The reason 
I'm trying to use openssh with mintty is that mintty seem snappier than 
puttycyg, and I want to group everything together.) I know absolutely nothing 
about Windows programming, but maybe it by default decides what to group 
together by the shortcut that started the application, but there could be a way 
for applications to inform otherwise?

As for running /bin/ssh, that's not the issue. The issue is that /bin/ssh fails 
without some environment setup done by bashrc (just run mintty /bin/bash -i ssh 
hostname). But that's OT anyway. 

Original comment by tuomov.i...@gmail.com on 16 Oct 2010 at 3:59

[GoogleCodeExporter]

I've had a little gander around MSDN, and you're right, there is an API for 
overriding the default icon grouping: the snappily named 
SetCurrentProcessExplicitAppUserModelID 
(http://msdn.microsoft.com/en-us/library/dd378422.aspx).

I shall combine that with the --class option to still allow to put mintty 
instances into separate groups if desired.

Original comment by andy.koppe on 16 Oct 2010 at 6:14

• Changed title: Override automatic Win7 taskbar grouping
• Changed state: Accepted
• Added labels: Difficulty-Easy, Priority-Medium, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Sounds good. Thanks.

Original comment by tuomov.i...@gmail.com on 16 Oct 2010 at 6:55

[GoogleCodeExporter]

Unfortunately this isn't as simple as it first appeared. In fact MS have really 
surpassed themselves and designed a complete mess.

Changing mintty to invoke SetCurrentProcessExplicitAppUserModelID causes these 
two problems:

1. If you right-click on a mintty shortcut and pin it to the taskbar, clicking 
on the resulting taskbar icon to start mintty will result in a separate taskbar 
icon, whereas of course it's meant to change the state of the pinned icon.

2. If you start mintty by clicking on a shortcut and then right-click on the 
resulting taskbar icon to pin it, the pinned icon will not have the command 
line arguments and the working directory of the original shortcut, so e.g. 
you'll get a non-login shell.

The reason for all that is that Windows uses a property called 
System.AppUserModel.ID on shortcut files to associate running programs with 
shortcuts when pinning. Programs that use 
SetCurrentProcessExplicitAppUserModelID are meant to set that property when 
their installer creates the shortcut.

Cygwin's mkshortcut utility used for creating mintty's start menu shortcut 
doesn't support setting that property, although that could be changed. (It 
requires some annoying but entirely feasible faffing about with COM.)

Users creating their own shortcuts are out of luck though. There's no user 
interface to setting or even just reading that property, thereby guaranteeing 
maximum user frustration.

Therefore I've decided not to use SetCurrentProcessExplicitAppUserModelID and 
stick with the default behaviour, because that at least seems fairly sane.

Luckily, someone going by the name of 'didroe' has stepped up to create a small 
command line utility called 'win7appid', which uses the aforementioned COM 
interfaces to get or set a shortcut's System.AppUserModel.ID property. It's at 
http://code.google.com/p/win7appid.

So to address your issue, you just use that utility to set the property to the 
same value on all your mintty shortcuts. I've tried it successfully. Microsoft 
have guidelines on how to form an AppID at 
http://msdn.microsoft.com/en-us/library/dd378459.aspx#how, but actually any 
string that doesn't clash with other applications will do.

Original comment by andy.koppe on 17 Oct 2010 at 5:32

• Changed state: Closed
• Added labels: Difficulty-Medium
• Removed labels: Difficulty-Easy

[GoogleCodeExporter]

Ok, that seems to work, although it is a bit on the clumsy side. Thanks again.

Original comment by tuomov.i...@gmail.com on 17 Oct 2010 at 9:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

John, sorry for the late reply. It's too easy to overlook comments on closed 
issues, even more so now that Google Code have removed the Updates page.

Please explain more clearly what problem you're trying to solve there. The 
original issue had already been addressed using the win7appid utility, so a new 
issue seems in order and I'm leaving this one closed.

A couple of questions for the new issue. How does your patch using OLE to set 
PKEY_AppUserModel_ID differ from just using 
SetCurrentProcessExplicitAppUserModelID? And how does it avoid the two issues I 
mentioned in comment 5?

Original comment by andy.koppe on 12 Mar 2012 at 5:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

John, I'm afraid you've lost me here (although admittedly I haven't found the 
time to try to think through the changes and the given reasons properly).

I'm not sure whether you're addressing the same issue that was originally 
reported, so I think it would be best if you started with a clean slate and 
entered a new issue with answers to the template questions ("What steps will 
reproduce the problem? What is the expected output? What do you see instead?"). 
Hopefully that will help me understand why the patch is needed and also what 
the impact on existing users would be.

Original comment by andy.koppe on 29 May 2012 at 12:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Prompted by John Peterson's insistence (via issue 365), I've had another look 
at this.

I'm not going to change the default behaviour, because having separate taskbar 
icons for different mintty shortcuts does make quite a lot of sense and I don't 
want to change things for people who've come to expect that. Even more so 
because setting the AppID in the application but not on a pinned shortcut would 
result in a separate taskbar icon when invoking the shortcut.

However, I do accept that setting the AppID on shortcuts using win7appid is not 
a sufficient solution for people who don't like the default Windows behaviour: 
as pointed out by John, this doesn't work for mintty instances that aren't 
invoked through a shortcut, which actually includes minttys created through the 
'New' window menu item (or its Alt+F2 shortcut).

Therefore, what I have done in r1295 is to add an 'AppID' config setting that 
can be used to override the Windows default grouping. This can be set either in 
config files or on the command line using the -o option (for example: -o 
AppID=mintty).

Hence, to ensure that all mintty windows are grouped together, just add a 
'AppID=somename' line to the user-specific ~/.minttyrc file or the global 
/etc/minttyrc file. Additionally, the AppID on pinned shortcuts also needs to 
be set to the same name using win7appid (from 
http://code.google.com/p/win7appid).

I've implemented this using SetCurrentProcessExplicitAppUserModelID(), as I 
found that grouping does work fine across different processes with that. As far 
as I can see, window-specific AppIDs are only needed for separating multiple 
windows created by the same process.

Original comment by andy.koppe on 5 Jan 2013 at 2:04

• Changed state: Fixed
• Added labels: Milestone-1.1.3

[GoogleCodeExporter]

Issue 365 has been merged into this issue.

Original comment by andy.koppe on 5 Jan 2013 at 2:07

[GoogleCodeExporter]

Patch moved to https://github.com/mirror/mintty/pulls.

Original comment by john.s.peterson@live.com on 5 Jan 2013 at 2:16

[GoogleCodeExporter]

Re comment 22: if you want to discuss this issue further, please do so here. 
I'm not going to respond to comments on other sites. I'd also be interested to 
hear whether the new AppID option does what you need.

Original comment by andy.koppe on 9 Jan 2013 at 7:41

[GoogleCodeExporter]

Confirmed fixed in 1.1.3.

Original comment by andy.koppe on 7 Apr 2013 at 1:03

• Changed state: Verified