Re: Baseline alignment ideas

[Alexander Larsson <alexl redhat com>]

On ons, 2013-02-27 at 21:22 +0900, Tristan Van Berkom wrote:
> > How do we assign 5 pixels above the baseline based on this? All we can
> > do is give the child more total height (via gtk_widget_size_allocate),
> > we have in general no control of where that height will go. The child
> > might be expandable both above and below its baseline, but how can we
> > "tell" it to only grow above?
>
> Interesting... taking your previous example of HBox with widgets
> A, B, B, and D... let's consider that A & B is in VBox1 and B & D is
> in VBox2
>
> What you are asking (I think) is how can we determine that VBox2
> can only grow /below/ and that VBox1 can only grow /above/.
>
> Is this correct ?

Mostly, although there are more complexities. It may grow on both side,
but to different extents and with different "speeds". For instance,
imagine a multi-line label that is ellipsized and has the baseline
setting as GTK_LABEL_BASE_LINE_IS_LAST_ROW. At any point it shows N rows
with the baseline at the Nth row, and if you add height it will add
empty space below the Nth row, but then when you suddenly fit another
row you'll get the baseline at the N+1th row and the height the was
previously blow now got moved to above the baseline.

> I think this conversation needs a little bit more context (as to how
> precisely you plan to layout the groundwork APIs for this), but
> here's what I would envision:
>
> I think that HBox has the responsibility to 'request and set the baseline'
> of it's contents (being VBox1 & VBox2)

Thats not what I was thinking, but that does seem to make this more
doable. However, this means that *all* implementations of size_allocate
must respect the baseline when allocating itself. Thats very different
from how todays existing widgets work, and a radical break of "API". The
model i was expecting is the current one where widgets do whatever they
do in gtk_widget_size_allocate() but can report where this would put the
baseline.

Of course, in practice container widgets outside of gtk+ are not that
common, so its possible that we could make sure the gtk+ ones did handle
an extended form of size allocation, which would let us do baseline
alignment in most cases.

Of course, implementing size allocation of e.g an ellipsizing label like
the above example with a pre-chosen baseline will be complicated and
probably need new PangoLayout APIs...

> I'm pretty sure this approach work's in theory, but there's a big
> 'gotcha' in play... which is the intrusive 'halign'/'valign' properties
> and any properties which are implicitly calculated by the
> ->adjust_size_request() and ->adjust_size_allocate() vfuncs.
>
> Which means the whole thing breaks down if either VBoxes
> have a valign property that != GTK_ALIGN_FILL or that
> margins or border_width are set... this is a hard problem to
> figure out too... it might require that widgets retain access to
> the full allocation given them by their parent, instead of the
> final allocation stored after adjustments are made.

I'm not sure this is a problem. valign will in this case be BASELINE, or
we would not do baseline alignment of the child at all.
The margins and borders could well be done automatically like now, as
long as they correctly modify the baseline that the child get, i
think...

> Finally, it's worth noting (I'm sure you're already aware) that
> minimum & natural preferred_height_for_width() will hardly
> ever differ (they will only differ for vertically rotated text, or
> perhaps some GtkWrapBox which is oriented to wrap from
> top to bottom).

Ellipsized multiline strings is another case.