[Bf-committers] UI layout: Why 'align' property of layouts is inherited?

[Brecht Van Lommel]

On Thu, Aug 22, 2013 at 11:33 PM, Bastien Montagne
<montagne29 at wanadoo.fr> wrote:
> Was wondering, why 'align' layout flag is de-facto inherited for all
> most common layout types (rows, columns, etc.)? I won't pretend to have
> a complete understanding of the layout engine, but this is currently
> giving me white hair...
>
> This very simple patch seems to fix this (afaict):
> http://www.pasteall.org/45073/diff
>
> It will induce edits in UI (e.g. 3DView tools, where some group of
> options are currently drawn 'aligned' even though there immediate layout
> is not set so), but imho it makes much more sense this way.
>
> Else it’s very confusing, especially as py code never know whether the
> layout given to it is aligned or not!

The reason it works this way is because the align option for buttons
is internally using the old align flags, for which there is only one
level, it doesn't have any notion of nested layout types. Such aligned
layouts over both column and rows aren't used much anymore though (I
actually couldn't find one quickly) so it could be changed, it's
always possible to manually set align flags for all levels.

> As I was in UI layout code, I also made "labelled items" (like e.g.
> string, non-expanded enums, etc.) sensible to current layout's direction
> (like expanded enums), so that the label is displayed above them when in
> vertical layout. This is what we already often do in py UI, using stupid
> UILayout.label calls for that. This simple change allows me e.g. to get
> rid of for label() calls in WeightEdit modifier's UI...

Sometimes you want it vertical if the width is narrow, but if it's
wide enough you want it horizontal. What the patch seems to do now is
not actually work this way in all cases. For a panel the top level
layout is a vertical layout but it still makes the items horizontal?
Otherwise e.g. the first Render panel layout would break.

> if (!is_vert)
>     w = w - labelw;

What is the reason for this change? It changes all the horizontal
label + button width a little bit but why?

My main concern with this patch is that it breaks API compatibility,
do we want to do this with 2.69 for a bit of code cleanup or is there
a more important reason to do it where it's impossible to achieve some
layout?

Brecht.