For #35, I added a change to hook into MAUI's VisualElement MesureInvalidated event to get the LayoutPanel to invalidate.
Basically, as far as I can tell stepping through it, changing the children of the MAUI layout controls does cause Avalonia to properly call for an invalidation of the Panel wrapping it (Despite what every LLM will tell you!) but when it gets to the panel, the Available Size within the Avalonia Measure method is exactly the same as the previous pass, so it doesn't update, so anything within the inner bounds of it doesn't update correctly.
I tried reproducing this with the base Avalonia controls in an Avalonia app to see how it handles the parent change, and it's fine. It's the exact same controls as what the MAUI bindings make, but the layout step for the outer panel has updated AvailableSize values that then cause the redraw.
So, my current working theory is somewhere between the MAUI and Avalonia.Controls.Maui code, the values for the Layout are not populating right, so the wrong values are available to Avalonia when it redraws, since the LayoutPanel values should be driven by what MAUI is telling it.
In the MAUI Source code, depending on the platform and specific control (I think iOS basically ends up invaliding every UIView through this method), some do hook into this event to do the same thing I did here, but I have a feeling it's the same hack-ish solution to dealing with it.
For #35, I added a change to hook into MAUI's VisualElement
MesureInvalidatedevent to get theLayoutPanelto invalidate.Basically, as far as I can tell stepping through it, changing the children of the MAUI layout controls does cause Avalonia to properly call for an invalidation of the Panel wrapping it (Despite what every LLM will tell you!) but when it gets to the panel, the Available Size within the Avalonia Measure method is exactly the same as the previous pass, so it doesn't update, so anything within the inner bounds of it doesn't update correctly.
I tried reproducing this with the base Avalonia controls in an Avalonia app to see how it handles the parent change, and it's fine. It's the exact same controls as what the MAUI bindings make, but the layout step for the outer panel has updated AvailableSize values that then cause the redraw.
So, my current working theory is somewhere between the MAUI and Avalonia.Controls.Maui code, the values for the Layout are not populating right, so the wrong values are available to Avalonia when it redraws, since the LayoutPanel values should be driven by what MAUI is telling it.
In the MAUI Source code, depending on the platform and specific control (I think iOS basically ends up invaliding every UIView through this method), some do hook into this event to do the same thing I did here, but I have a feeling it's the same hack-ish solution to dealing with it.