Stacklayout leaves layout space for items whose IsVisible=false

Description

Given the following Stacklayout with three buttons, I’d expect that if one of the buttons was marked isvisible=false, that the layout would not reserve layout space in the stacklayout for the invisible button. (that’s the case in Xamarin Forms). However, MAUI appears to generate a layout for a button that’s not visible.

<StackLayout Orientation="Horizontal">
                <Button Margin="10,0" Text="Button 1" HorizontalOptions="FillAndExpand" />
                <Button Margin="10,0" Text="Button 2" HorizontalOptions="FillAndExpand" />
                <Button Margin="10,0" Text="Button 3" HorizontalOptions="FillAndExpand" IsVisible="False" />
            </StackLayout>

Steps to Reproduce

1. Create a File -> New MAUI project
2. Create a horizontal stacklayout with three buttons
3. mark one button’s isvisible as false
4. Expected result would be the two remaining visible buttons that stretch the width of the Stacklayout
5. Actual result is that the invisible button still is laid out and has reserved space.

Link to public reproduction project repository

https://github.com/edgiardina/StackLayout_IsVisible_Bug

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS, Android

Affected platform versions

all platforms

Did you find any workaround?

No workaround I can see

Relevant log output

No response

[edgiardina]

@nebula2 Sure, I could, in the Page codebehind, do the math manually. That makes it more of a pain to restyle later. But the main point is that this worked for the most part in Xamarin Forms. Why is there a departure here in MAUI? Why are layout options considered “cursed” yet available to use?

It’s been a frustrating road unfortunately in my attempt to migrate a small hobby project from Xamarin Forms to MAUI (definitely over 50 hours now for the migration, if not more). The layout engine seems to have under the covers been subtly changed such that stacklayouts are not really usable. Stacklayouts were IMHO a great solution to the fragmentation of mobile display sizes. declaring discrete widths/heights and calculating my own layouts instead of using XAML goes against the spirit of the x-plat project. It wouldn’t be so bad to change all the stacklayouts to grids if we didn’t already have the Xamarin Forms standard to see how it should work, vs how MAUI works.

There have been a lot of confusing design decisions for MAUI that have made switching painful and I don’t understand the underlying philosophy behind them. Why is MAUI tied to the .net workflow version and not a nuget package like forms? The mobile frameworks shift quickly as vendors change them, and waiting until .NET releases in november isn’t an option IMHO. Why did stacklayouts get nerfed in MAUI?

[nebula2]

@edgiardina I don’t know 😕 I struggled very hard to create a stable app using MAUI (with lots of experience using Xamarin) and I have collected quite an amount of workarounds…