Any objection to my pushing the formatting of error/warning dialog message strings into the gnc_xxx_dialog() routines? These library functions would grow a bit, but most of the callers of these routines would simplify. This also has the benefit of consolidating all the logic about creating/freeing temporary strings and results into one location.
Here's a typical diff:
@@ -687,15 +685,9 @@
{
const char *format = _("The file \n %s\n already exists.\n"
"Are you sure you want to overwrite it?");
- char *tmpmsg;
- gboolean result;
-
- tmpmsg = g_strdup_printf (format, newfile);
- result = gnc_verify_dialog (tmpmsg, FALSE);
- g_free (tmpmsg);
/* if user says cancel, we should break out */
- if (!result)
+ if (!gnc_verify_dialog (FALSE, format, newfile))
{
g_free (newfile);
return;
There are two drawbacks. First, invariant messages will also be
duplicated by the library function before the dialog is created.
Second, the order of the arguments to these dialog creation routines
changes as the format string gets pushed to the end of the function call
as the last required argument to the function. (This last isn't a
requirement of the compiler, but its conceptually simpler to group the
format string and its variable number of arguments together.) All of
these routines would still perform compile time checking of the
arguments to the format string.
Comments?
David
signature.asc
Description: This is a digitally signed message part
