GNU bug report logs - #1849
Windows 7 Taskbar Support

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1849 in the body.
You can then email your comments to 1849 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Michael Kleehammer" <michael <at> kleehammer.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Windows 7 Taskbar Support
Date: Sat, 10 Jan 2009 12:33:36 -0600

To work well with the upcoming Windows 7, the Windows version of emacs will need
to start from emacs.exe without allocating the extra console window.  This means
it will need to be linked as a GUI program instead of a console program.

In previous versions of Windows, the Quick Launch shortcuts were small icons
that launched programs.  The programs were then allocated a new button in the
taskbar.  Windows 7 consolidates these: the shortcuts are also the taskbar
buttons.  Similar to the Mac OS/X dock, when a program that has a shortcut is
run, it is not allocated a new taskbar button - instead, the shortcut is
highlighed differently.

This obviously assumes that the program consists of a single main executable
that the shortcut launches.  Unfortunately, emacs on Windows is a console
program which creates an unwanted "DOS" window.  To run as a GUI, a special GUI
launcher named runemacs.exe is used which hides the console window.

To launch emacs, the user will need to pin runemacs.exe.  When launched, it
starts emacs.exe and immediately exits, causing two problems: (1) the shortcut
does not stay highlighted to indicate the program is running and (2) a 2nd
taskbar button is created for emacs.exe.

If a user pins emacs.exe, it will always create an extra console window, so that
is not an option either.

The proper "fix" is to compile the Windows version of emacs.exe as a GUI
program, not a console program, which is a very simple change.  It would
eliminate the ability to run emacs on Windows in a console window, however.

First, this is probably acceptable to 99% of users.  In fact, I don't know of
anyone that runs emacs on Windows in a console, but I'm sure someone does.
(Remember, there is no SSH or the like; we're talking Windows here ;)

If needed, the makefile could be updated to build either or both.

I think it would be simple to compile the program as a GUI program but have the
-nw flag allocate a console when needed.

Message #12 received at 1849 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>,
        1849 <at> debbugs.gnu.org
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Sun, 11 Jan 2009 22:21:22 +0800

severity 1849 wishlist
thanks

Michael Kleehammer wrote:
> I think it would be simple to compile the program as a GUI program but have the
> -nw flag allocate a console when needed.
>   

I had already considered this approach to offer limited multi-tty 
functionality on Windows (limited because Windows limits programs to one 
console at a time). I think it is the right way to deal with this, but 
I'm not sure that I agree with your claim that it would be simple (you 
can't just open any console for -nw, it has to follow the same behavior 
as a program that is compiled as a console program).

Message #19 received at 1849 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: 1849 <at> debbugs.gnu.org
Subject: emacs on Windows 7
Date: Mon, 11 May 2009 19:04:09 -0500

[Message part 1 (text/plain, inline)]

After looking at it more, I agree it might not be simple.  However, I do
think a GUI-only version is a better default.  If you agree, what needs to
be done to make it happen?  And is this the right place to discuss?  Thanks.

[Message part 2 (text/html, inline)]

Message #24 received at 1849 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Ben Straub <ben <at> straubnet.net>
To: 1849 <at> debbugs.gnu.org
Subject: emacs on Windows 7
Date: Sat, 30 May 2009 07:47:25 -0700

It seems Microsoft has anticipated this.

The fix is for all executables that want to stack their icons to set
an Application Identifier, as documented at
http://msdn.microsoft.com/en-us/library/dd378459.aspx. Just have
emacsclientw.exe and emacs.exe call
SetCurrentProcessExplicitAppUserModelID with the same string (I
suggest "GNU.Emacs") during their startup.

 I've submitted a patch to emacs-devel
(http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00461.html),
though I wasn't aware this bug existed then.

Message #29 received at 1849 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> f2s.com>
To: Ben Straub <ben <at> straubnet.net>, 1849 <at> debbugs.gnu.org
Subject: Re: bug#1849: emacs on Windows 7
Date: Sun, 31 May 2009 15:02:14 +0800

tags 1849 +patch
thanks

Ben Straub wrote:
>  I've submitted a patch to emacs-devel
> (http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00461.html),
> though I wasn't aware this bug existed then.
>   

Thanks, we'll probably install it as soon as the 23.1 branch is cut.

Message #36 received at 1849-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> f2s.com>
To: 1849-done <at> debbugs.gnu.org
Cc: Ben Straub <ben <at> straubnet.net>
Subject: Re: bug#1849: emacs on Windows 7
Date: Tue, 30 Jun 2009 23:57:19 +0800

Jason Rumney wrote:
> Ben Straub wrote:
>>  I've submitted a patch to emacs-devel
>> (http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00461.html),
>> though I wasn't aware this bug existed then.
>>   
>
> Thanks, we'll probably install it as soon as the 23.1 branch is cut.

A similar patch is now installed.

Message #45 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: 1849 <at> debbugs.gnu.org
Subject: Windows 7 Taskbar Support
Date: Sat, 07 Jan 2012 12:26:54 +0800

Reopened.

It seems that this is only partially done.  Emacs, emacsclient and
runemacs are setting the AppUserModel ID consistently, so when running
their windows will group together. But there are two remaining changes
before this can be considered complete:

1. Set the AppUserModel ID on the shortcut created by addpm.exe, so
dragging the shortcut to the taskbar will work as expected (pinned
shortcut grouped with windows of running emacs).

2. Set the AppUserModel RelaunchCommand property of Emacs windows to
"runemacs.exe" so that pinning an running Emacs instance works as expected
(launch via runemacs.exe so the command window does not show).


Unfortunately both of these require directly using the IPropertyStore
interface, which is only available on Windows versions since Vista, and
is missing from current mingw32 headers, so a significant amount of
reverse engineering system headers will be involved.

Message #48 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 1849 <at> debbugs.gnu.org
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Mon, 9 Jan 2012 18:40:26 +0100

On Sat, Jan 7, 2012 at 05:26, Jason Rumney <jasonr <at> gnu.org> wrote:

> 2. Set the AppUserModel RelaunchCommand property of Emacs windows to
> "runemacs.exe" so that pinning an running Emacs instance works as expected
> (launch via runemacs.exe so the command window does not show).
>
> Unfortunately both of these require directly using the IPropertyStore
> interface,

If I'm reading the docs right, this also means that, instead of
SetCurrentProcessExplicitUserModelID, we'll have to use the
IPropertyStore to set the AppUserModelID at the window level:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd378459(v=vs.85).aspx

"When an application sets an explicit AppUserModelID at the window
level, the application can provide the specifics of its relaunch
command for its taskbar button."

Doc for SHGetPropertyStoreForWindow says: "A window's properties must
be removed before the window is closed. If this is not done, the
resources used by those properties are not returned to the system. A
property is removed by setting it to the PROPVARIANT type VT_EMPTY."

So it seems like there will be initialization and cleanup for every
frame creation/destruction.

    Juanma

Message #51 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Michael Kleehammer" <michael <at> kleehammer.com>
Cc: 1849 <at> debbugs.gnu.org
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Mon, 29 Feb 2016 15:20:15 +1100

"Michael Kleehammer" <michael <at> kleehammer.com> writes:

> To work well with the upcoming Windows 7, the Windows version of emacs will need
> to start from emacs.exe without allocating the extra console window.  This means
> it will need to be linked as a GUI program instead of a console program.

[...]

Jason Rumney <jasonr <at> gnu.org> writes:

> Reopened.
>
> It seems that this is only partially done.  Emacs, emacsclient and
> runemacs are setting the AppUserModel ID consistently, so when running
> their windows will group together. But there are two remaining changes
> before this can be considered complete:
>
> 1. Set the AppUserModel ID on the shortcut created by addpm.exe, so
> dragging the shortcut to the taskbar will work as expected (pinned
> shortcut grouped with windows of running emacs).
>
> 2. Set the AppUserModel RelaunchCommand property of Emacs windows to
> "runemacs.exe" so that pinning an running Emacs instance works as expected
> (launch via runemacs.exe so the command window does not show).
>
> Unfortunately both of these require directly using the IPropertyStore
> interface, which is only available on Windows versions since Vista, and
> is missing from current mingw32 headers, so a significant amount of
> reverse engineering system headers will be involved.

This was four years ago.  Has this been fixed in the meantime?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #54 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1849 <at> debbugs.gnu.org, michael <at> kleehammer.com
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Mon, 29 Feb 2016 17:26:29 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 29 Feb 2016 15:20:15 +1100
> Cc: 1849 <at> debbugs.gnu.org
> 
> > It seems that this is only partially done.  Emacs, emacsclient and
> > runemacs are setting the AppUserModel ID consistently, so when running
> > their windows will group together. But there are two remaining changes
> > before this can be considered complete:
> >
> > 1. Set the AppUserModel ID on the shortcut created by addpm.exe, so
> > dragging the shortcut to the taskbar will work as expected (pinned
> > shortcut grouped with windows of running emacs).
> >
> > 2. Set the AppUserModel RelaunchCommand property of Emacs windows to
> > "runemacs.exe" so that pinning an running Emacs instance works as expected
> > (launch via runemacs.exe so the command window does not show).
> >
> > Unfortunately both of these require directly using the IPropertyStore
> > interface, which is only available on Windows versions since Vista, and
> > is missing from current mingw32 headers, so a significant amount of
> > reverse engineering system headers will be involved.
> 
> This was four years ago.  Has this been fixed in the meantime?

No, and it probably never will be.

Message #61 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1849 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 michael <at> kleehammer.com
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Sun, 19 Sep 2021 09:20:43 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Mon, 29 Feb 2016 15:20:15 +1100
>> Cc: 1849 <at> debbugs.gnu.org
>>
>> > It seems that this is only partially done.  Emacs, emacsclient and
>> > runemacs are setting the AppUserModel ID consistently, so when running
>> > their windows will group together. But there are two remaining changes
>> > before this can be considered complete:
>> >
>> > 1. Set the AppUserModel ID on the shortcut created by addpm.exe, so
>> > dragging the shortcut to the taskbar will work as expected (pinned
>> > shortcut grouped with windows of running emacs).
>> >
>> > 2. Set the AppUserModel RelaunchCommand property of Emacs windows to
>> > "runemacs.exe" so that pinning an running Emacs instance works as expected
>> > (launch via runemacs.exe so the command window does not show).
>> >
>> > Unfortunately both of these require directly using the IPropertyStore
>> > interface, which is only available on Windows versions since Vista, and
>> > is missing from current mingw32 headers, so a significant amount of
>> > reverse engineering system headers will be involved.
>>
>> This was four years ago.  Has this been fixed in the meantime?
>
> No, and it probably never will be.

That was five years ago.  Presumably, if it will never be fixed, life
will move on and Windows 7 will be left on the dustbin of history.

Should we just go ahead and close this as wontfix?  Lars?

Message #64 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1849 <at> debbugs.gnu.org, larsi <at> gnus.org, michael <at> kleehammer.com
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Sun, 19 Sep 2021 20:13:40 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 19 Sep 2021 09:20:43 -0700
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1849 <at> debbugs.gnu.org, michael <at> kleehammer.com
> 
> >> > Unfortunately both of these require directly using the IPropertyStore
> >> > interface, which is only available on Windows versions since Vista, and
> >> > is missing from current mingw32 headers, so a significant amount of
> >> > reverse engineering system headers will be involved.
> >>
> >> This was four years ago.  Has this been fixed in the meantime?
> >
> > No, and it probably never will be.
> 
> That was five years ago.  Presumably, if it will never be fixed, life
> will move on and Windows 7 will be left on the dustbin of history.
> 
> Should we just go ahead and close this as wontfix?  Lars?

I'm not Lars, but I think that we should close it, indeed.

Message #67 received at 1849 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1849 <at> debbugs.gnu.org, larsi <at> gnus.org, michael <at> kleehammer.com
Subject: Re: bug#1849: Windows 7 Taskbar Support
Date: Sun, 19 Sep 2021 10:38:37 -0700

tags 1849 wontfix
close 1849
thanks

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefan <at> marxist.se>
>> Date: Sun, 19 Sep 2021 09:20:43 -0700
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1849 <at> debbugs.gnu.org, michael <at> kleehammer.com
>>
>> >> > Unfortunately both of these require directly using the IPropertyStore
>> >> > interface, which is only available on Windows versions since Vista, and
>> >> > is missing from current mingw32 headers, so a significant amount of
>> >> > reverse engineering system headers will be involved.
>> >>
>> >> This was four years ago.  Has this been fixed in the meantime?
>> >
>> > No, and it probably never will be.
>>
>> That was five years ago.  Presumably, if it will never be fixed, life
>> will move on and Windows 7 will be left on the dustbin of history.
                                           ^^ in
>>
>> Should we just go ahead and close this as wontfix?  Lars?
>
> I'm not Lars, but I think that we should close it, indeed.

OK, thanks.  Closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.