Sven Neumann writes:
> Almost all of the messages that cause this problem don't come from the > GIMP application. They are created by libraries that we are using and > these libaries aren't necessarily using g_print() and g_printerr().

Nope, you have it backwards. 3rd-party libraries who write to stdout directly don't cause them.

> Also I don't see why we should be redirecting stdout and stderr. > Everything that shows up there is strictly just for the eyes of > developers.

Some clarification here: The GIMP executable is linked as a "GUI" application. This means that it doesn't have any console window when it starts. stdout and stderr are not connected to anything. Writing to them doesn't go anywhere, and certainly doesn't open a console window for the application.

It's the g_print() etc functions that explicitly open a new console window if stdout (or stderr) isn't connected to a valid file handle.

It would be possible to make it impossible to close the console window that GLib opens, by removing the close button from it. Then users would know just to minimize it if they aren't interested in the messages. See my last comment in bug #141102.

> We use g_message() for all messages that are meant to be > seen by users. Such messages then are processed by the following logic: >
> If GIMP was started with the --console-messages command-line > option, the messages go the console (stdout iirc).

Hmm, if most GIMP users on X11 start GIMP through some window manager whose stdout isn't visible, is that option then really supposed to mean "don't show messages"?

I guess there is a mismatch in the ways of thinking here: GIMP thinks that writing to stdout means the output will mostly go somewhere where the user doens't see it, unless he explicitly does something unusual (starts GIMP from the command line).

The Win32 code in GLib again thinks that g_print() etc messages are *important*, and supposed to be shown to the user in some way, even opening a new console window if there isn't one already. If the user wants to redirect stdout and stderr (to NUL: or a file), he can do it from the command line.

--tml

Hi,

It would be possible to make it impossible to close the console window that GLib opens, by removing the close button from it. Then users would know just to minimize it if they aren't interested in the messages. See my last comment in bug #141102.

It's often a habitual thing for windows users, minimizing a console window that displays constant warning messages often isn't enough satisfaction for some. May be GIMP could have a preference option where the user can choose to have these g_print based messages redirected to a file using a custom print handler that gets set via g_set_print_handler(..).

Regards,

Alif.

Hi Tor,

I've played around with the g_set_print_handler and the g_log_set_handler functions and they certainly stop the console window from coming up when I use my custom handler to redirect the message to somewhere else. So it may well be a good way to give the user an option of redirecting these stdout and/or stderr messages to somewhere totally invisible.

Regards,

Alif.

On Sat, 11 Sep 2004 06:48:28 +0000, Tor Lillqvist wrote:

Sven Neumann writes:
> Almost all of the messages that cause this problem don't come from the > GIMP application. They are created by libraries that we are using and > these libaries aren't necessarily using g_print() and g_printerr().

Nope, you have it backwards. 3rd-party libraries who write to stdout directly don't cause them.

> Also I don't see why we should be redirecting stdout and stderr. > Everything that shows up there is strictly just for the eyes of > developers.

Some clarification here: The GIMP executable is linked as a "GUI" application. This means that it doesn't have any console window when it starts. stdout and stderr are not connected to anything. Writing to them doesn't go anywhere, and certainly doesn't open a console window for the application.

It's the g_print() etc functions that explicitly open a new console window if stdout (or stderr) isn't connected to a valid file handle.

It would be possible to make it impossible to close the console window that GLib opens, by removing the close button from it. Then users would know just to minimize it if they aren't interested in the messages. See my last comment in bug #141102.

> We use g_message() for all messages that are meant to be > seen by users. Such messages then are processed by the following logic: >
> If GIMP was started with the --console-messages command-line > option, the messages go the console (stdout iirc).

Hmm, if most GIMP users on X11 start GIMP through some window manager whose stdout isn't visible, is that option then really supposed to mean "don't show messages"?

I guess there is a mismatch in the ways of thinking here: GIMP thinks that writing to stdout means the output will mostly go somewhere where the user doens't see it, unless he explicitly does something unusual (starts GIMP from the command line).

The Win32 code in GLib again thinks that g_print() etc messages are *important*, and supposed to be shown to the user in some way, even opening a new console window if there isn't one already. If the user wants to redirect stdout and stderr (to NUL: or a file), he can do it from the command line.

--tml

On Sun, 12 Sep 2004 13:15:37 +0000, Tor Lillqvist wrote:

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

It's handy during development, but annoying for a released app. I'm about to hack something into my app to suppress it (almost all my users get a bunch of harmless but irritating font warnings on startup and then moan on my mailing list).

How about having no console window by default, and add a g_win32_console_whatever() thing which apps could set as a print handler with an #ifdef DEBUG

gtk-app-devel-list people, check the start of this thread from the gimp-developer archives at
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg07988.html

Sven Neumann writes: > There got to be a way to change this behaviour of g_print(), no?

Well, one could redirect stdout and stderr to /dev/null (i.e. NUL: on Windows), either in the command line that starts GIMP, or even in GIMP itself with freopen(). If stdout or stderr are connected to NUL:, they aren't invalid, and g_log() won't open any console window.

One could even go so far that if there is a consensus among GTK+ app developers (whose apps run on Win32) that the opening of console windows in GLib was a silly idea and has been of little use, that code could just be removed. g_print() etc would then write to stdout or stderr, like on Unix, regardless of whether they are connected to anything or not. It would then be the end user's responsibility to redirect stdout/stderr of a GUI application to a file if they want to see whatever might be written to stdout/stderr.

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

Personally I don't have any preference.

--tml

On Sun, 12 Sep 2004 13:15:37 +0000, Tor Lillqvist wrote:

gtk-app-devel-list people, check the start of this thread from the gimp-developer archives at
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg07988.html

Sven Neumann writes: > There got to be a way to change this behaviour of g_print(), no?

Well, one could redirect stdout and stderr to /dev/null (i.e. NUL: on Windows), either in the command line that starts GIMP, or even in GIMP itself with freopen(). If stdout or stderr are connected to NUL:, they aren't invalid, and g_log() won't open any console window.

One could even go so far that if there is a consensus among GTK+ app developers (whose apps run on Win32) that the opening of console windows in GLib was a silly idea and has been of little use, that code could just be removed. g_print() etc would then write to stdout or stderr, like on Unix, regardless of whether they are connected to anything or not. It would then be the end user's responsibility to redirect stdout/stderr of a GUI application to a file if they want to see whatever might be written to stdout/stderr.

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

I too think it's more trouble than it's worth. If nothing else, it's different from how stdout is treated on X (and I assume other ports as well). Since a lot of Windows GTK stuff is just ported over from X, it's likely that the developers don't even know that they are spamming the Windows users.

Rockwalrus

On 12 Sep 2004 15:16:21 +0200, Sven Neumann wrote:

Hi,

Tor Lillqvist writes:

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

+1

Sven

Replying to your own message is a sign of insanity. Guilty as charged. :)

On Sun, 12 Sep 2004 12:47:44 -0400, Nathan Summers wrote:

On Sun, 12 Sep 2004 13:15:37 +0000, Tor Lillqvist wrote:

Sven Neumann writes:

>

One could even go so far that if there is a consensus among GTK+ app developers (whose apps run on Win32) that the opening of console windows in GLib was a silly idea and has been of little use, that code could just be removed. g_print() etc would then write to stdout or stderr, like on Unix, regardless of whether they are connected to anything or not. It would then be the end user's responsibility to redirect stdout/stderr of a GUI application to a file if they want to see whatever might be written to stdout/stderr.

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

I too think it's more trouble than it's worth. If nothing else, it's different from how stdout is treated on X (and I assume other ports as well). Since a lot of Windows GTK stuff is just ported over from X, it's likely that the developers don't even know that they are spamming the Windows users.

On the other hand, if it were just factored off into a separate function, and suitable implementations were provided for the other ports, I could see this as a useful optional g_log handler that a GTK app could choose to install.

Rockwalrus

On Sunday, September 12, 2004, 15:15:37, Tor Lillqvist wrote:

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

How about setting an environment variable? If something like OPEN_CONSOLE is set, open the console window when needed, otherwise not?

Anyway, I'm in favour of not opening the console by default. It's easy enough to change a GUI program to open console on startup, if that's needed.

Hi,

Tor Lillqvist wrote:

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

Me too.

I hate threads that degenerate into this, but it's the most annoying thing possible in a GUI app :)

Cheers, Dave.

On 09/12/04 14:47:14, Sven Neumann wrote:

Tor Lillqvist writes:

I guess there is a mismatch in the ways of thinking here: GIMP thinks that writing to stdout means the output will mostly go somewhere where the user doens't see it, unless he explicitly does something unusual (starts GIMP from the command line).

The Win32 code in GLib again thinks that g_print() etc messages are *important*, and supposed to be shown to the user in some way, even opening a new console window if there isn't one already. If the user wants to redirect stdout and stderr (to NUL: or a file), he can do it from the command line.

There got to be a way to change this behaviour of g_print(), no?

Regardless on what's done in the glib side, why not using g_set_print_handler and g_log_set_handler, as Alif Wahid suggests, to redirect the messages to the Error Console? I, for one, as a user of the Win32 version expected to find the messages there and when they were shown in a different window I wondered why. Perhaps it's also better under Linux so that the messages aren't lost if the user doesn't open gimp from a console.

On Sun, Sep 12, 2004 at 01:15:37PM +0000, Tor Lillqvist wrote:

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

Me. :)

./danfe

Hi Tor,

Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all?

I support this idea, that GLIB shouldn't bother opening a console window at all. Cheers.

Alif.

On 09/13/04 11:04:06, Sven Neumann wrote:

The messages aren't meant for user's eyes, I think I mentioned that. The messages don't make any sense for the user and should only ever seen by developers or when we ask users to start gimp from a console window and to tell us if there are messages to be seen.

Doesn't it make sense to prefix Glib errors with something like: "Glib Error:" or "System Error:" or "Gimp Error:" (localizing just that string) and let the rest appear as-is within the error console?

If you think that a certain messages should be seen by the user and not to go stderr, let us know about it. That message should then use g_message() and also needs to be localized.

No, that's not exactly the case. But using stderr is a bad idea under Windows for the reasons that motivated this thread.

No. The user is not supposed to see them, never. Actually no such messages should ever be emitted. If it does, there's a programming error. It would not help to show these messages to the user.

What about a user who wants to file a bug report? Surely they are relevant in that case?

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

William Skaggs writes:
> What about a user who wants to file a bug report? Surely > they are relevant in that case?

They can then start the GUI app with explicit redirection of stdout and stderr to a file.

--tml

]
]> Doesn't it make sense to prefix Glib errors ]with something like: "Glib
]
]> Error:" or "System Error:" or "Gimp Error:" ](localizing just that
]> string) and let the rest appear as-is within ] the error console?
]
]No. The user is not supposed to see them, never. Actually no such ]messages should ever be emitted. If it does, there's a programming ]error. It would not help to show these messages to the user.

They are useful for bug reports.

I would like to see a clean way to control logging of various messages. The messages would ideally be able to be shown in a real window (not the console), tee to a file, etc. by checking logging options in the user preferences.

The log window (not the console window) should pop up when the first log entry occurs. GTK+ System level logging could be disabled initially, with a checkbox to enable it. Saving the log to a file could also be initially disabled. When scripts running autonomously in non-GUI mode, use stderr or logfile for error messages instead.

Just my opinion.

_-Ted

p.s. But if it's going to hold up the release, stub out the code in this release to do something simpler.

_________________

On Mon, Sep 13, 2004 at 05:39:00PM +0200, Sven Neumann wrote:

Hi,

Pedro Gimeno Fortea writes:

On 09/13/04 11:04:06, Sven Neumann wrote:

The messages aren't meant for user's eyes, I think I mentioned that. The messages don't make any sense for the user and should only ever seen by developers or when we ask users to start gimp from a console window and to tell us if there are messages to be seen.

Doesn't it make sense to prefix Glib errors with something like: "Glib Error:" or "System Error:" or "Gimp Error:" (localizing just that string) and let the rest appear as-is within the error console?

No. The user is not supposed to see them, never. Actually no such messages should ever be emitted. If it does, there's a programming error. It would not help to show these messages to the user.

spew is beautiful though.

i would rather users get over it and even read it.

you guys forget that as soon as the shock of the new thing is over, spew is really really interesting.

carol

shaneyfelt@juno.com writes:
> The messages would ideally be able to be shown in a real window > (not the console)

And what's so unreal about a console window? Is is just that they are black and white and make (some) people think of MS-DOS? (Some call console windows "DOS boxes" and seem to think "A-ha! a DOS box! So GIMP really runs on DOS!" ;-)

> The log window (not the console window) should pop up when the first > log entry occurs.

Please tell me in what way such a "log window" would look and behave differently from a console window? For all intents and purposes, that's what they are supposed to be. Is it just the colours?

(Remember that we are talking about facilities in GLib here. GLib has no GUI. GIMP's "error console" is somehing else.)

> GTK+ System level logging could be disabled initially, with a > checkbox to enable it.

Well, it's GLib that opens a console window if stdout or stderr aren't connected to anything (not even the bit bucket) when g_print(), g_message(), g_warning(), g_error(), g_printerr() etc are called. Where would such a checkbox be? These calls are done for instance by the Pango library, it doesn't have any GUI of its own either.

The consensus so far seem to be that GLib should not open any console windows by itself. OK, fine with me, such a change could be done even in the stable branch (2.4.x) IMHO. But I certainly hope that it doesn't mean that people then will start whining that they want "log windows" for warnings and error messages. Sheesh, that's what the console windows are/were, dammit.

--tml

On Monday, September 13, 2004, 23:26:52, Tor Lillqvist wrote:

The consensus so far seem to be that GLib should not open any console windows by itself. OK, fine with me, such a change could be done even in the stable branch (2.4.x) IMHO. But I certainly hope that it doesn't mean that people then will start whining that they want "log windows" for warnings and error messages. Sheesh, that's what the console windows are/were, dammit.

If anybody wants log windows back, it's easy to change the compilation process to produce a console EXE - or, if the user doesn't have (or doesn't want to use) a compiler, there are programs that can switch an already compiled EXE file between console/GUI applications (it's a matter of changing 1 byte).

Tor Lillqvist wrote:

The consensus so far seem to be that GLib should not open any console windows by itself. OK, fine with me, such a change could be done even in the stable branch (2.4.x) IMHO. But I certainly hope that it doesn't mean that people then will start whining that they want "log windows" for warnings and error messages. Sheesh, that's what the console windows are/were, dammit.

I vote for:
* g_print(): popup a console window; if the programmer is using g_print(), he probably wants to see something. * g_warning(): use OutputDebugString, so the only people who can do something about the warnings can use something like DebugView (from Sysinternals) to see it.
* any other function just use (f)printf.

Daniel K. O.

Hi Tor,

The consensus so far seem to be that GLib should not open any console windows by itself. OK, fine with me, such a change could be done even in the stable branch (2.4.x) IMHO. But I certainly hope that it doesn't mean that people then will start whining that they want "log windows" for warnings and error messages. Sheesh, that's what the console windows are/were, dammit.

Like Jernej mentioned, if anybody wants to have a console window then they just have to compile it without the -mwindows option in GCC and whatever equivalent in MSVC. I think if a developer explicitly compiles a program to be GUI only on win32, then he/she expects to see no console window. So in my humble opinion, I think GLIB should not open a console window if stdout and stderr doesn't exist. I also do not think that a "log window" is necessary since the console window can be so easily obtained.

Developers also have the option of using g_log_set_handler and g_set_print_handler functions for hooking into any messages generated and redirecting them to somewhere else (file, application dialogs etc.).

Perhaps, it would be nice if somehow the console window opened currently could be closed without shutting down the whole GUI application. Unfortunately, windows does not allow that I think. Or does it?

Regards,

Alif.

Here's what a log window would look like:

A log window would have a button that says "Clear" to clear the log and one that says "Close" to close the window, and maybe something that says what file to tee. Nothing should shutdown the GUI unless clearly marked and accompanied by a clear confirmation that says on the button "QUIT AND DISCARD CHANGES" or similar text.

This log window would be nice, but it's probably not worth all the fuss - for this release, at least.

The important thing is to not allow a Windows console to come up and kill the application like it does.

_-Ted

_________________

Hi,

It doesn't make sense to have such log windows as a part of GLIB. Sounds like this sort of log window could really come in handy as part of GTK perhaps?

I think somehow the console window can be made closeable but when closed, doesn't shut down the whole app, then that would be ideal solution. Anyone know if it is possible to close some sort of a console window and still keep other proper GUI windows open so the app doesn't exit?

Regards,

Alif.

On Tue, 14 Sep 2004 02:14:48 GMT, shaneyfelt@juno.com wrote:

Here's what a log window would look like:

A log window would have a button that says "Clear" to clear the log and one that says "Close" to close the window, and maybe something that says what file to tee. Nothing should shutdown the GUI unless clearly marked and accompanied by a clear confirmation that says on the button "QUIT AND DISCARD CHANGES" or similar text.

This log window would be nice, but it's probably not worth all the fuss - for this release, at least.

The important thing is to not allow a Windows console to come up and kill the application like it does.

_-Ted

________________________________________________________________ Get your name as your email address. Includes spam protection, 1GB storage, no ads and more Only $1.99/ month - visit http://www.mysite.com/name today! _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

See KB article 818361 concerning disabling the close button on the title bar. This seems to be the important part:

hWnd = ObtainWindowHandle(name); hMenu = GetSystemMenu(hWnd, false);
DeleteMenu(hMenu, 6, 1024);

I haven't tried it. You probably have the window handle and don't need the first line. Just guessing.

_-Ted

_________________

--- Tor Lillqvist wrote:

The consensus so far seem to be that GLib should not open any console windows by itself. OK, fine with me, such a change could be done even in the stable branch (2.4.x) IMHO. But I certainly hope that it doesn't mean that people then will start whining that they want "log windows" for warnings and error messages. Sheesh, that's what the console windows are/were, dammit.

--tml

This is EXACTLY what will happen -- People will say: "Stupid glib is dumping core -- (or should I say "crashing" since we are talking about windows?) and I have no clue where in MY program I am messing up --

Leave the DOS-Window, console window, DOS box alone !!!

What is the trade off -- Have a "DOS box" or find potential problems faster ?

PS - If the user is scared of the "DOS box" -- Why wouldn't she be scared of a log window as well ?

HF.

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Harring,

The serious problem is not that the dos console looks scary, although it is ugly, that would be ok for ms windows. The problem is that windows hangs any application with a console window if someone happens to click on the text in the box, for example, to copy it, or by accidentally touching it with a stylus. This is the serious problem, not some sort of confusion over what a console window is.

Actually what is happening is the application gets suspended at the next console output until the selected area on the console is unselected. Obviously, if ms windows were any good, it would queue the output rather than suspending the GUI application, but the typical user can't distinguish this problem from a crashed GIMP. However, it is in our power to work around the problem. One such workaround is to only use a console if a command line option (like --console) or an environment variable is set.

Ted

_________________

On Fri, 17 Sep 2004 18:59:38 GMT, shaneyfelt@juno.com wrote:

However, it is in our power
to work around the problem. One such workaround is to only use a console if a command line option (like --console) or an environment variable is set.

Since gtk already meddles with the program's arguments, it's not unreasonable for this to be done at the gtk level.

Rockwalrus

I wrote:
> > Except that on Windows it's not "or", but "and". Just starting a GUI > > application from a command shell in a console window doesn't make its > > stderr and stdout connected.

Iago Rubio writes: > True, but I think my point of view is still valid. No Windoze app opens > a console for output.

Yes. My point was mostly directed to Unix-oriented people to warn them not to think or advice Windows users that "just start the application from a command prompt and you will see the output". It isn't that easy.

For instance to see the help text from "gimp --help" on Windows one has to pipe its output to more. (Currently, with the console-window-opening still in GLib, the text output appears in a console window that opens but that then immediately closes when GIMP terminates...)

Unfortunately there doesn't seem to be any way for a Windows application to check whether it has actually been started from a command interpreter in a console window, and not Explorer (so that it might in that case attach its stdout and stderr to that console window). Or is there? I can't even find any API to find out the parent process of a process...?

--tml

Tor Lillqvist wrote:

I wrote:
> > Except that on Windows it's not "or", but "and". Just starting a GUI > > application from a command shell in a console window doesn't make its > > stderr and stdout connected.

Iago Rubio writes: > True, but I think my point of view is still valid. No Windoze app opens > a console for output.

Yes. My point was mostly directed to Unix-oriented people to warn them not to think or advice Windows users that "just start the application from a command prompt and you will see the output". It isn't that easy.

For instance to see the help text from "gimp --help" on Windows one has to pipe its output to more. (Currently, with the console-window-opening still in GLib, the text output appears in a console window that opens but that then immediately closes when GIMP terminates...)

When started from the MinGW (and probably Cygwin) bash, this doesn't happen. The output appears in the same console (rxvt window). Of course, it isn't really running on Windows in this case, but at least developers using thiese environments shouldn't be affected by the lack of the output then (or will they?).

Michael

Michael Schumacher writes:
> When started from the MinGW (and probably Cygwin) bash, this doesn't > happen. The output appears in the same console (rxvt window).

Wow. Didn't know that. I seldom use MSYS and its rxvt. I assume rxvt's window isn't a console window, it's a normal "graphics" window that just happens to contain only text, handled by the rxvt application itself. (I.e. it's like xterm etc on X11. A Unix equivalent of console windows would be built-in text-only windows in the X server, or something.)

Rxvt itself presumably passes some pipes for stdout/stderr to applications it starts and then shows whatever comes through those pipes.

Few end-users have rxvt, though.

--tml

Few end-users have rxvt, though.

huh, that is wrong, many people in Asia really perfer it, coz its nice wide-width characters handling.

Regards, Cai Qian

On Sunday, September 19, 2004, 15:13:31, Cai Qian wrote:

Few end-users have rxvt, though.

huh, that is wrong, many people in Asia really perfer it, coz its nice wide-width characters handling.

Does that include Windows users?

Does that include Windows users?

No, only those Cygwin people.