*** Bug 740215 has been marked as a duplicate of this bug. ***

We need support for hexpand on the left/right so that we can implement the new designs for Builder.

It looks like after distributing the natural sizes, the size_allocate implementation just subtracts end_width from the available width. We can probably just check for hexpand and ignore the subtraction in that case.

Oh nevermind, I forgot we support packing multiple items.

I guess the workaround for now is to just get_ancestor() the box.

Created attachment 330328 [details] [review]
headerbar: simplify calculation in size-allocate

There's some extraneous MIN() calls that have predetermined answers.

This commit drops them and then simplifies a few redudant checks
into one MIN call.

Created attachment 330330 [details] [review]
headerbar: deduplicate some size allocation code

With a headerbar, the widget in the center may be a label
(constructed internally), or a custom widget constructed
externally.  The size allocation code needs to handle both
case uniformly, and so there's more than one place that
checks which one to use and does an operation on the
correct one.

This commit simplifies the code, by checking up front which
one is the center (title) widget, storing that in a temporary,
and then deduplicating all the logic later on in the function.

Created attachment 330331 [details] [review]
headerbar: compute nominal size of sides up front

In order to support the expand property on children, we're
going to need to look at the size of each side of children
up before allocating them (to compute how much extra
allocation each child gets).

This commits lays the groundwork for that analysis by splitting
the size calculation of each side of the header bar outside
of the loop that allocates each child of the header bar.

Created attachment 330333 [details] [review]
headerbar: support hexpand property for children

The header bar currently ignores the hexpand property on its
children.  This commit changes the code to honor that property.

It divvies up any free space and distributes it equally to packed
children (with any left over space given out a pixel at a time
on a first come first serve basis).

This commit also makes sure the center widget can be marked expand.
It accomplishes this by using up the padding it centers itself with.

so the expand policy i took was:

1) all the children marked expand on each side of the title divvy up free space uniformly
2) if there are a few leftover pixels, they get given one pixel a piece first come first serve
3) if both the title widget and some children are marked expand, title widget gets half the free space from each side (and children from each side divvy up the other halves among themselves)

2 and 3 are a little arbitrary so might make sense to do something else.

One concern I have is that apps in the wild might break if they accidentally have expand set and were inadvertently relying on it getting ignored.

(In reply to Ray Strode [halfline] from comment #8)
> One concern I have is that apps in the wild might break if they accidentally
> have expand set and were inadvertently relying on it getting ignored.

The number of headerbar-using applications is still relatively small, so I think we might be okay with the change and some internal testing, plus notify people on the GTK blog/pgo/ML about the change.

Review of attachment 330328 [details] [review]:

hmm, suspicious. Not sure what I was thinking at the time. But you are correct that this is equivalent

Review of attachment 330330 [details] [review]:

ok

Review of attachment 330331 [details] [review]:

ok

Review of attachment 330333 [details] [review]:

ok. Please add a note about this to docs/reference/gtk/migrating-3xtoy.xml

Attachment 330328 [details] pushed as e0bebba - headerbar: simplify calculation in size allocation code
Attachment 330330 [details] pushed as eccfce5 - headerbar: simplify some size allocation code
Attachment 330331 [details] pushed as 847a43c - headerbar: compute nominal size of sides up front
Attachment 330333 [details] pushed as 0015ebc - headerbar: support expand property for children

Thanks for doing this at the end, I already see the effect in some appliacations.

Yosef, which applications do you see an effect in? Our goal is to not affect previous applications (unless they were clearly doing something wrong). It would be good to have a list of them so we can notify them.

The music time scale in lollypop.