help-emacs-windows
[Top][All Lists]
Advanced

[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: Fri, 23 Oct 2015 12:04:57 -0400

On Windows 8, I started with runemacs.  Pinned it.  Taskbar shortcut did have AppUserModelID of GNU.Emacs.
But starting a second instance via runemacs resulted in two icons on taskbar.  Going to taskbar properties, saw the
"Taskbar buttons:" option was set to "Combine when taskbar is full" and the taskbar was not full.
Changed to "Always combine, hide labels" and now the icons on the taskbar are grouped.
Should check the taskbar properties on the other OS's. Grouping of icons won't work the way David expects
if it is set to "Never combine" or "Combine when taskbar is full".

Checked on Windows 7, same behavior.  Which is odd, because I know I've seen this problem on Win7 before and Win8
and changing shortcut from emacs.exe to runemacs.exe seemed to work.  But yes, it seems something changed in Windows 10.

Will retest on Windows 10 later. Even in Windows 10 if the appid is set in the taskbar shortcut, then icons are grouped correctly
- which tells me that the Set...ID call works.  I believe the problem is that the act of pinning creates a shortcut
without the AppUserModelID for some reason.  I haven't found anything out about why, so Eli's right, if someone can ask
Microsoft somehow what's different and if Emacs needs to change somehow so that Windows can correctly deduce the appid
when pinning, that would be good.

I don't know how Windows determines the appid to use in the shortcut it creates when pinning in Win7/Win8.
It can interrogate the Window of the process being pinned.
For Windows store apps there's an XML file it seems that gets queried.
I think the assumption at MS is that shortcuts get created by an applications installer (MSI) which supports
setting the shortcut's appid.  Emacs doesn't use a typical Windows installer, addpm is the closest thing in that it creates shortcuts.
I've fixed up my code a bit so it compiles under MSVC but I don't have mingw set up to actually build it.
If you want, feel free to try this change until I can build it. (Still need error handling.  It won't try to set the appid on OS's that don't support the PropertyStore interface on a shell link, so it should be fine for general use.)
If this works, then addpm could be the recommended approach if encountering this problem on Win10 - run addpm to create the shortcut,
then move that to the taskbar.


diff addpm.c addpm2.c
303a304,309
>      const PROPERTYKEY KEY_AppUserModel_ID =
>         { { 0x9F4C2855, 0x9F79, 0x4B39,
>       { 0xA8, 0xD0, 0xE1, 0xD4, 0x2D, 0xE1, 0xD5, 0xF3, } }, 5 };
>      const PROPERTYKEY* PKEY_AppUserModel_ID = &KEY_AppUserModel_ID;
307a314,335
>      // get the shortcut's propertystore interface
>      IPropertyStore *store;
>      result = IShellLinkA_QueryInterface (shortcut, &IID_IPropertyStore,
>                                           (void **) &store);
>      if (SUCCEEDED(result)) {
>      // then must be on OS that supports property stores,
>      // set AppUserModelID.  Note: Don't try setting NoPin or other properties
>      // that are not supported on Windows7 without checking OS level better.
>      PROPVARIANT pv;
>      result = InitPropVariantFromString(L"GNU.Emacs", &pv);
>      
>      result = IPropertyStore_GetValue(store, PKEY_AppUserModel_ID, &pv);
>      result = IPropertyStore_SetValue(store, PKEY_AppUserModel_ID, &pv);
>      result = IPropertyStore_Commit(store);
>      
>      result = IPropertyStore_Release(store);
>      }
>      // save the shortcut file
334a363,368
>      const PROPERTYKEY KEY_AppUserModel_ID =
>         { { 0x9F4C2855, 0x9F79, 0x4B39,
>       { 0xA8, 0xD0, 0xE1, 0xD4, 0x2D, 0xE1, 0xD5, 0xF3, } }, 5 };
>      const PROPERTYKEY* PKEY_AppUserModel_ID = &KEY_AppUserModel_ID;
338a373,394
>      // get the shortcut's propertystore interface
>      IPropertyStore *store;
>      result = IShellLinkA_QueryInterface (shortcut, &IID_IPropertyStore,
>                                           (void **) &store);
>      if (SUCCEEDED(result)) {
>      // then must be on OS that supports property stores,
>      // set AppUserModelID.  Note: Don't try setting NoPin or other properties
>      // that are not supported on Windows7 without checking OS level better.
>      PROPVARIANT pv;
>      result = InitPropVariantFromString(L"GNU.Emacs", &pv);
>      
>      result = IPropertyStore_GetValue(store, PKEY_AppUserModel_ID, &pv);
>      result = IPropertyStore_SetValue(store, PKEY_AppUserModel_ID, &pv);
>      result = IPropertyStore_Commit(store);
>      
>      result = IPropertyStore_Release(store);
>      }
>      // save the shortcut file


On Fri, Oct 23, 2015 at 10:14 AM, Eli Zaretskii <address@hidden> wrote:
> From: Juanma Barranquero <address@hidden>
> Date: Fri, 23 Oct 2015 15:47:52 +0200
> Cc: Rob Davenport <address@hidden>,
>       "address@hidden" <address@hidden>, David Vanderschel <address@hidden>
>
> As I said, the calls to Set...ID do succeed when I run runemacs.exe or
> emacs.exe from inside GDB. So I don't think that's the problem.

So the conclusion is AFAIU this: Windows 10 changed the behavior wrt
the AppID of the shortcuts pinned to the taskbar: where previous
versions "inherited" the AppID of the application that was pinned,
Windows 10 doesn't.  Is that correct?

Maybe someone could ask on some Microsoft forum whether indeed there
was a change in behavior here, and if so, what is its rationale.  It
could even be a bug in Windows 10.

Thanks.



reply via email to

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