Re: Couple of items
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Couple of items
- Date: Thu, 28 Mar 2002 21:28:03 +0100 (CET)
On Wed, 27 Mar 2002, Owen Taylor wrote:
> > g_message() goes to stderr, exactly because it should be used instead
> > of g_printerr(), so that programs can catch messages of a certain
> > library and the user knows what module produced the output.
>
> OK, the old code was a little unclear on the issue, and I've been
> confused on this for a while.
i don't find the old code particularly hard to read:
fd = (log_level > G_LOG_LEVEL_MESSAGE) ? 1 : 2;
> In a some cases, the debug
> spew includes text from widgets (UTF-8), strings marked for
> translation (UTF-8), err->message strings from (UTF-8) or filenames
> (UTF-8 unless you set G_BROKEN_FILENAMES).
btw, G_BROKEN_FILENAMES=1 doesn't have any real effect on my machine,
the file selection still complains about filenames in latin1 (that's
with LANG=C). i tend to think g_filename_to_utf8() should be somewhat
more clever about its fallback.
> So, approximate tallies, would be:
> No Convert Convert
>
> Work properly | 1900 | 2550
> --------------------------------------+-----------------+--------------------
> Sort of broken, but doesn't matter | 500 | 30
> --------------------------------------------------------+--------------------
> Broken | 70 | 1
>
>
> (Where I'm pretty sure about the last line.)
ok, that looks promising, thanks for collecting some sample data here.
> > that had to be changed. though i don't think there's a point in reverting
> > that part, other than to use this as a threat in order to push conversion
> > for g_print() and g_printerr() without further discussion.
>
> Basically, I see the gmessages.c changes being in three parts:
>
> - Cleanups and fixes. Big, and not critical. (It's certainly better
> code now, but there were not problems that people were running into
> with the old code.)
unless they triggered recursive warnings or warnings in the threading layer.
that code is still potentially harmfull, though much less now. fixing it
requires making gmem.c and g_thread_self() g_log()-free and adding the log
depth to GThread.
>
> Regards,
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]