bug#1849: Windows 7 Taskbar Support

bug#1849: Windows 7 Taskbar Support

[Michael Kleehammer]

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.

bug#1849: Windows 7 Taskbar Support

[Jason Rumney]

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).

Processed: Re: bug#1849: Windows 7 Taskbar Support

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 1849 wishlist
bug#1849: Windows 7 Taskbar Support
Warning: Unknown package 'w32'
Severity set to `wishlist' from `normal'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#1849: marked as done (Windows 7 Taskbar Support)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]


Your message dated Tue, 30 Jun 2009 23:57:19 +0800
with message-id <4A4A35DF.4040106@f2s.com>
and subject line Re: bug#1849: emacs on Windows 7
has caused the Emacs bug report #1849,
regarding Windows 7 Taskbar Support
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1849: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1849
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5071 bytes --]

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

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.



[-- Attachment #3: Type: message/rfc822, Size: 3034 bytes --]

From: Jason Rumney <jasonr@f2s.com>
To: 1849-done@emacsbugs.donarmstrong.com
Cc: Ben Straub <ben@straubnet.net>
Subject: Re: bug#1849: emacs on Windows 7
Date: Tue, 30 Jun 2009 23:57:19 +0800
Message-ID: <4A4A35DF.4040106@f2s.com>

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.

bug#1849: Windows 7 Taskbar Support

[Jason Rumney]

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.

bug#1849: Windows 7 Taskbar Support

[Juanma Barranquero]

On Sat, Jan 7, 2012 at 05:26, Jason Rumney <jasonr@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

bug#1849: Windows 7 Taskbar Support

[Lars Ingebrigtsen]

"Michael Kleehammer" <michael@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@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

bug#1849: Windows 7 Taskbar Support

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 29 Feb 2016 15:20:15 +1100
> Cc: 1849@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.

bug#1849: Windows 7 Taskbar Support

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Mon, 29 Feb 2016 15:20:15 +1100
>> Cc: 1849@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?

bug#1849: Windows 7 Taskbar Support

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 19 Sep 2021 09:20:43 -0700
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 1849@debbugs.gnu.org, michael@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.

bug#1849: Windows 7 Taskbar Support

[Stefan Kangas]

tags 1849 wontfix
close 1849
thanks

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Sun, 19 Sep 2021 09:20:43 -0700
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 1849@debbugs.gnu.org, michael@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.