Re: [PATCH] Alert dialogs should not have window title according to the HIG
- From: Dennis Cranston <dennis_cranston yahoo com>
- To: Luca Ferretti <elle uca libero it>, Jaap Haitsma <jaap haitsma org>
- Cc: "nautilus-list gnome org" <nautilus-list gnome org>
- Subject: Re: [PATCH] Alert dialogs should not have window title according to the HIG
- Date: Thu, 15 Dec 2005 20:57:38 -0800 (PST)
While using nautilus to copy a file to another directory, I was presented with the attached
dialog. "Conflict While Copying" should not be a button. I believe this bug was introduced when
the alert dialogs patch was applied to cvs. Also, the window list applet displayed a "untitled
window" button for the dialog.
--- Luca Ferretti <elle uca libero it> wrote:
> Il giorno gio, 08/12/2005 alle 22.49 +0100, Jaap Haitsma ha scritto:
> > Luca Ferretti wrote:
> > > Il giorno sab, 03/12/2005 alle 19.42 +0100, Jaap Haitsma ha scritto:
> > >
> > >>Patches attached at http://bugzilla.gnome.org/show_bug.cgi?id=323134
> > >
> > >
> > > I was writing a light replacement for ell alert functions, based on
> > > GtkMessageDialog and following HIG rules.
> >
> > Good idea
> >
> > > It's not yet finished, and I don't know if it's better to ask for
> > > inclusion in GTK+ or keep it as cut-and-paste code. Do you think it
> > > could be useful for Nautilus alerts, so we can test the code before
> > > suggest it for gtk?
> > >
> >
> > Questions/Remarks
> >
> > * Why not make GtkMessageDialog HIG compatible, by fixing some stuff and
> > maybe adding some extra functions?
>
> IMHO the current GtkMessageDialog API is good. The only missing stuff in
> default values should are the window title and the skip taskbar/pager.
> Oh, and maybe the transient property.
>
> We can simply add to GtkMessageDialog API 4~5 functions to directly
> create HIG compliant messages, so if you (developer) have to create an
> error alert, you can simply call the gtk_message_dialog_error ()
> function, while if you need more control (not usual, but...) you can
> still use the 'core' functions.
>
> Of course I wrote those function in a separate source file and header to
> simplify edit and tests, but I think should be really trivial move
> function from gtkstockmessagedialogs.[ch] to gtkmessagedialog.[ch].
>
> > * I'd like to have line wrap enabled. Otherwise you might get very wide
> > dialogs.
>
> ??? Line wrapping is yet enable in GtkMessageDialog.
>
> > * In your code it does not seem to be possible to get an icon on a button
>
> Yeah, in TODO list.
>
> But I've a doubt: is better provide a single function like
>
> gtk_message_dialog_warning_new (parent_win, primary_message,
> secondary_message, affirmative_button_plus_icon,
> alternate_button_plus_icon, ...);
>
> or maybe split it in 2 function like
>
> gtk_message_dialog_warning_new (parent_win, primary_message,
> secondary_message, affirmative_button_plus_icon);
>
> gtk_message_dialog_add_alternate_button (dialog,
> alternate_button_plus_icon);
>
> The *add_alternate_button function could be useful to error messages too
> (HIG says: "may present a convenience button to allow immediate handling
> of the error. For example, a Format... button in a "This disk is not
> formatted" alert. Place this button to the left of the affirmative
> button.")
>
> Moreover HIG allow you to put more then one alternate button in alert
> (HIG says: "Extra buttons may be used to provide alternates to the
> primary action proposed by the alert text. Place these buttons to the
> left of the Cancel button, or the affirmative button if Cancel is not
> present.")
>
> The slitted API seems more reasonable to me.
>
> Cheers.
>
> --
> nautilus-list mailing list
> nautilus-list gnome org
> http://mail.gnome.org/mailman/listinfo/nautilus-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]