Re: Balsa's terminal logging

Le 2018-01-05 à 10:28, Albrecht Dreß a écrit :
Hi all,

I noticed that Balsa uses a variety of methods to print messages typically used for error reporting or for /very/ low-level debugging to the terminal (note: *not* via libbalsa_information):
* fprintf(stderr, …), sometimes depending on balsa_app.debug
* printf(…), sometimes depending on balsa_app.debug
* g_print(…), sometimes depending on balsa_app.debug (prints to stdout)
* g_printerr(…) (prints to stderr)
* g_debug (prints to stdout)
* g_error (prints to stderr)
* g_message (ditto)
* g_warning (ditto)

This is somewhat confusing, clutters up the xsession log files, and is not always helpful for real debugging, as it lacks timing and thread information (e.g. g_debug() output from parallel POP3 or SMTP operations in different threads).

My idea is to write our own g_log default handler, which includes all this extra information, and /exclusively/ use g_log(…) and the related convenience macros to emit any information.  The output could look like

2018-01-05T14:55:42.161399Z balsa:(main) WARNING[libbalsa]: some message from libbalsa 2018-01-05T14:55:42.161414Z balsa:4008e0 ERROR[default]: error message from thread 0x4008e0
iso8601 time stamp                thread level[domain]

I'm not sure if the domain is of any use (probably not), so we could just omit it.

Our log handler should evaluate the balsa_app.debug setting and the G_MESSAGES_DEBUG environment variable:
* levels ERROR, CRITICAL, WARNING, MESSAGE: always print to stderr
* level INFO: print to stdout only if balsa_app.debug is TRUE, and maybe G_MESSAGES_DEBUG is defined
* level DEBUG: print to stdout only if G_MESSAGES_DEBUG is defined

The calls to [f]printf, g_print and g_printerr need to be converted to the appropriate macros: * fprintf 🠆 g_info() for balsa_app.debug, g_warning() or g_error() otherwise
* printf and g_print 🠆 g_info() for balsa_app.debug, g_message() otherwise
* g_printerr 🠆 g_warning() or g_error()

What do you think about this idea?  As always, any comment is welcome!

Judging by my experience with other applications, that would certainly help debug problems, if it is not too difficult to implement. It could even help more advanced users resolve configuration problems by themselves.
From what you say, it seems it would give cleaner code as well.

Since log files have a tendancy to occupy a lot of space longer term, it would be a plus if older log entries were automatically removed. For example, I don't think log entries over a month old would still be useful.


balsa-list mailing list
balsa-list gnome org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]