[Usability] Re: RFE - API change from GtkMessageDialog to GtkAlert

[Owen Taylor <otaylor redhat com>]

Thanks for the suggestion. Unfortunately, it's way too late
to do it for 2.0. (We've now cut off even tiny API changes.)

We could _add_ this for 2.2, however. Feel free to file a bug to that
effect. (Personally I think it would be confusing to programmers and
probably lead to inconsistency on the desktop.)

The change to make the icon extend all the way down the side would be
easy enough to do compatibly with a little hackish repacking of the
GtkDialog in the init function; anybody who actually _did_ put help
buttons in their GtkMessageDialog would perhaps get a non-optimal
result, but otherwise it would be fine.

(Of course, this arrangement does exacerbate the problem that
message dialogs tend to be too wide in aspect ratio.)

Where do nautilus-style "Details" buttons go?

Regards,

                                        Owen

Gregory Merchan <merchan baton phys lsu edu> writes:

> I realize that this is too late for the freeze.
> 
> I'd like to see a change from the GtkMessageDialog api to a GtkAlert api.
> There are three parts I see changing for this.
> 
> The name:
>  * GtkAlert is fewer letters and words so it requires less typing and the egtk
>     minor mode for emacs will work correctly without modification.
>  * The name is more suggestive of proper use. The essential difference between
>    a dialog and an alert is that the user never requests an alert; an alert
>    is an intrusion into the user's workflow.
> 
> The construction:
>  * Alerts may have a Cancel button, an equivalent of OK, and possibly an
>    alternative action button.
>    - Error notices and informative alerts would have just an OK button.
>    - Authenication alerts would have GtkEntry's to meet authentication
>       requirements and Cancel and OK buttons.
>    - Confirmation alerts would have Cancel (as such) and an OK-equivalent
>       button labeled to indicate what is okayed. When appropriate they would
>       also have an alternative action button.
>  * The arrangement of widgets would be slightly different from that of
>    GtkDialog. This is shown here indicating boxes (which would not be visible,
>    of course) and placement of all elements even though entries and an
>    alternative button would not appear together.
> 
>    +--------+------------------------------------------+
>    | <icon> | <alert text>                             |
>    |        |                                          |
>    |        |          <auth1> [____________]          | 
>    |        |          <auth2> [____________]          |
>    |        |                                          |
>    |        +------------------------------------------+
>    |        | <alternative button>     <cancel> <<ok>> |
>    +--------+------------------------------------------+
>  
>    The alternative button would be placed in the secondary area of the
>     GtkButtonBox; an alert would not have a Help button and the alternative
>     would be useful for alerts like the "Save before closing"-alert.
> 
>     |  A "Save before closing" alert would have:
>     |
>     |    <icon>               = the warning icon
>     |    <alternative button> = _Don't Save
>     |    <cancel>             = Cancel
>     |    <<ok>>               = Save
> 
>    Running the space of the icon to the bottom of the window makes the alert
>     more clear and more distinct from dialogs. Without this change, the
>     alternative button would appear in the same place as Help does in dialogs
>     unless it were kept in the primary area of the GtkButtonBox - doing that
>     would place a potentially destructive action too near the safe actions in
>     an alert like "Save before closing".
> 
> The third change would be to the api as necessary to afford this. I've not
>  yet drafted any code for it, but Seth Nickell claims to have done so.
> 
> Breakage:
>  * The GtkMessageDialog first appeared in gtk+ 1.3 so no part of the 1.2 api
>     will be broken by this change that isn't already broken.
>  * If the change does not appear before 2.0 it will lead to soon deprecating
>     the new GtkMessageDialog api and having two active and overlapping api's.
>     This could result in inconsistency of the user interface.