[h-e-w] Fwd: Windows 10 Taskbar Behavior

[Rob Davenport]

Ah, thank you Eli.  I had not yet looked into the Emacs source to determine that.  But I'm glad it's already there.  Much more knowledgeable developers have been at work. :)   I see emacsclient.c, runemacs.c *and* w32term.c all call SetCurrentProcesExplicitAppUseModelID with  L"GNU.Emacs".  So it should work.

Though I do see the problem in Windows 7 too (not just Windows 8 or 10).. I believe the issue is that by default, when pinning Emacs, the shortcut that gets created does *not* have the AppID set, and therefore looks different to the Windows shell.  I don't know if pinning other applications would get the correct AppID or not - and if it does maybe Windows is looking for something in the exe that it's not finding in emacs.exe to create the shortcut with the AppID.

There is a  tool called 'lnk-parser' which could also be useful. <https://code.google.com/p/lnk-parser/>  It's a command-line tool that dumps the contents of a shortcut (lnk file) and includes the AppId.    And I just tried this test.  I ran lnk-parser on my (working) pinned Emacs shortcut and it shows the AppID of "GNU.Emacs".  I unpinned it, ran runemacs and pinned it again, and now the lnk-parser shows that the shortcut does *not* contain any AppID.

Maybe there's a way to help Windows create the shortcuts correctly when pinning by providing other info in the emacs processes, or we can write a program like win7appid that can be used similarly (and GPL'd) to let users manually update the shortcuts.

Rob

p.s.

Another way to (manually) edit the app id of a shortcut... add the following string registry entry to HKCR\lnkfile:

[HKEY_CLASSES_ROOT\lnkfile]

"FullDetails"="prop:System.PropGroup.Description;System.ItemTypeText;System.Comment;System.Link.TargetParsingPath;System.AppUserModel.ID;System.ItemFolderPathDisplay;prop:System.PropGroup.FileSystem;System.ItemNameDisplay;System.Size;System.DateCreated;System.DateModified;System.FileAttributes;*System.OfflineAvailability;*System.OfflineStatus;*System.SharedWith;*System.FileOwner;*System.ComputerName"

Then doing the Properties on a shortcut file, in the Details tab, the AppUserModelID is displayed - and is editable.  I fixed my repinned emacs shortcut with this.    (You could just set "FullDetails" to be *just* "prop:SystemAppUserModel.ID" but then the details tab will *only* show the app id.

On Fri, Oct 9, 2015 at 3:40 AM, Eli Zaretskii <address@hidden> wrote:

> Date: Thu, 8 Oct 2015 23:09:18 -0400
> From: Rob Davenport <address@hidden>
> Cc: "address@hidden" <address@hidden>
>
> This issue intrigued me so I kept looking into it and here's what I've found.

Thank you for your research.

> In Windows 7 and newer, the shell (Explorer.exe) changed the behavior of the
> taskbar, and groups taskbar items (processes, files, windows, etc.) to make it
> easier to find what you're working on (and share features like the jumplists
> and taskbar preview). In order to do that, the shell needs a way of identifying
> what to group.It does this using the "Application User Model ID". (See
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd378459(v=vs.85).aspx
> and http://blogs.msdn.com/b/oldnewthing/archive/2012/08/20/10341464.aspx for
> some good details.)
>
> The Windows shell uses some heuristics to try to identify what should be
> grouped but it isn't perfect. For example, for programs started via shortcuts,
> the target in the shortcut must be the same. So if you have two shortcuts to
> the same program but with different command line parameters, they would be
> considered different and not be grouped. For processes it assumes only
> processes with the same name should be grouped. And that's the situation with
> Emacs - emacs.exe and runemacs.exe aren't considered the same by the Windows
> shell and it doesn't group the icons on the taskbar and similar undesired
> behavior we see.
>
> Microsoft says the way to solve this is to explicitly set an AppID which
> overrides the heuristics. So for better behavior in Windows 7 and later, all
> emacs processes (emacs.exe, runemacs.exe, emacsclientw.exe, etc.) should be
> modified to call SetCurrentProcessExplicitAppUserModelID() during their
> startup.

Yes, that's true.  However, Emacs on Windows has been doing precisely
that, i.e. calling SetCurrentProcessExplicitAppUserModelID, since
2009, i.e. since Emacs 23.2 at least.  And IME it works fine on
Windows 7.  The question is, why doesn't it on Windows 10?

IOW, the issue is not the changes in Windows 7, which we already
handle, AFAIK, but the changes in Windows 10.