I'm not fond of adding a second logging api to glib, when we already have g_log
and friends. Maybe we should discuss what features are missing from g_log that
make it unusable for your case. I can think of a few:

- categories
- a convenient way to filter by severity/category *at runtime*, 
  via a config file or an environment variable
- a convenient way to set up alternative destinations eg a socket
- "extensible printf" functionality for printing custom types

Is this what you are missing ?

Clearly not going to happen

Just for posterity: the following might give you an idea:

 $ GST_DEBUG=*:3 gst-launch-0.10 v4l2src num-buffers=5 ! ffmpegcolorspace ! xvimagesink

 $ GST_DEBUG=*:2 gst-launch-0.10 v4l2src num-buffers=5 ! ffmpegcolorspace ! xvimagesink

 $ GST_DEBUG=*sink:5 gst-launch-0.10 v4l2src num-buffers=5 ! ffmpegcolorspace ! xvimagesink

(and then *:5 or *:9 for the complete output. Add 2>&1 | less -R to see things in a pager.)

Timing info, process + thread IDs, source filename + line number + function name are extremely useful.

The optional 'object' argument to each debug message is also very useful, printed as '<xvimagesink0>' after the function name for example, though admittedly this is nicer when object actually have names, which GstObjects do, but GObjects do not (yet?).

I know lots of people who would love to see this in GLib and who would use it in their apps and libraries, and I believe there are also folks who'd do the work to integrate it into GLib and fix it up where needed.

Last time the topic came up on the mailing list (a while back) everyone seemed in favour, with only you (IIRC) undecided/unconvinced.

I think these two systems could simply serve slightly different purposes, just like GVariant has its own type system.

Not to say that it's the pinnacle of logging systems, but I think it is much-liked amongst those who've actually used it, and has proven extremely useful when debugging GStreamer applications.