Re: GtkGroupBox and layout ideas for Gtk3

[Matthias Clasen <matthias clasen gmail com>]

On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson <alexl redhat com> wrote:

>
> In Gtk+ this would be done as a GtkGroupBox container with two GtkGroup
> hierarchies (one per direction). With the setup in Gtk3 this should be
> quite doable. However, there are a few things missing for a perfect
> match.

Sounds interesting. I guess the main advantage of using group
hierarchies is that you save yourself from fiddling with attachment
points.

> First of all, what happened to Bug 628902 "Add expand flags to
> GtkWidget". It seems to have stalled. This would be very useful.

Oh, I still want to land that. I wanted to bring it up for discussion
at a team meeting first, and then last weeks team meeting was
torpedoed by a backhoe incident in my backyard...

> Secondly, the matisse layouts heavily feature baseline-aligned layouts,
> which I think would help gtk+ a lot to reach the next level in gui
> neatness. The problem with this is that its not enough to just add a
> baseline property to the widget, because baseline handling must be part
> of the size negotiation. For example, a baseline aligned hbox with to
> labels, containing "Y" and "y", clearly would be taller than the maximum
> height of the two labels. So, we need to change the
> gtk_widget_get_preferred... APIs to include the baseline. Fortunately
> these are not set in stone yet, so we have time before Gtk3 is released.

Right, baseline support would be very nice to have. It was part of the
original width-for-height SoC project, but turned out to be somewhat
complicated and wasn't really completed. We should revisit that and at
least figure out what api changes it might need.

> Third, rather than hardcoding spacing in containers, matisse is based on
> adding spacers (gaps) to the layouts. These gaps are either of custom
> size rigid (basically what we get in gtk now) or flexible, but mostly
> they are of standard sizes, that are tied to the theme. For instance, it
> has standard sizes for distance to container edge, distance between
> related components, distance between unrelated components and distance
> for indentation.
>
> In fact, not only do these distances depend on the theme, but their
> exact values actually depend on the widgets in questions, such that e.g.
> the distance between two related buttons could be different than between
> a label and a related button.
>
> I'm not sure the per-widget-type distances are all that useful, but at
> the very least having the other standard distances available and themed
> would both make Gtk+ code less riddled with constants, and allow themes
> that have different amounts of whitespace.

What we have in that area is a rather unfortunate mess of spacing
properties and style properties. Incidentally, flexible space came up
in the grid discussion just today.