Re: [Evolution-hackers] Alert Dialog API



umm, we already have e_notice, which covers 90% of uses of such
dialogues, and the api is nicer.  the other thing we have in the mailer
is one that can lookup a boolean gconf key to do 'do not show me this
again' stuff, and handle all the details, it could just as easily, using
the same api, ask a question without that prompt.  those 2 functions
could cover 95% of the questions required.

On Tue, 2004-02-03 at 13:55 -0500, Rodney Dawes wrote:
> So, my current thoughts on writing the API for the HIG-compliant alert
> dialogs, is that there will be a generic API call for creating custom,
> and/or extended alert dialogs, and some simplistic API calls for popping
> up simple dialogs to alert the user of an error, warning, or a simple
> informational piece of text. The API would look something like this:
> 
> GtkWidget  * e_alert_dialog_new (const gchar * summary,
> 				 const gchar * message,
> 				 GtkMessageDialogType alert_type,
> 				 GtkWindow * parent);
> void e_alert_dialog_set_icon (EAlertDialog * dialog,
> 			      const gchar * name);
> void e_alert_dialog_set_icon_from_pixbuf (EAlertDialog * dialog,
> 					  GdkPixbuf * pixbuf);
> void e_alert_dialog_set_icon_from_... (...);
> 
> This would be the generic interface for creating a custom or extended
> alert dialog. The _new () call creates a new dialog with the appropriate
> summary, message, icons, and window title, based on the given
> alert_type, and sets the appropriate flags for blocking the given parent
> when it is shown. The current GtkDialog APIs can be used to add buttons
> to the dialog, and run it. And, the response signal will get emitted,
> when the user clicks one of the buttons.
> 
> void e_alert_dialog_popup_simple (const gchar * summary,
> 				  const gchar * message,
> 				  GtkMessageDialogType alert_type,
> 				  GtkWindow * parent);
> 
> This would be the simple interface for popping up quick alert dialogs
> that don't need extra programmatic interaction. It is useful for simple
> warnings and errors, so that no extra code needs to be written to handle
> running and closing the dialog, for instance, when there is only an "OK"
> button, in the case of most common errors.

be better to take the returned widget and have a 'run' method.

> GtkWidget * e_alert_dialog_new_confirmation (const gchar * summary,
> 					     const gchar * message,
> 					     GtkWindow * parent);
> 
> This is to handle simple confirmation dialogs, such as confirming the
> "Empty Trash" request, or such. It returns a GtkWidget, so that the
> programmatic interface can be set up to do the right thing if the
> user confirms the action.
> 
> GtkWidget * e_alert_dialog_new_save_confirmation (const gchar * summary,
> 						  const gchar * message,
> 						  GtkWindow * parent);
> 
> This is to handle save confirmation dialogs. It also returns a GtkWidget
> for use in the programmatic interface needed to do the correct thing
> when the user chooses to save, not save, or cancel.

Why not just return the return code of the answer.

The message strings should be varargs printf stuff, rather than having
to make strings up outside of it.

> So, that is all I have now. A simple API for having HIG-compliant alerts
> that can be extended and customized if need be. Any thoughts, or other
> requests or constructive complaints?

really gtkmessagedialog should be made hig compiliant, or the hig
altered to fit reality ...





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]