Re: Couple of items

[Tim Janik <timj gtk org>]

On Wed, 27 Mar 2002, Owen Taylor wrote:

>  * Messages at a severity less than g_warning() [info,message,debug]
>    go to stdout rather than stderr which makes them entirely useless,
>    especially for libraries. (Libraries never should interfere with
>    stdout.)

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.

>  * g_warning() is very noisy, especially if you are trying to construct
>     multiline messages with multiple statements. (Especially annoying,
>    IMO is that g_warning() puts \n\n after each message)

error/critical/warning put an extra '\n' *before* the message, because
they are meant to alert the user and need to be visible regardless of
previous printed junk which might not have been '\n' terminated.

they aren't meant to be used for configuration errors though, that's what
g_message() is for which isn't as noisy.

> > > As for your points about escape codes and binary data:
> > > 
> > >  * I don't really understand what you mean by escape codes. Printing out 
> > >    characters not in your locale is not generally going to work.
> > 
> > you can use escape codes to switch character sets, e.g. to get IBM style
> > |
> > +- corners, --- lines, double lines, etc...
> > |
> 
> This is something that you'd only ever want to do if you were sure that
> your output was going to a terminal. I'd argue that if you want that, you
> shouldn't be using g_print(), g_printerr(), but probably open ("/dev/tty", ...)

regardless of your argument (which i'd share for theoretical purposes), in
practice that's what people do with printf() and people who use GLib do this
kind of stuff (as well as putting out binary data which is arguably questionable
also) with g_print().

> > > We've basically made conflicting statements on this subject:
> > > 
> > >  - [ An explicit one ] g_print*() is supposed to take UTF-8 strings.
> > > 
> > >  - [ An implicit one ] g_print*() used to pass things through literally.
> > 
> > yep, the statement here is actually that g_print() and g_printerr() are
> > the GLib versions of fprintf(stdout,) and fprintf(stderr,). making them
> > do conversions is basically bad API breakage (since we have these functions
> > for a long time now).
> 
> But, since g_print() and g_printerr() have redirection facilities they
> aren't equivalent to fprintf(stdout,) fprintf(stderr,). 

there's not much of a redirection facility for g_print() to speak of, merely
a function pointer to catch everything running through g_print(). if you
want to facilitate redirection, use g_log() which comes with the necessary
fundament to match modues and log levels from which messages are generated.

> If we don't make these functions convert, then there will be *no* way
> to print a redirectable string without introducing a lossy conversion 
> to the locale and back, and *no* convenient way of printing to stderr
> at all that fit's with our model of internationalization.

that's why i suggested introducing variants that convert to utf8.

> > > We are going to have a chance of hurting some people over either way.
> > > I'd really prefer to take the route that leaves us with useful 
> > > g_print() and g_printerr() functions rather than useless g_print()
> > > and g_printerr() functison.
> > > 
> > > Maybe we should hold off on this patch until after 2.0.1, so we can get some
> > > confirmation that people aren't using g_print() for binary data, but that
> > > worries me too. Every day we have a GTK+ out there with buggy g_log() functions
> > > is a day where someone may write:
> > > 
> > >  str = g_utf8_to_locale (message);
> > >  g_warning ("%s", str);
> > > 
> > > [ Or, mostly likely, get it wrong and write g_warning (str); ]
> > 
> > i'm not sure you got my note correctly. the functions in question are only
> > g_print() and g_printerr(). everything that goes through g_logv() (i.e. warnings,
> > errors, etc...) is converted to the current locale. note that the conversion
> > occours in the g_log default handler though, which means, if you install
> > a user handler for a specific log domain to catch log messages, you're still
> > passed the original unconverted UTF-8 string.
> 
> No, I understood what the situation is. What I'm saying is, is:
> 
>  - I'd like to make everything (g_log() and g_print*()) convert.

i agree that g_log() should convert to locale and that there should be stdout
and stderr print variants that do. however, i think we shouldn't break completely
valid uses of the current g_print() and g_printerr() which are based on the
contract of printf() mimicking.

>  - If we are worried about g_print() and binary streams, maybe we should
>    put the entire patch in after we release 2.0.1 so people have some
>    time to fool around with it before we release.

don't throw out the baby with the bath-water. there're lots of important
fixes and cleanups in CVS now, the conversion in question are just a few lines
in g_log_default_handler():

      if (g_get_charset (&charset))
        g_string_append (gstring, message);     /* charset is UTF-8 already */
      else
        {
          if (!g_utf8_validate (message, -1, NULL))
            {
              g_string_append (gstring, "[Invalid UTF-8] ");
              g_string_append (gstring, message);
            }
          else
            {
              string = g_convert_with_fallback (message, -1, charset, "UTF-8",
                                                ".", NULL, NULL, NULL);
              g_string_append (gstring, string);
              g_free (string);
            }
        }

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.

> I don't want to make 2.0.1 convert encodings on some stuff, and 2.0.2 
> convert encodings for more stuff.
> 
> Regards,
>                                         Owen
> 
> 

---
ciaoTJ