Experimental alignment layout manager using state retained in the layout manager

Based on https://codereview.chromium.org/2230913003/

[kylix_rd, 2016-10-24 21:42:57]

Description was changed from

==========
Added new AlignLayoutState which places align and state data into the layout
instance

BUG=
==========

to

==========
Based on https://codereview.chromium.org/2230913003/
==========

[kylix_rd, 2016-10-24 21:42:57]

kylixrd@chromium.org changed reviewers:
+ robliao@chromium.org, sky@chromium.org

[kylix_rd, 2016-10-24 22:11:42]

This CL and patch(es) are based on https://codereview.chromium.org/2230913003/
which pushes the state management from the attributes into the layout manager
itself.

[sky, 2016-10-25 02:55:03]

I can't quite tell if this is ready for review. It depends upon another patch,
but that hasn't landed.

In order to review this patch there needs to be a good description of what it
does. The docs that are there now aren't clear and would require me to dig
through the code to understand how it works. Consumers of this layout manager
shouldn't need to do that. Additionally any new layer manager increases the
complexity with views, so I would like to understand what it is about this
layout manager that makes it better than existing ones. Good documentation would
help illustrate this as well as showing how existing code converted to this
layout manager is easier and more succinct.

[kylix_rd, 2016-10-25 17:01:58]

On 2016/10/25 02:55:03, sky wrote:
> I can't quite tell if this is ready for review. It depends upon another patch,
> but that hasn't landed.
> 
> In order to review this patch there needs to be a good description of what it
> does. The docs that are there now aren't clear and would require me to dig
> through the code to understand how it works. Consumers of this layout manager
> shouldn't need to do that. Additionally any new layer manager increases the
> complexity with views, so I would like to understand what it is about this
> layout manager that makes it better than existing ones. Good documentation
would
> help illustrate this as well as showing how existing code converted to this
> layout manager is easier and more succinct.

The purpose here was to, hopefully, show that moving all the state information
into the layout manager made the code a little more complicated than keeping the
view-specific state attached to the views via the attributes. The housekeeping
for the state information is less "automatic".

Clearly, the code review tool isn't very good at showing deltas between CLs.

Some key points:

 o Core algorithms remain unchanged.
 o All child view bounds changes must be done via the layout.
   o Call SetBounds directly on the child view can cause undesirable behavior.
 o Layout API is a little more complicated.
 o Moving state into the layout does follow semantics of existing layouts.

I'd like to investigate reworking the existing layout managers to use attributes
where appropriate.