"The time has come," the Walrus said, "To talk of many things: Of shoes--and ships--and sealing-wax-- Of cabbages--and kings-- And why the sea is boiling hot-- And whether pigs have wings."
so... we do have many things to deal with.
g_log... g_warning... fprintf(stderr... magic dialog output...
What's the plan for a grand unification of this all?
First, there are a few classes getting setup that would appear to deal with this. When should each be used, and where.
Second, what should the messages be? What are the rules for the types, contents, internationalization, etc.
Not sure if this best starts here on the list, or on the Wiki. I've setup a stub page to get filled in eventually. http://www.inkscape.org/cgi-bin/wiki.pl?ErrorsAndWarnings
On Wed, Apr 13, 2005 at 08:36:41PM -0700, Jon A. Cruz wrote:
g_log... g_warning... fprintf(stderr... magic dialog output...
What's the plan for a grand unification of this all?
First, there are a few classes getting setup that would appear to deal with this. When should each be used, and where.
Second, what should the messages be? What are the rules for the types, contents, internationalization, etc.
Not sure if this best starts here on the list, or on the Wiki. I've setup a stub page to get filled in eventually. http://www.inkscape.org/cgi-bin/wiki.pl?ErrorsAndWarnings
I've also thought about getting these a bit better organized, but maybe this could wait until later?
Bryce
Bryce Harrington wrote:
I've also thought about getting these a bit better organized, but maybe
this could wait until later?
Well... it's not too much actual coding work, and quite easy to search for and replace.
However... it's exactly the kind of thing that caused problems more than once. :-(
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.
Peter Moulder suggerì:
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.
GError could be useful to propagate cleanly errors. They require only a little effort to setup.
On Thu, Apr 14, 2005 at 10:10:13PM +1000, Peter Moulder wrote:
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 a long term solution, I'd suggest to place functions like this via the Inkscape::Application class, since that is the spot that has the knowledge of whether we're running GUI or not.
Specifically, define pure virtual routine(s) in src/application/app-prototype.h, and then instantiate them in editor.* for GUI use. For commandline usage, we'll eventually have a commandline.* or something, where a non-GUI handler can be instantiated. We may have additional classes for other run modes such as inkview and perhaps an animation player.
Then add a message routine to Inkscape::Application in src/application/application.* that simply calls the above method from _app_impl. Then this allows any part of the codebase to print error messages knowing only the inkscape app object.
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.
Could you add the above to the Programming Manual area in wiki? This is some good info to keep track of.
Bryce
participants (4)
-
Bryce Harrington -
Emanuele Aina -
Jon A. Cruz -
Peter Moulder