After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 56331 - Dialogs should be updated to reflect current GUP proposal
Dialogs should be updated to reflect current GUP proposal
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2001-06-18 03:01 UTC by Gregory Merchan
Modified: 2011-02-04 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to support GUP dialog proposal (C source) (3.36 KB, patch)
2001-06-20 23:27 UTC, Gregory Merchan
none Details | Review
Patch to support GUP dialog proposal (C header) (658 bytes, patch)
2001-06-20 23:28 UTC, Gregory Merchan
none Details | Review
Patch to support GUP dialog proposal (C source) (3.84 KB, patch)
2001-06-22 10:28 UTC, Gregory Merchan
none Details | Review
Patch to support GUP dialog proposal (C header) (801 bytes, patch)
2001-06-22 10:29 UTC, Gregory Merchan
none Details | Review
New patches for Box, ButtonBox and Dialog (tar'd, gzip'd) (1.41 KB, application/x-gtar)
2001-07-03 06:37 UTC, Gregory Merchan
  Details
New diffs redux. (Missing child property still.) (2.75 KB, application/x-gtar)
2001-07-05 01:47 UTC, Gregory Merchan
  Details
This should be the end of it; fixes the order of the buttons. (8.62 KB, patch)
2001-08-25 18:35 UTC, Gregory Merchan
none Details | Review
Ooops, missed the gtkgamma dialog. (9.83 KB, patch)
2001-08-25 18:40 UTC, Gregory Merchan
none Details | Review

Description Gregory Merchan 2001-06-18 03:01:51 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.
Comment 1 James Cape 2001-06-18 03:32:26 UTC
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

Comment 2 Owen Taylor 2001-06-18 19:26:07 UTC
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?)



Comment 3 James Cape 2001-06-19 06:56:45 UTC
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.
Comment 4 Gregory Merchan 2001-06-20 23:27:15 UTC
Created attachment 664 [details] [review]
Patch to support GUP dialog proposal (C source)
Comment 5 Gregory Merchan 2001-06-20 23:28:09 UTC
Created attachment 665 [details] [review]
Patch to support GUP dialog proposal (C header)
Comment 6 Owen Taylor 2001-06-21 16:10:21 UTC
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.
Comment 7 Gregory Merchan 2001-06-22 10:28:42 UTC
Created attachment 669 [details] [review]
Patch to support GUP dialog proposal (C source)
Comment 8 Gregory Merchan 2001-06-22 10:29:21 UTC
Created attachment 670 [details] [review]
Patch to support GUP dialog proposal (C header)
Comment 9 Gregory Merchan 2001-06-22 10:50:59 UTC
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.
Comment 10 Calum Benson 2001-06-28 11:13:22 UTC
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  :)
Comment 11 Owen Taylor 2001-06-28 12:58:56 UTC
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.
Comment 12 Gregory Merchan 2001-07-03 06:37:32 UTC
Created attachment 711 [details]
New patches for Box, ButtonBox and Dialog (tar'd, gzip'd)
Comment 13 Owen Taylor 2001-07-04 13:57:35 UTC
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)
Comment 14 Gregory Merchan 2001-07-05 01:47:47 UTC
Created attachment 716 [details]
New diffs redux. (Missing child property still.)
Comment 15 Owen Taylor 2001-07-06 01:59:20 UTC
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.

Comment 16 Gregory Merchan 2001-08-25 18:35:07 UTC
Created attachment 966 [details] [review]
This should be the end of it; fixes the order of the buttons.
Comment 17 Gregory Merchan 2001-08-25 18:40:27 UTC
Created attachment 967 [details] [review]
Ooops, missed the gtkgamma dialog.
Comment 18 Gregory Merchan 2001-08-25 18:43:42 UTC
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.)
Comment 19 Owen Taylor 2001-11-02 20:06:42 UTC
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.
Comment 20 Bugzilla Maintainers 2004-04-01 23:44:57 UTC
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