bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Emacs bug Tracking System
Subject: bug#1849: marked as done (Windows 7 Taskbar Support)
Date: Tue, 30 Jun 2009 16:05:07 +0000

Your message dated Tue, 30 Jun 2009 23:57:19 +0800
with message-id <address@hidden>
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 address@hidden
immediately.)


-- 
1849: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1849
Emacs Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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.



--- End Message ---
--- Begin Message --- Subject: Re: bug#1849: emacs on Windows 7 Date: Tue, 30 Jun 2009 23:57:19 +0800 User-agent: Thunderbird 2.0.0.22 (Windows/20090605)
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.


--- End Message ---

reply via email to

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