Centralize logic for handling logical children

[PureWeen]

Description of Change

A lot of our logical children code was just being copy and pasted between different controls. This PR standardizes Adding/Removing logical children inside Element. This way, whenever we add/remove a logical control we always make sure the same set of operations occur and that the VisualDiagnostics code also gets triggered.

This PR doesn't apply these changes to the Page elements yet because I felt like that would have stuffed too much logic into one PR.

Once/if this PR is merged then I will do a follow up PR against Page and all the derived page types. This will help us to avoid scenarios where things aren't showing up in the VisualTree, plus, once we get Page straightened out, users will be able to add logical children to page, which has come up on the community toolkit CommunityToolkit/Maui#620.

The end goal will be to also remove the ChildrenNotDrawnByThisElement and AllChildren properties on Element as well. Which were only really hacks to workaround how LogicalChildren are handled inside Page

Implementation

• The idea is that any subclasses should only call AddLogicalChildren/RemoveLogicalChildren to interact with their logical children. They shouldn't need to provide their own storage container for their own logical children. That's just handled/managed by Element now
• I did add an override for LogicalChildrenInternalBackingStore, because there are a few cases (Page/Layout) where it's going to take a little more effort to make that code work by only calling AddLogicalChildren/RemoveLogicalChildren. Page also makes a lot of assumptions about its LogicalChildren, for example, it automatically calls LayoutChildInBounds on every single LogicalChild.

[MartyIX]

Why are the children "logical"? Is there a simple explanation?

[github-actions]

Thank you for your pull request. We are auto-formatting your source code to follow our code guidelines.

[github-actions]

Thank you for your pull request. We are auto-formatting your source code to follow our code guidelines.

[mattleibow]

Wow, gone from DO NOT USE to a public feature. Is this intentional and why was it marked so strongly before?

[PureWeen]

Yea, I don't fully understand the strong language. IVT really just exists because of where LogicalChildren was setup wrong. Any case where the LogicalChildren and the IVT diverge seems like a defect of the control. For example, ListView, for some reason, completely breaks if you start mapping the LogicalChildren to realized cells (basically what we do for CV).

I think we could get rid of all these hacks

maui/src/Controls/src/Core/BindableObject.cs

Lines 265 to 279 in ebfa27a

	protected virtual void OnBindingContextChanged()
	{
	BindingContextChanged?.Invoke(this, EventArgs.Empty);
	if (Shell.GetBackButtonBehavior(this) is BackButtonBehavior buttonBehavior)
	SetInheritedBindingContext(buttonBehavior, BindingContext);
	if (Shell.GetSearchHandler(this) is SearchHandler searchHandler)
	SetInheritedBindingContext(searchHandler, BindingContext);
	if (Shell.GetTitleView(this) is View titleView)
	SetInheritedBindingContext(titleView, BindingContext);
	if (FlyoutBase.GetContextFlyout(this) is BindableObject contextFlyout)
	SetInheritedBindingContext(contextFlyout, BindingContext);
	}

if the LogicalChildren were accurate.

Is there any scenario where it makes sense for LogicalChildren != IVT.GetChildren?

I could rename LogicalChildren to VisualChildren and then I guess it's more in line with the language we're using for IVT.

[drasticactions]

AFAIK, the original reason why LogicalChildren was discouraged was to avoid people using it to access underlying elements and build UI Structures around it rather than using Binding and acting on elements organically. For example, you wouldn't want someone to try to poke at individual elements in a ListView or CollectionView via LogicalChildren, as those items come and go as needed, and trying to pin something to one could create problems if you don't know what you're doing.

IMO "VisualChildren" is a misnomer. I believe @PureWeen brought that up before with Shell: Shell is virtual controls made up of visual elements that are not, by themselves, "Visual." But they still need to be represented in the LVT as that is the proper makeup of your application, From what the Window has on down. Then again, IMO, as long as the information is correct, I don't care what the name is, lol.

[github-actions]

Thank you for your pull request. We are auto-formatting your source code to follow our code guidelines.