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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list