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

[Brecht Van Lommel]

On Fri, Aug 23, 2013 at 3:14 PM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> Hmm… I’m fine with it, as long as all nested layouts are defined as aligned.
>
> E.g. in:
>      col = layout.column(True)
>      row = col.row(False)
>
> ... items in row will still be aligned. This is bad, imho (and DingTo
> agreed here). However, if both col and row are defined as 'aligned', I
> see no problem with the recursive call (and hence aligning all items in
> both col and row into a single 'group'). That’s what my patch is doing.
>
> So yes, I guess we should forbid that implicit 'alignment', and force to
> specify it at each level of layout, when required (I think at least the
> four gpencil buttons in 3D view's object tools use such an implicit
> column+row alignment).

Ok, sounds good to me.

> Yeah... don’t know why this happens indeed, in my two-columns layout of
> WeightEdit modifier, it works as expected... Anyway, that left/top label
> modification is more of an oportunity-change, we can let this aside for
> now. The only thing I really need here is to explicitly inherit the
> 'align' parameter from parent layout, so that text fields & co still
> behave as expected when aligned... ;)
>
>>> 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?
> Well, when we have label above widget, we do not need all that width
> sharing, we have full width available for both! Else (label to the left
> of widget, aka horizontal sublayout), there is no change here from
> previous code.

There is a change actually? For example the Render panel, it shows a
bit different. Anyway this change I would skip for compatibility
reasons.

>> 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?
> I had to dive into this because else I could not get my uiList filtering
> UI right (as I use an aligned column to layout the list itself, the grip
> + filter_show buttons, and the filter options, but then do not want all
> filter options to be aligned into a single group!). Else I have to add
> separators, but these take way too much room!

Ok, the alignment stuff I don't mind, it has minimal impact, just the
vertical label alignment thing seems to break quite a bit of our UI,
so would rather not change that.

Brecht.