Fwd: Windows 10 Taskbar Behavior

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 <[email protected]> wrote:

> > Date: Thu, 8 Oct 2015 23:09:18 -0400
> > From: Rob Davenport <[email protected]>
> > Cc: "[email protected]" <[email protected]>
> >
> > 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.
>