What about ubiquitous things for Xamarin.Forms?

[juepiezhongren]

Thanks to Flutter, a lot of xamarin-fans are seriously considering ubiquitous looking things,@Mike-EEE, but indeed there is avalonia for years, @kekekeks.

Thanks to Skixam, @adamped, a sample project aimed to create another platform like flutter.

• Xamarin.Forms is loved and enjoyed, but it is a "limited" abstraction in the form of native wrapper, which lacks the strong customizablity in wpf and avalonia. So, Miguel de Icaza's idea of offering render-options(wrapper vs skia vs...) for current xf controls is not to provide the beauty of Flutter or Avalonia.

• Skixam is great, but it is a "Hard Fork" of Xamarin.Forms. Ubiquitous UX is great, but native UX is also needed, e.g. alert and listView refresh animation. Existing wrapper controls are still good.

So, I suggest that there should be a different set of ubiquitous looking controls(Ubis) , which is to boost the ecosystem for forms and not to compete or to replace it. My suggestions are below:

1. UbiGrid, UbiStackPanel, UbiLabel...... Ubis are better than a new platform, because it could be used together with existing forms' api without any change.

2. For nesting, "only-ubi", there should only be one renderer just like skixam' idea.

<UbiGrid>
    <UbiStackPanel>
        <UbiLabel/>
        <UbiButton/>
        <UbiLabel/>
    </UbiStackPanel>
</UbiGrid>

3. For nesting, "non->ubi", renderers should be as many as root-ubis, below there should be 3

<Grid>
    <StackPanel>
        <UbiLabel/>
        <UbiButton/>
        <UbiLabel/>
    </StackPanel>
</Grid>

4. For nesting, "ubi-root", there should be 2 renderers, one skiaView renderer and one other render for nonUbis layout.

<UbiGrid>
    <UbiStackPanel>
        <Grid>
           <UbiButton/>
        </Grid>
        <UbiButton/>
        <UbiLabel/>
    </UbiStackPanel>
</UbiGrid>

5. Skia is good, but to decouple it from ubi is better. Skia is only for 2D, other engines should also be given the hook. So, there will be things like this. BTW, skia into wasm is possible, but there seems to be no prototype, SO to use another engine based on web canvas API is a MUST!

<UbiGrid Engine="Skia">
    <UbiStackPanel Engine="Urho">
        <Grid>
           <UbiButton/>
        </Grid>
        <UbiButton/>
        <UbiLabel/>
    </UbiStackPanel>
</UbiGrid>

[weitzhandler]

@juepiezhongren I like the concept, though not the way you laid it out.

In my dreams Avalonia-like framework is the perfect option. Native look and feel is really not much of a concern to me; I would prefer the controls to be rendered the same everywhere, with an option to add native look and feel themes to each platform for those who require it. As soon as that gets wasm support, Silverlight is back, and there will only be left to miss RIA Services 😁

[jassmith]

@MisterJimson actually the idea is that material shell inherently brings ubiquitous controls

[MisterJimson]

@jassmith how exactly? Rendering raw or styling native controls? Styling native controls will always have some inconsistencies, even if minimal.

[juepiezhongren]

@MisterJimson shell is based on skia or ios CoreDraw api, i think @jassmith so, there will be fluentShell or cupertinoShell?

[jassmith]

@MisterJimson as @juepiezhongren yes the idea is it draws fully from scratch. It wont have to draw on the target platform but you could certainly ask it to. The goal is on to bring Material (with MaterialShell at least) everywhere.

@juepiezhongren Ideally yes. The problem right now is both FluentShell and CupertinoShell would rely heavily on live blur. Android is lovely and all but somehow they've managed to avoid getting an efficient live blur view. This made Material the natural first target while we figure out exactly what to do about that problem.

[jassmith]

To be clear, Shell does not do drawing, MaterialShell does.

[gulshan]

Have you guys seen this- https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample ? Only for desktop though, not mobile platforms.

[juepiezhongren]

@gulshan server-side is good

[PureWeen]

@juepiezhongren thoughts on https://github.com/xamarin/Xamarin.Forms/issues/4435

It seems similar to what you propose here except instead of being a tag it's an attribute that brings about the ubiquity and if someone were inclined they could create Visual="Skia"

[juepiezhongren]

@PureWeen i dont treat visual="skia" a good suggestion, simply because current xf's controls lack two much properties for personal customization, eg. brush, controlTemplate, etc.

[juepiezhongren]

or, just make current controls full api implemented, lots of properties invalid while wrapper-mode and valid while skia-mode

[samhouts]

We've made a lot of progress on Visual in the last few months. We've love to get your feedback on it. We invite you to try the Visual Challenge and let us know if this solves any pain points for you that led you to make this proposal. Thanks! https://github.com/davidortinau/VisualChallenge

[juepiezhongren]

@samhouts visual is good, but we do need draw, we do need pixel-perfect solution

[PureWeen]

So where does this enhancement request fall when held up against visual and the drawing spec https://github.com/xamarin/Xamarin.Forms/issues/2452

simply because current xf's controls lack two much properties for personal customization, eg. brush, controlTemplate, etc.

This is pretty easily overcome via attached properties that we are figuring out the best way to achieve over here

https://github.com/xamarin/Xamarin.Forms/issues/5005

[weitzhandler]

@samhouts

We've made a lot of progress on Visual in the last few months.

By us, Windows and desktop are first. Visual doesn't even support UWP, won't even try it.

[samhouts]

I think we can close this now that we're making progress on #2452. Thanks!