align vs expand vs grid

[Benjamin Otte <otte gnome org>]

Hey,

I've had an interesting discussion that has so far involved Matthias
and Alex about align and expand flags and about GtkGrid's involvement
in it[1]. This discussion is mostly academic in that it should never
appear in the real world. People should set their expand and align
flags properly when designing a user interface. However, this problem
happens when using the default settings, so people will inevitably
encounter it. Most likely they will encounter it
- while preparing their UIs in Glade
- when writing tutorials
- when writing testcases
so it seems useful to define a proper behavior. So lets go on to the problems.

(1) Should align apply when the widget expands?
An easy warm-up question, it can be answered with yes/no. Currently
the code in GtkWidget constrains the size allocation of a widget to
its natural size unless it is set to ALIGN_FILL.[2] This means that
even widgets that are set to expand will never grow bigger than their
natural size when a different align is set. My intuition is that
expand set to true should override the align setting and expand the
widget to fill all available space. If you do not want that and want
to instead align your widget, you can hardcode the expand to FALSE.
What brought me to consider this question is that expand is inherited
by parent containers, so an align set on _any_ ancestor of an
expanding widget will effectively nullify its expansion and I wondered
if that's intentional.

(2) How should GtkGrid handle extra space when no child is expanding?
This question arises when a GtkGrid is set to expand while none of its
children are or when the grid uses ALIGN_FILL and gets allocated extra
space - Open glade, put a button into a grid into a window, make the
window bigger, now you've got the problem. Previous discussion about
this exists on gtk-devel[3] containing many solutions. Among them:
- Don't assign any extra space to children, use it as space on the
right/bottom side. (This is the current behavior)
- Don't assign any extra space to children, center the contents in the grid.
- Don't assign any extra space to children, use it as spacing between children.
- Assign the extra space to children, behave as if all children had
expand set to TRUE.
Note that all of these methods can be achieved setting various expand
and align flags on the grid and/or its children, so in the end they
are basically all equivalent.
Unfortunately, all of them have interesting side effects that can
require some work to undo them, in particular if you insist on one
widget

Once you're done answering these 2 questions, please consider fixing
the script I just committed[4] to make the alignment test and the
flags test produce identical output using the reftest machinery. It'd
help a lot in explaining your idea in code.


Now on to my ideas about this:

(1) No
Align should not apply. Widgets that are set to expand have a maximum
size of infinity and any size you assign them should not be
constrained.

(2) Assign the extra space to children, behave as if all children had
expand set to TRUE.
This can result in ugly output, but has some serious advantages
compared to all the other methods. The mail I quoted above[3] contains
this :

On Sun, 2010-10-10 at 12:34 -0400, Havoc Pennington wrote:
> The general principle I think is that if a child doesn't say it can
> benefit from expand, it doesn't make sense to expand it. For example,
> expanding a button just looks bad.
>
And I think this principle is wrong. First of all every other
container (that is not considered for deprecation) does assign extra
space to children (in particular all subclasses of GtkBin do, such as
GtkWindow, or GtkExpander). Second, if children should never get
assigned extra space, why do we have the ALIGN_FILL parameter? Third,
if the grid decides where to put the extra space, the align property
does not ever make sense (with none of the other methods described
above would it be possible to have a single child in the grid be
end-aligned. Fourth, 2 interesting invariants hold for a Grid with one
child: 1) It behaves identical to all bin subclasses and 2) it does
not modify the layout at all. And fifth, it is the easiest to work
with for achieving the other effects:
- The current behavior can be achieved by using ALIGN_START on the grid
- The centering behavior can be achieved by using ALIGN_CENTER on the grid
- The spacing behavior can be achieved by using ALIGN_CENTER on all children


But because my gut feeling is not sure about this and because I wasn't
involved in the original design discussion and might be missing
something, I'd welcome some more input on this.

Benjamin


1: If I were ranting, this would include something about people adding
functionality to GTK without actually porting at least a few
applications to it, but I'm in a good enough mood, so a footnote must
suffice. ;)
2: http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h=3.1.4#n5126
3: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00072.html
4: http://git.gnome.org/browse/gtk+/commit/?id=c2f23ccd230a0dce89848cee987974f277b2aa06