GNOME Bugzilla – Bug 84188
"Dialogue" button widths should not be homogenous
Last modified: 2010-08-22 23:58:47 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.
(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.
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.
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.
(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?
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.
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.
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?
See bug 539907 with patch.
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.
That is correct. Still it's an improvement and maybe a basis for a patch that does both.
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
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...