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 84188 - "Dialogue" button widths should not be homogenous
"Dialogue" button widths should not be homogenous
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.0.x
Other Linux
: Normal normal
: Small API
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-06-05 04:13 UTC by Seth Nickell
Modified: 2010-08-22 23:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
preliminary patch (17.96 KB, patch)
2010-08-16 20:58 UTC, Matthias Clasen
none Details | Review

Description Seth Nickell 2002-06-05 04:13:27 UTC
The HIG reccomends using active phrasing in alert buttons, such as "Save",
"Quit without Saving" and "Repair Disk", as long as the phrases are fewer
than 3 words. However, the occasional button such as "Quit without Saving"
looks very strange because GTK uses homogenous sizes for alert buttons.

After some discussion a few of us usability crack-smokers have agreed that
homongenous button sizes do not provide a significant usability advantage,
and look sufficiently bad that they are problematic (also they make the
penalty for long buttons much larger since all buttons expand to that size).

It would be preferable to have button widths be non-homogenous but to
provide a reasonable "minimuum-size" so common stock buttons such as "OK"
and "Yes" do not become *too* small.
Comment 1 Calum Benson 2002-10-24 19:46:13 UTC
(Just adding comments in response to Owen's recent "what should we 
fix for 2.2" email)

I agree that there are situations where you want (probably at most) 
one button in a dialog to be longer than the others to accomodate a 
long label, but I don't know if we've thought about it enough to 
know what to suggest as a solution... well, maybe Seth has but he 
hasn't told me :)  

It would certainly be nice not to have to rely on the developer to 
set all the buttons to the right width manually... some sort of 
heuristic that allowed gtk to spot an 'outlier' and make the outlier 
as big as necessary, but just keep the others as big as the biggest 
other button, perhaps...?  Or maybe that's trying to be too clever.
Comment 2 Owen Taylor 2002-12-10 02:32:45 UTC
I think non-homogeneous + minimum width make sense, but this
requires two things. 

 1) API additions to GtkButtonBox to allow non-homogeneous
    layouts (we can't change the GtkButtonBox ot a GtkBox - 
    that would be incompatible change)

 2) A way of picking a minimum size that scales properly
    with theme, stock icon size, and text size. My idea
    here is that we always put a hidden button in the area
    with some stock on and string (perhaps "Default") and
    use it's size as the minimum size.
Comment 3 Owen Taylor 2004-02-23 22:01:27 UTC
I think something like gtk_style_get_grid_size() that gives
the width/height of a "character" would be useful in a lot
of places.
Comment 4 Tommi Komulainen 2006-02-22 14:08:28 UTC
(In reply to comment #2)
> I think non-homogeneous + minimum width make sense, but this
> requires two things. 
> 
>  1) API additions to GtkButtonBox to allow non-homogeneous
>     layouts (we can't change the GtkButtonBox ot a GtkBox - 
>     that would be incompatible change)

Considering GtkBox:homogeneous already exists, wouldn't this actually be just a bugfix?
Comment 5 Matthias Clasen 2006-02-22 14:16:18 UTC
currently  buttonboxes ignore homogeneous. If we suddenly made it  pay
attention to homogeneous, we will at least have to override the default
to   be TRUE  for button boxes.  And even then, it would probably break
a ton of button boxes in glade files, since glade in its wisdom writes out the default values of properties explicitly...

And homogeneous = FALSE by itself would not handle the "minimum size idea
mentioned above.
Comment 6 Matthew Paul Thomas (mpt) 2009-09-21 12:01:12 UTC
Aha, so someone had reported this already.

I think the right approach here is to assign widths to buttons in a horizontal group based on how similar their non-adjusted widths would be. For example, imagine three buttons in a group, "Review Changes…", "Don’t Quit", and "Quit". "Don’t Quit" and "Quit" are similar enough in natural width that they should have the same allocated width. But "Review Changes…" is so different in natural width that it should have a width of its own.

I am not sure that this could reliably be done by GTK itself. But if it is done by designers instead, buttons will sometimes look obscenely wide in some localizations because one button in the group happens to be particularly difficult to translate.
Comment 7 Milan Bouchet-Valat 2009-10-08 13:48:02 UTC
I think a reasonable way of computing this is that if a widget size exceeds the means of all the other widgets' sizes (including itself, not matter) by a certain value (say 1.5), we can consider it as "free sized", meaning that we don't force it to be the same size as others. That's a little dirty, but IMHO Owen's proposal would not be ideal either because we can imagine a box with two wide buttons of approximately the same size; in that case, forcing their sizes would be useful.

The hard part in my proposal is to guess a nice value, and to check whether it would still fit in case there are two buttons requiring free size: the value might be wrong e.g. when there are two small buttons and two big ones.

Anyway, fixing that is not really trivial, even with that solution, since the GtkButtonBox code does all computations by hand, assuming all children are of the same size. But should be doable. Do you see major flaws with that approach?
Comment 8 Christian Dywan 2009-10-08 14:21:32 UTC
See bug 539907 with patch.
Comment 9 Matthias Clasen 2009-10-08 16:00:04 UTC
From what I can see, the patch in bug 539907 doesn't address the 'semi-homogeneous' part at all, does it ? Its only about giving up on homogenous altogether if there is not enough space for it.
Comment 10 Christian Dywan 2009-10-08 19:12:06 UTC
That is correct. Still it's an improvement and maybe a basis for a patch that does both.
Comment 11 Matthias Clasen 2010-08-16 20:58:21 UTC
Created attachment 168009 [details] [review]
preliminary patch

Here is a preliminary patch. Some enhancements should still be done: 
- make the exclusion work for much-smaller-than-average buttons too
- allow to explicitly mark a child as non-homogeneous
Comment 12 Allison Karlitskaya (desrt) 2010-08-17 21:56:51 UTC
on the topic of if we should have an API for marking a particular child as an outlier: i think we should not have this API.

even in cases that you "know" that it will be larger, why not just let the logic do the work?  if you are as sure as you think you are, then it will kick in every time anyway...