Someone needs to get rid of that stupid text console on Win32.

What about the error console tab?

(When I first got 2.0 I thought that's where the errors
would be sent.  I've only just started looking at the 
code, so I can only offer a user-level suggestion.)

GIMP errors are sent there. Warnings about programming errors or messages caused
by libraries go to stdout/stderr.

Ah, I see.  Yick.  Sounds like a lot of work and there'd be
little guarantee that all libraries could be modified (or
have those modifications added to their projects permanently),
much less all the plugins.  Maybe some kind of low level hack
could take over stdout/stderr handles (which I assume get passed
to the plugins) - but it'd be a hack.  Regular command-line
redirection "&>2 nul" IIRC works, does it not?  What happens on Linux
to stdout/err messages from libraries and/or plugins?

Perhaps an option to hide the console window a la Console
<http://sourceforge.net/projects/console>?  Though that program
provides a context menu option to show it again.  Or perhaps 
minimizing it to the system tray?

An easy workaround would indeed be to start GIMP from a batch file like this:

start gimp.exe > nul 2>&1

On Linux the error messages go to the console that GIMP was started from or if
started from a desktop menu, the messages go whereever the desktop redirects the
output to. Usually this means that users never see those messages which is OK
since they aren't meant to be seen by users.

I'd suggest we ask for the installer to be changed to redirect the output as
Michael suggested in comment #5.

The first argument to START is a title, 
if we also want to use command line parameters.
I added /B on the command line to 
"Start application without creating a new window."
but it doesn't seem to create a new DOS window 
without the option.  Does it help anything here?
Are there any issues with gimp-win-remote and 
file type association in all of this?

set GIMPPATH=C:\Program Files\GIMP-2.0\bin
path %GIMPPATH%;%PATH%
start "The GIMP" /B /D"%HOMEPATH%" "%GIMPPATH%\gimp-2.0.exe" --use-wintab > nul 
2>&1  

Good idea, Shaneyfelt. It would need a tiny tweak though: adding %~sn parameters
to accept files to open (and "%*" won't expand them to fully qualified path
names).  Also, the installer for Windows would need to tweak the GIMPPATH line
to point to the actual Gimp path during installation.  That's possible, but I'm
not familiar enough with the install program Mr. Simoncic is using to say how
difficult it would be to do.

-----------------STARTGIMP.CMD----------------------
set GIMPPATH=d:\Progra~1\GIMP-2.0\bin
path %GIMPPATH%;%PATH%
start "The GIMP" /B /D"%HOMEPATH%" "%GIMPPATH%\gimp-2.0.exe" %~s1 %~s2 %~s3 %~s4
%~s5 %~s6 %~s7 %~s8 %~s9 > nul 2>&1
----------------------------------------------------

So I created the .CMD file above, though without the --use-wintab flag as I
don't use that, but it could also be added during installation.  The %~sn
parameters expand input parameters into fully qualified path names using short
filename (necessary if the image files aren't in %HOMEPATH%; could use %~fn if
you have no spaces in your path names).

I put it in my c:\usr\local\bin directory, and changed the default value for the
registry key: 
 HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\gimp-2.0.exe
to point to this .cmd file ("c:\usr\local\bin\startgimp.cmd").
And gimp-win-remote will either start the Gimp or post a DROPFILES message to
send it files to open.  

The only issue was that the console window for the command processor (CMD.EXE)
handling the startgimp.cmd script flashes past.  Since console windows, be they
flashing or not, seem anathema to some Windows users, I modified
gimp-win-remote.c to take care of that.  Since it gets the command to launch the
Gimp from that registry key above, I had it change the flags to ShellExecute to
be SW_HIDE when launching a .cmd or .bat file (like startgimp.cmd), and SW_SHOW
otherwise (when it's assumed to be gimp's executable).  This works for me,
gimp-win-remote now starts the Gimp without the console window for the
startgimp.cmd script flashing up.

However, since the App Paths key now indicates the startgimp.cmd file is the app
to run to launch the Gimp (as far as Windows is concerned), other applications
that start the Gimp via that script (e.g. the Windows "Run..." box) will work,
but the console window will flash by.  Not much can be done about that other
than having people configure their launching mechanism of choise to use
gimp-win-remote.exe to start their Gimps.  For instance, just calling
startgimp.cmd on the command-line will launch a new Gimp process each time,
calling gimp-win-remote is necessary.  So I also created another script file
"2gimp.bat" which calls gimp-win-remote.exe (with expanded input files via %~sn
like above), and a doskey alias to call 2gimp.bat and that lets me say "gimp
image.jpg" on the command-line and either start the Gimp or send the filename to
it, without the console windows.

I will attach my updated gimp-win-remote.c and a modified startgimp.cmd that,
just FYI.  I'll also send this to Mr. Simoncic and Mr. Bruck (gimp-win-remote
maintainer on Sourceforge) as that's where the changes would need to be made.

Created attachment 31556 [details]
Modified gimp-win-remote.c to hide script console windows

I modified gimp-win-remote.c to change the flag sent to the ShellExecute method
to be SW_HIDE when the application being launched is a script (.cmd or .bat
extension), and SW_SHOW otherwise (when it's the Gimp executable).  This will
allow scripts to be used to launch the Gimp with "start /B" and ">nul 2>&1" to
prevent console windows from appearing.

Created attachment 31557 [details]
Windows script to launch the Gimp without a console window

A Windows script file that launches the Gimp with "start /B" and ">nul 2>&1" so
no console window is created and stdout/err output go to the nul device.
(Modified from Shaneyfelt's suggestion for this bug.

I should point out that a .PIF file can probably be used to make Windows not pop
up a console for the .cmd file.  It certainly does for a regular .bat.

Good point. You can have it start the cmd processor Minimized, but not hidden
(that I can tell) so it still flashes on the taskbar. That may be sufficient on
faster computers, and wouldn't require changes to gimp-win-remote, isolating the
changes to the Gimp installation only.  If Mr. Bruck wants to change
gimp-win-remote, people can use that if the taskbar flashing is still annoying.
Can a PIF file be created programmatically during installation or would this be
better as a FAQ that interested users could implement themselves?

Well, I try to avoid Windows whenever possible, but I believe it's possible to
have relative paths in the PIF, so you can just include it as a file that gets
install to the same directory that the .cmd file gets installed to

Actually, I looked into the Inno Setup installer Mr. Simoncic uses and it's easy
enough to create a shortcut (LNK file) to the Gimp with the path correct and the
"runminimized" setting, so that can be done easily.  (So my efforts at modifying
gimp-win-remote are not useful - too bad, I was happy to have been able to
contribute something.)  It could all be done in the installer - though creating
the "startgimp.cmd" file is a little trickier (in order to put the installation
path in the "set GIMPPATH" line) but it's certainly possible.

However, Mr. Simoncic told me last night that the next version of GLib will
likely do away with the console windows, so this whole issue may be moot.

(I do wonder though where the output messages will go - I hope not into the bit
bucket.  I actually like the console windows and usually run the Gimp with
--verbose, but then again, I'm a programmer and I like seeing all the messages
on startup.)

Sorry, but by default they indeed will from the next version of GLib go to the 
bit bucket (for GUI exes). Redirect to a file or pipe to see them. (Or run the 
MSYS shell, which sets the standard output and error handles even for GUI exes, 
or something, I haven't really investigated what it does, but anyway if you run 
gimp-2.0 --verbose from MSYS's shell, you do see the output.)

See also bug #141102, where I at first had the idea to just make the console 
windows have garish colours so that people would stop calling them "DOS 
boxes" ;-) But this "feature" that selecting text in a console window hangs the 
application means they must die.

Goodbye AllocConsole. Fixed in GLib, branches glib-2-4 and HEAD:

2004-09-22  Tor Lillqvist  <tml@iki.fi>

	* glib/gmessages.c: [Win32] Don't ever open a console
	window. (Which we used to do if standard output or standard error
	are invalid, as they are for GUI applications.) These console
	windows that open up unexpectedly have caused endless amounts of
	confusion among end-users. (#141102, #151175)

	Don't output the process id on Windows. Only output the program
	name. If not set with g_set_prgname(), fetch the application
	executable's name and use that.

Thanks :)

Thanks Tor.  I suppose it is for the best, though I didn't mind the console
windows.  (Maybe if it had made the window title "CONSOLE" people would be a bit
less likely to call them "DOS boxes", though I like the garish color idea. :)

I can certainly handle redirecting output to a file or using MSYS if I want to
check for errors in the output.