Hi, Alif Wahid <alif.wahid@xxxxxxxxx> writes: > > > I noticed that GIMP uses message output and debugging functions > > > provided by GLIB. So isn't it possible to fix this by just setting a > > > custom print handler using g_set_print_handler and so on? That would > > > make it portable as well. Just a suggestion anyway. Cheers. > > > > No, it is not possible to fix it this way. Messages sent via GLib are > > of course not sent to stdout/stderr. At least not by default. > > But the GLIB docs for g_set_print_handler say that "Any messages > passed to g_print() will be output via the new handler. The default > handler simply outputs the message to stdout. By providing your own > handler you can redirect the output, to a GTK+ widget or a log file > for example". It says the same for g_log functions as well. 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(). 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. 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). Otherwise they are shown in the Error Console dockable. If that dockable doesn't exist, an error dialog pops up. If for whatever this isn't being successful (I can't think of reason), the message ends up on the console. So since stdout/stderr are not for the user's eyes, why are the poor GIMP users on the Win32 platform faced with it? Sven
