[Top][All Lists]

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

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

From: Rob Davenport
Subject: Re: [h-e-w] Windows 10 Taskbar Behavior
Date: Thu, 22 Oct 2015 21:24:01 -0400

I infer it's not a high occurrence issue by the fact that no one else is complaining about the problem.  Either they aren't seeing it or it doesn't bother them (or enough to chime in).  I'm not saying give up on it, but it may take a while to fully understand (if ever).  I haven't found any smoking gun Microsoft documentation that indicates how 'pinning' determines the appid to use.  Yes, it would be best if we could figure out if there's anything we can do to get Windows to add the right appid, but it may be that getting addpm to set the AppID in the shortcut it creates is sufficient to resolve this adequately.

And I have seen it work "by default" (without even running addpm) sometimes.  I don't have a good explanation for when it "just works" and when it doesn't.  But it seems that adding the appid to the shortcut doesn't hurt and makes it work in cases where it wouldn't otherwise. So I still think we should get addpm to add it. But for those that don't run addpm, we can document the need to set the appid in shortcuts using either win7appid, or the registry tweak to edit it in the properties dialog or advising them to run addpm.  At least on emacswiki.  

I'm sure we can get addpm to do it.  We should make it conditional on what the OS is.  It shouldn't try to add the AppID on older versions of Windows that don't support property stores in shortcuts (anything before Windows 7).  There might be other issues.  


On Thu, Oct 22, 2015 at 4:11 PM, David Vanderschel <address@hidden> wrote:
On 10/21/2015 10:29 PM, Rob Davenport wrote:
Since it seems to work by default for most people (have only heard David and I having issues), I don't think it's a high priority issue.

How did you infer that?  I see only one 'success' reported in this thread:

On 10/18/2015 4:09 PM, Ben Key wrote:
I got this to work as expected, as follows.

1. Use the AddPm program to create the shortcut. I ran it as an administrator. The shortcut was added to "c:\ProgramData\Microsoft\Windows\Start Menu\Programs\Gnu Emacs\Emacs.lnk."
2. Use win7appid to set the App ID of the Emacs.lnk to GNU.Emacs.
3. Start Emacs using that shortcut.
4. Pin to the taskbar.

I added the emphasis on step 2.  No "default" there.

I'd grant that it is not a high urgency issue, but it should not be ignored either.

If it is too cumbersome to set the ID in addpm, couldn't addpm just invoke the C++ app ID setting program to do it?  The only issue I see there is that the C++ program would have to be in the distribution, but it is open source with the more lenient BSD License (not even mentioned in the source).  (There may be complications here that I don't appreciate.)

  David V.

reply via email to

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