Re: Re: console window

I don't think the environment variable would be an ideal solution. If we
were talking about unix and variants, then yes, maybe. But this is Windows.
In a totally unscientific study, 95% of windows users don't know how to set
or modify environment variables. (Ok, so that's unreliable, but you see my
point.) However, I think the environment variable would be an ok idea if it
was something like G_WIN32_ALWAYS_ALLOC_CONSOLE, and if it wasn't set, it
should default to not creating a console. This way, users could still be
able to access these messages (Assuming a good FAQ on how to change the
environment variable), but clueless users would be none the wiser.

Another idea would be a simple set of  functions. Maybe
g_log_set_all_handlers(GLogFunc), which would set log handlers for NULL,
"Gtk", "Gdk", "Glib", etc, using GLogLevelFlags G_LOG_LEVEL_MASK |
G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION. That seems easy enough to
implement. The other function would be something like
g_log_set_all_handlers_to_null(). This would set log handlers similar to
g_log_set_all_handlers(GLogFunc) except the GLogFunc would be an internal
callback that did nothing but return.

Or, instead of those two, void g_log_disable_printf() (and conversely
g_log_enable_printf()) could set a global gboolean, and when the default log
handler was called, if this gboolean was true, no printf statement would
occur. This would still allow individual applications to attach handlers and
process error messages if they wanted to, without the overhead of the idea
above. IMHO this seems the most efficient.

--Lee


To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/