On Wed, Apr 13, 2005 at 08:36:41PM -0700, Jon A. Cruz wrote:
g_log... g_warning... fprintf(stderr... magic dialog output...
For messages that aren't bugs and that the user needs to see (e.g. file not found, failed to parse, etc.), I suggest that we have a function that checks for gui-ness and either presents an alert dialog box or writes to stderr as appropriate. The code at the end of inkscape.cpp:inkscape_segv_handler looks appropriate.
For bugs, use g_log or one of its wrapper macros like g_warning, g_critical, g_error, g_return_if_fail etc.
I don't know what convention we should use for choosing between the different levels. One fact to guide us is that g_error (i.e. calling g_log with G_LOG_LEVEL_ERROR) will by default abort() the program, whereas g_critical and g_warning will not by default. glib documentation for g_critical says:
It's more or less application-defined what constitutes a critical vs. a regular warning. You could call g_log_set_always_fatal() to make critical warnings exit the program, then use g_critical() for fatal errors, for example.
but doesn't say what should differentiate g_error from g_critical if one were to do that.
So far we've covered what to do with messages indicating bugs in inkscape and what to do with messages that are important enough to present an alert dialog for in the gui case. I'm not sure about less important messages. Maybe use g_log but use a lower level than g_warning. (The order is g_warning > g_message > g_info > g_debug.)
We currently have a log file for extensions-related errors, though I believe it's currently used only for dependency-related messages.
There is value in trying to separate bug messages from other messages, so that users are more likely to report the bug messages to us. We'd like to be told about such bugs, for a number of reasons:
- so that we can improve users' experience of inkscape;
- to improve our knowledge as developers: both as to what circumstances can occur that we thought couldn't occur, and also to tune the amount of effort we spend on checking
- learning of bugs earlier can reduce future pain
Having clear rules about g_log severities would help, especially if our g_log handler highlighted such severities.
Having the rule that g_log be used only for bug messages would make it easier still.
On translation: Whether or not the above rule is adopted, messages indicating bugs should not be wrapped in _(): the message is intended to be sent to developers, and it's most helpful if the string that gets reported by users can be searched for with grep in the source code, and if the developer can understand the string.
On charsets: both g_log_default_handler (at least in glib 2.4.7 and 2.6.3, I haven't checked other versions) and the handler of src/dialogs/debugdialog.cpp assume that the message is in utf8. (Reference: Messages::message in src/dialogs/debugdialog.cpp, and g_log_default_handler in gmessages.c). Luckily this is the most convenient charset for most callers in inkscape given that we use utf8 for most of our strings.
Whereas anything written to stdout/stderr with printf/fprintf should use locale encoding, e.g. using g_utf8_to_locale. (For the moment I make no comment on whether/when it is appropriate to write to stdout/stderr directly, just what charset to use if one does.)
One reason to avoid writing to stdout (whether via printf or via g_log with low level number) is that it can interfere with command-line use of inkscape, e.g. converting a file and sending the result to stdout. This reason doesn't apply to use of stderr though.
pjrm.