LEGO wrote:
While trying to do this I changed the default configuration filename
to "". and make sure mate would not try to compile if the config
filename is an empty string.
That's the correct thing to do.
Here is the issue: if mate's preference was changed it failed to start
ethereal just aborted in an assertion in
proto_register_subtree_array() because when the preferences chage mate
tryes to register its subtree array after the tree_is_expanded array
is already allocated.
I've checked in (a modified version of) your change to grow the array.
A failure to open a file in a plugin should be reported with the
report_open_failure() routine declared in epan/epan.h - that'll put up
an alert box in Ethereal and print a message in Tethereal. There are
also report_read_failure() routines to report I/O errors when reading a
file (code should check for read errors as well), and for errors in, for
example, the contents of the file, report_failure() should be used.
Good to know, I'll change mate's setup to use report_failure() insted
of g_warning().
Use report_open_failure() to report failures to open files - it does the
work of making the message correspond to the reason for the open failure
(permissions error, etc.) - and use report_read_failure() to report read
errors, for the same reason.
What about runtime "errors" is a g_message fine in those cases or
should mate just be quiet?
"Errors" in what sense? If the error is something the user needs to
correct, use report_failure(). If it's not something the user needs to
correct, does it need to be reported at all?
Mate has a debug facility is it ok for it to use g_message whenever it
is not sending the debug output to a file?
For debugging messages, g_message() should be fine.
