I just pushed a branch to master that changes how errors are reported. This is part of a bigger effort to isolate the front end from the backend, but it's just a small first step. In general, errors have been presented directly to the user (as dialogs) as soon as they happened. This is demonstrated by the fact that e_error_new() returned a GtkDialog*. This is problematic for a few reasons. The first being that it's not always desirable to show an error as a dialog (for instance, we might want to display them in the future in a GtkInfoBar widget or something similar). In addition, it makes it very difficult to separate the backend functionality from the UI, or to let the calling function make a policy decision about whether the error should be displayed or handled in some other way.
So, as a first step to fix this, I've created a new 'object' (really just a plain struct right now, but in the future it could be a proper GObject if we thought it was useful) called EAlert. I chose EAlert rather than EError based on Matthew Barnes advice since evolution often uses this infrastructure to present general informative messages, not only errors. I have kept the convenience API in place to create / display a dialog directly, but the function names will be a bit different. For instance, where you previously used e_error_new(), you can now achieve the same thing with e_alert_new_dialog_for_args() (the _for_args() is to distinguish it from e_alert_new_dialog() which accepts a EAlert* object -- if you can think of a better name for this function, feel free to suggest one). Where you previously used e_error_run(), you can now do the same thing with e_alert_run_dialog_for_args() (same note about function naming as above). However, my goal is to phase out use of these dialog-related helper functions. The plan is that in the future, instead of reporting errors directly, functions that can fail will take a EAlert** parameter and return a newly allocated EAlert object describing the situation (i.e. the same idiom as GError). The calling function can then determine how to handle or present that to the user. I started changing the files in filter/ to use the design I mentioned in the previous paragraph, so for example, the function: e_filter_element_validate(EFilterElement *element, GtkWindow *parent) became: e_filter_element_validate(EFilterElement *element, EAlert **alert) Other parts of the tree have only been changed to use the equivalent helper functions mentioned above. -- Jonathon Jongsma <jonathon.jong...@collabora.co.uk> _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers