Everything is a control/widget arhitecture, i.e. every component of a control can be replaced

[Jure-BB]

Flutter has shown that the composite design pattern can be a very powerful tool for creating user interfaces.

The key concept is that every higher level control is build from other controls and that all child controls can be replaced.

Primitive controls are the ones that contain lower level code, e.g. code to draw on canvas.

A common "mistake", for example, is a Button control with a string property for text. This immediately cripples customization of the button control. If type of this property is changed to be a base control, then developer can use either Label or Image control or any layout control or any custom control to be placed inside the button. So this button control is flexible enough to be a text button or image button or any other clickable control.

This pattern lends itself to easily and quickly create custom controls from basic controls or to completely transform existing complex controls (which is hard to do without an arhitecture like this).

In flutter, there are some places, where composition of widgets is somehow broken:

• handling scrolling behavior requires slivers instead of widgets, which breaks the flow of widgets composition
• some widgets don't expose all parts as replaceable widgets, which severely limits customization of these widgets

How and what kind of information propagates through the tree (e.g. user input events, default styling...) is also an important design consideration.

What are MAUI's design goals regarding composition? I know some composition was already possible in Xamarin.Forms, but it wasn't a core element of the arhitecture, because controls relied on native controls. But since Maui.Graphics.Controls don't rely on native controls, is there any special focus on this pattern now (like with Flutter's "everything is a widget")?

IMO, this is a powerful arhitecture.

(Note, that this is only intended as discussion of possible design arhitecture which has both pros and cons. I haven't used Maui.Graphic.Controls yet, so I don't know how much it already aligns with discussed arhitecture, but from my experience many UI frameworks (for various reasons) fail to implement this well)

[robloo]

Flutter has shown that the composite design pattern can be a very powerful tool for creating user interfaces.

Flutter has shown this? What? WPF was first by a wide margin. And it's a Microsoft tech led by the .NET team. How so much has been forgotten...

Xamarin Forms is the one that went backwards to the days of Windows Forms and forgot what XAML UI frameworks were supposed to be. Your example of a Text property on Button is a good one and shows how poor the design was from the start.

As a Microsoft project I think this should be architected more on WPF/UWP ideas than Fluttter. That's what the dev community is already familiar with (or at least should be).

[robloo]

@GeraudFabien I think we all know how MAUI works today. This project is fundamentally changing that to the point where compositional approach to controls is possible-- building from primitives like WPF.

I wouldn't say native was popular when Xamarin first started. There was simply no other choice. That's why most applications started moving to web tech -- to share code. Its what devs always needed. At Xamarin, Forms started just as a simple project and I dont think they really intended for it to get so big or they would have done things differently. They were also very stubborn and didn't really see why anyone wanted something other than native. Many were asking for WPF at the time though.

There was also a huge internal fight at Microsoft where devs could see that a Flutter/WPF render everything architecture was the future. They were told to take a hike. Guess where the original Flutter devs came from? Thats right, Flutter was started by some ex Microsoft devs that left the company because Microsoft's management was so bad they couldn't see how good of an idea it was.

Finally, I have no idea why you put a link to the project we are discussing. Obviously we are already here.

[GeraudFabien]

I made a mistake between two thread and though this thread was on dotnet/maui. Sorry if i didn't made this mistake i wouldn't have post this.

[robloo]

Ah ok, that explains it, no worries!

[jsuarezruiz]

Interesting thread. I think it can be summed up that what you really want is the freedom to be able to nest, replace, and customize any part of a control.

[Jure-BB]

@jsuarezruiz Yes, you could say that. One important aspect is that this customization is based on a common (unified) set of interfaces/abstractions. So, not only that you can customize any part of a control, you can also place any control inside of any part of any control.