GNOME Bugzilla – Bug 56331
Dialogs should be updated to reflect current GUP proposal
Last modified: 2011-02-04 16:09:32 UTC
Dialogs should be updated to reflect current GUP proposal. http://developer.gnome.org/projects/gup/proposals/dialog.html The major code changes from 1.2 are as follows: * Button alignment should reflect locale. * A "Help" button, if present, must be grouped separately from the other buttons in the dialog so that it's placement is constant relative to the dialog window.
Doing this is actually *really* easy, just stick the action area ButtonBox into a {H,V}Box, and stick the help button at the other end. Don't show the help button until it's connected to something. To see an example of much of what I'd like to see in dialogs, including this help arrangement, check out http://jimbob.myip.org/software/gnomechat/src/gui-utils.c
We'd have to add support for this in the GtkDialog API - having people repack widgets is not acceptable. My proposal for this would be: gtk_dialog_set_response_secondary (GtkDialog *dialog, gint response_id, gboolean is_secondary); Which moves response_id into a secondary button box packed into a HBox along with dialog->action_area. And have buttons added with GNOME_STOCK_HELP be automatically seconary unless set otherwise. A patch to implement this would be appreciated, and would increase the chance that it will get into GTK+-2.0. (Question raised - why are we doing this for dialogs when it was decided a while ago that it was a bad idea for menus?)
The reason to align a help button away from action buttons is because in a dialog there are typically only one path to take: You fill in or read the dialog, you hit Ok, or you fill it in, hate what you did, then hit Cancel (in either case, closing the dialog). The Help button is completely different from the "Ok" and "Cancel" buttons because it does/is not: 1. Get rid of the dialog (Ok and Cancel do both) (most important difference) 2. Do anything with the contents of the dialog (Ok typically applies them, Cancel typically does nothing, or visa-versa for instant-apply dialogs) 3. Necessary to understand the dialog (or, shouldn't be :-) -- Both Ok and Cancel are necessary, in that you have to know about them, and what they do to use the dialog effectively). Because of these differences, Help buttons should be separate. The primary reason is #1. The help button shouldn't do anything with the dialog, so it shouldn't be grouped next to 2 buttons which do. Because top-level menuitems (which don't have icons) are harder to notice than a button (and most application windows are far larger than most dialog windows), it's better to stick the help menu next to the other menus because it can be missed easily if it is not grouped with the other items. Basically, 1. It's a lot harder to miss a button with an icon in a dialog than it is to miss a top-level menuitem without one in an application window. 2. Help buttons are sufficiently different from the primary action buttons in a dialog to warrant their being separate. 3. Help *menus* are not sufficiently different in what they do compared to the other menus in an application to warrant their separation. 4. Dialogs have one basic path through them, so making sure each UI element is distinct is important, whereas application windows have as many paths as there are UI elements, so making sure no UI elements get left out of the user's mental picture of what can be done is more important than element distinction.
Created attachment 664 [details] [review] Patch to support GUP dialog proposal (C source)
Created attachment 665 [details] [review] Patch to support GUP dialog proposal (C header)
I would get rid of the repacking in this patch and always just create the secondary action area -- should simplify things a lot with the code, and the cost of two extra box widgets isn't worth worrying about. A doc comment is needed for the new API entry point.
Created attachment 669 [details] [review] Patch to support GUP dialog proposal (C source)
Created attachment 670 [details] [review] Patch to support GUP dialog proposal (C header)
In the new patches: * The secondary area is part of the object structure. * The HBox is not. * The doc comments are included as needing to be fixed. There is another factor which I'm not sure is handled yet. The default action in gtk 1.2 would change as the used tabbed through the action area; if this is still the case, it must be changed - I don't know how (yet?). The reason for may be found here: http://mail.gnome.org/archives/gnome-accessibility-list/2001-June/msg00001.html Also, these patches are untested; I am not set-up to do any work with cvs gtk. Final notes for now: I suspect that F1 (?) or Help (on some keyboards) needs to be bound to activate "Help". I don't know if this is widget level or application level. I think the Sun keyboard also has a Cancel key which should be considered equivalent to Escape for dialogs.
How does all this affect the Dialog Look-and-Feel capplet's ability to let you left/right-justify or spread out the buttons along the bottom of every dialog? Oh, and no, Sun keyboards don't have a Cancel key-- they do have a Stop key, but that's not really quite the same thing, it's supposed to "stop" whatever operation is going on under the mouse pointer at the time. I'm not sure if it's ever been used as a Cancel key in the context of dialog boxes, I'd need to check :)
At the current time, there is no settable option for where the buttons go - they are always right (or TFEL) alighned. I think we'd just ignore the primary/secondary distinction for anything other than right-aligned buttons if we made this a user-conifgurable setting. It's also possible we could move the help button over to the right, if the user selected left-alighned buttons but this seems like a too-drastic rearrangement, As far as user settings go, this seems like a very low priority one (and without regard to the location of [Help]) its one I think is good if it goes away - I can't see why one way of doing it would be preferred _by a patricular user_ over another.
Created attachment 711 [details] New patches for Box, ButtonBox and Dialog (tar'd, gzip'd)
Comments on latest patch: - Doc comments for all new API functions are mandatory - The desired behavior for the dependency on GtkButtonBoxStyle is that START => secondary goes after at the end END => seocondary goes before at the start SPREAD/EDGE => secondary goes after but is not otherwise different. With the definition of before/after dependening on direction of the widget. - Ordering should not affected by setting secondary and setting it back - this means that set_secondary() should not call reorder_child(). Changes in order from set_secondary() should all happen as an effect of the size_allocate() code. - A child property needs to be added to GtkButtonBox for "is_secondary" (don't worry too much about this ... easy to add after the fact) - Set secondary should have a g_return_if_fail (child->parent && child->parent == widget)
Created attachment 716 [details] New diffs redux. (Missing child property still.)
Thu Jul 5 21:53:46 2001 Owen Taylor <otaylor@redhat.com> * gtk/gtkbbox.[ch] gtk/gtkbox.[ch] gtk/gtk[hv]bbox.c: Patch from Gregory Merchan to add gtk_button_box_set_secondary(), which separates the child into a separate group from the normal buttons. * gtk/gtkdialog.c: Make help buttons secondary by default. * gtk/gtkbbox.c: Added a child property "secondary". * gtk/testgtk.c: Turn on the help button for the color selector to check that it properly appears as secondary.
Created attachment 966 [details] [review] This should be the end of it; fixes the order of the buttons.
Created attachment 967 [details] [review] Ooops, missed the gtkgamma dialog.
Sorry this is so late. I missed the toolkit provided dialogs before. The last patch fixes the order of the buttons for all of them found by `grep gtk_dialog gtk+/gtk`. (I missed the gtkgamma.c part in attachment 966 [details] [review]. The entire patch set is included in 967.)
Fri Nov 2 14:55:53 2001 Owen Taylor <otaylor@redhat.com> * gtk/{gtkcolorseldialog.c,gtkfilesel.c,gtkfontsel.c, gtkgamma.c,gtkmessagedialog.c}: Go to the GUP proposed ordering of buttons with [OK] in the lower right hand corner. Patch from Gregory Merchan, #56331.
The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions. URL: http://developer.gnome.org/projects/gup/proposals/dialog.html