First an update on deprecations: GLib and GTK+ master have been fully converted to use function attributes for deprecations now, and most uses of G_DISABLE_DEPRECATED guards in GLib headers have been removed. They are still used for deprecated things that are not symbols, like macros and enum values. I haven’t done the same for GTK_DISABLE_DEPRECATED yet, but it should happen fairly soon. Looking forward to a future of less deprecation-induced build breakage (unless you insist on -Werror, of course…).

Continuing the theme of ‘making things suck less for developers’… another favourite is logging.  It is very hard to get right; you want to add plenty of debug and diagnostic messages to help with, well, debugging. But then people complain if you fill up their syslog or .xsession-errors with tons of debug spew, like here. The GLib logging system with g_log() and the macro wrappers g_debug(), g_warning(), etc leaves much to be desired. It does have the concept of replaceable log handler functions, which is ok for complicated uses. But unfortunately, the default handler is so inflexible that many applications are forced to install a custom handler just to be able to turn debug output on and off.

As a small step towards making better logging, the default log handler in GLib master now only emits errors, warnings and criticals. Informational and debug messages are only emitted if you set the G_MESSAGES_DEBUG environment variable. The value can be a list of log domains that you are interested in, or the special value ‘all’ to get it all. As a reminder, the log domain is almost invisible in your code unless you use g_log() directly; it’s what you define by adding -DG_LOG_DOMAIN=”MyCoolApp” to your CPPFLAGS.