Fix/document layout system

[BioTurboNick]

One of my biggest pain points in making complex layouts in MAUI is that the result of the rendering pass leaves parts of the layout using measurements from an earlier pass. It's as if there's a missing rendering pass after the last measurement pass. I'm spending way too much time trying to finesse a way to make it work correctly. And I can't tell if I'm just not using the system correctly, violating some expectation, or if the system is broken.

I would like to see documentation for how the MAUI layout system works, and how custom layouts are expected to fit into this system.

Such documentation existed for WPF, such as here: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/layout?view=netframeworkdesktop-4.8

[BioTurboNick]

An example of such a layout experiencing this issue:

I want a control to rearrange itself based on whether its bounding box is wide or tall. So when the size of the object changes, I adjust Grid attached properties to place the inner layouts in different locations on the grid. But what I sometimes observe is either 1) the on-screen arrangement reflects the previous state, such that it renders tall when it should be wide and vice versa (if I only adjust when there are changes) or when I interact with the controls, triggering a fresh layout pass; or 2) the arrangement is just incorrect. Which of these occurs depends on when the base OnSizeAllocated is called.

In another related example, the text labels in a nested control either do not fit inside their bounding box, or will end up infinitesimally thin because an intermediate resize cycle provided a narrow measure.

[Xyncgas]

MAUI showed products working fantastically, however I suspect the framework it's tailored to their taste, their ways of making application so there's a lot assumptions in the framework potentially about what you are supposed to do. I recommend UI frame works stop making the assumptions for application developers, because we are creative people that's creating disruption in the industry therefore bringing new energy to the economy, wanting to be writing programes in whatever way we can

There're a lot smart people who doesn't need to do things using the hundreds of features in the UI framework that's being maintained, what they needed was a framework that can render given dimension, location, styling, handling events, providing layering for elements created so they understand hierarchy and 'z-index' when handling a mouse click that's it and people can make their own framework abstracting a rectangle and then a button with material design etc

[hartez]

I would like to see documentation for how the MAUI layout system works

Developer-focused docs (still in progress) are here: https://github.com/dotnet/maui/blob/main/docs/design/layout.md

Still some parts to write, and a few things that may need to be updated. If you find something in there that's confusing or doesn't answer questions, ping me so I can fill in the blanks.

[BioTurboNick]

I have yet to read in detail, but it looks extremely helpful, thank you!

One thing I don't see is mention of "OnSizeAllocated" - is using this to do anything touching layout effectively an anti-pattern? If so, would be great to discuss that.

[MartyIX]

Yes, OnSizeAllocated is something that would be very helpful to document. Ping @hartez.

[hartez]

Adding a section about OnSizeAllocated: #15617

tl;dr; it's still around for migration/legacy purposes, but it's been superseded by ArrangeOverride(). It's not an anti-pattern necessarily, though I have seen folks in the past (in XF) using it in ways that I wouldn't recommend. If you're invalidating your entirely layout from that method, then there's probably a better way to accomplish your goals.

[BioTurboNick]

Github should have a thank you reaction emoji; the others don't quite cover it. :-)

[BioTurboNick]

So I tried this refactoring (in 7.0.81):

class MyControl : Grid
{
    protected override OnSizeAllocated(...)
    {
        // Adjust positions and bounds of children and children's children here
    }
}

to

class MyControl : Grid
{

    protected override ILayoutManager CreateLayoutManager()
    {
        return new MyControlLayoutManager(this);
    }

    class MyControlLayoutManager : GridLayoutManager
    {
        public override Size ArrangeChildren(Rect bounds)
        {
            // Adjust positions and bounds of children and children's children here
            return base.ArrangeChildren(bounds);
        }
    }
}

(Documenting how the Measure/ArrangeChildren overrides should interact with the base method would be useful.)

Now this seems to mostly work. I had to move Drawable invalidations back into OnSizeAllocated for them to work properly. Though the drawables are drawn beyond their expected container right now on the first pass... still checking on that.

It seems like it is necessary to trigger a second layout pass with the same dimensions to obtain the correct appearance.

[BioTurboNick]

Okay, this could be a bug in GraphicsView on Android. It's doing something nonstandard with width and height. Filed a PR #15721

[BioTurboNick]

A workaround seems to be to do all the layout twice - once in Measure, again in Arrange.

[BioTurboNick]

Ah - if I extend PlatformTouchGraphicsView and have GraphicsViewHandler use it, and call Invalidate() in OnLayout(), that also fixes that issue. (perhaps it could instead be called in the base PlatformGraphicsView?)

[BioTurboNick]

Or not? I'm so confused lol. Might have been 7.0.86 issue, though I thought I was on 7.0.81 -- added it back and the problem resolved?

[BioTurboNick]

Anyway, another layout observation: adding and removing Grid column or row definitions during ArrangeChildren doesn't work. But changing the row/column/rowspan/columnspan attached properties does work.