Hi guys,
Since GLib 2.32, log messages at levels INFO or DEBUG aren't output unless G_MESSAGES_DEBUG environment variable is set to either "all" or to include the domain the message comes from [1].
The problem is that it breaks our `-v` option, since we simply turns on outputting INFO-level messages. So, we need a fix or a workaround, something. I see 2 solutions:
1) simply `g_setenv("G_MESSAGES_DEBUG", "all", TRUE)` when given `-v` (e.g. around main.c:131, `if (app->debug_mode) g_setenv(...`)
2) output everything ourselves in `handler_log()` (log.c:115) rather than calling GLib's default handler.
The simplest fix is of course 1. Not sure which one is the better though. Anyway, I think we need to do something about this soon.
Thoughts?
Cheers, Colomban
[1] http://developer.gnome.org/glib/unstable/glib-Message-Logging.html#g-log-def...
PS: BTW, if I read the `handler_log()` correctly, we block *all* messages when not in debug mode? I mean, warnings, criticals and everything. Do we really want that?
On 2 June 2012 20:58, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
Since GLib 2.32, log messages at levels INFO or DEBUG aren't output unless G_MESSAGES_DEBUG environment variable is set to either "all" or to include the domain the message comes from [1].
Environment variables should die, they are hidden dependencies that don't transport to user systems.
The problem is that it breaks our `-v` option, since we simply turns on outputting INFO-level messages. So, we need a fix or a workaround, something. I see 2 solutions:
- simply `g_setenv("G_MESSAGES_DEBUG", "all", TRUE)` when given `-v`
(e.g. around main.c:131, `if (app->debug_mode) g_setenv(...`)
Maybe do this for pending release ...
- output everything ourselves in `handler_log()` (log.c:115) rather
than calling GLib's default handler.
... and this later for "proper" fix that allows us to tailor it as we need, unless this is very simple too.
Cheers Lex
The simplest fix is of course 1. Not sure which one is the better though. Anyway, I think we need to do something about this soon.
Thoughts?
Cheers, Colomban
[1] http://developer.gnome.org/glib/unstable/glib-Message-Logging.html#g-log-def...
PS: BTW, if I read the `handler_log()` correctly, we block *all* messages when not in debug mode? I mean, warnings, criticals and everything. Do we really want that?
Probably still want criticals IMHO.
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 02/06/2012 13:16, Lex Trotman a écrit :
On 2 June 2012 20:58, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
Since GLib 2.32, log messages at levels INFO or DEBUG aren't output unless G_MESSAGES_DEBUG environment variable is set to either "all" or to include the domain the message comes from [1].
Environment variables should die, they are hidden dependencies that don't transport to user systems.
? These environment variables are documented so why is it worst than a configuration file somewhere?
The problem is that it breaks our `-v` option, since we simply turns on outputting INFO-level messages. So, we need a fix or a workaround, something. I see 2 solutions:
- simply `g_setenv("G_MESSAGES_DEBUG", "all", TRUE)` when given `-v`
(e.g. around main.c:131, `if (app->debug_mode) g_setenv(...`)
Maybe do this for pending release ...
I did this.
- output everything ourselves in `handler_log()` (log.c:115) rather
than calling GLib's default handler.
... and this later for "proper" fix that allows us to tailor it as we need, unless this is very simple too.
Well. It's easy to output something. It's harder to output something as useful as what the GLib handler can output, like including prgname, pid & co, an doing so to the proper stream. Not really hard, but not trivial either.
[...]
PS: BTW, if I read the `handler_log()` correctly, we block *all* messages when not in debug mode? I mean, warnings, criticals and everything. Do we really want that?
Probably still want criticals IMHO.
Fixed, now we only hide info, debug and message log entries.
Cheers, Colomban
[...]
? These environment variables are documented so why is it worst than a configuration file somewhere?
Couple (or 3) reasons:
1. with most desktops it seems running geany from the menu or icon won't set environment variables because no shell runs to read .bashrc or whatever setup file
2. as far as I can find its only documented in the Glib documentation, not somewhere even an experienced *user* is likely to look
3. As a general comment, how often have you taken ages to find that you had to set path to make something work because no installer can set it for you?
All should be command line options IM(not so)HO so they are explicit and in user documentation. The config file is just a way of saving you having to type too much , just like gcc @file, file can be distributed to set things.
Cheers Lex
The problem is that it breaks our `-v` option, since we simply turns on outputting INFO-level messages. So, we need a fix or a workaround, something. I see 2 solutions:
- simply `g_setenv("G_MESSAGES_DEBUG", "all", TRUE)` when given `-v`
(e.g. around main.c:131, `if (app->debug_mode) g_setenv(...`)
Maybe do this for pending release ...
I did this.
Okey dokey.
- output everything ourselves in `handler_log()` (log.c:115) rather
than calling GLib's default handler.
... and this later for "proper" fix that allows us to tailor it as we need, unless this is very simple too.
Well. It's easy to output something. It's harder to output something as useful as what the GLib handler can output, like including prgname, pid & co, an doing so to the proper stream. Not really hard, but not trivial either.
Well, if we have to re-invent the wheel then don't bother.
[...]