[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Vanderschel
Subject: Re: [h-e-w] Windows 10 Taskbar Behavior
Date: Sun, 11 Oct 2015 18:09:19 -0500
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

In my original post, I called attention to the fact that, in Windows 7 and 8.1, it has always been sufficient to start Emacs with runemacs, pin it, and change the pinned shortcut's target to runemacs. I cannot explain why it is not working for you in Windows 7. (My Windows 7 machine is down right now, so I cannot reverify it there, but I think Eli did.)

On 10/9/2015 4:08 PM, Rob Davenport wrote:
Interesting.  I ran my earlier test on this Windows 7 laptop and when I pinned 
Emacs, the shortcut did *not* have any App ID.   I don't have a Windows 8 
machine (my other laptop is now Windows 10), as I would like to test it there.  
But you're saying it works correctly in Windows 8.1.   Does it work for you in 
Windows 7?   If so, then there's something different about my Windows 7 machine 
causing it to not set the app id when pinning.  And apparently it only works in 
Windows 8.1, not 7 or 10.  Odd.

Either way, I think we have two ways to set the App ID in the shortcut 
(win7appid tool and the Details tab after applying that registry change - and I 
updated with that tip as well [1]).



p.s. Every time this week I go to it comes up in a non-English 
mode - it's been in Russian and Swedish for me.  Anyone else seen that?  I 
tried clearing cookies and cache.  Weird.

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of David Vanderschel
Sent: Friday, October 09, 2015 4:26 PM
To: Eli Zaretskii <address@hidden>; Rob Davenport <address@hidden>
Cc: address@hidden
Subject: Re: [h-e-w] Windows 10 Taskbar Behavior

On 10/9/2015 2:40 AM, Eli Zaretskii wrote:

From: Rob Davenport <address@hidden>
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.

I think it is a bug in Windows 10.  Using the app ID program after I pin Emacs to the 
taskbar in Windows 8.1, the app ID associated with the shortcut is already 
"GNU.Emacs".  However, in Windows 10, the program reports that there is no app 
ID associated with the shortcut.  So setting the ID (as it should have been set on 
pinning the program) fixes the problem.  (I also observed that the app ID is not case 

    David V.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]