Uno Platform Support

[MartinZikmund]

Support for Uno Platform/non-XF UWP

Draft for #120

TODOs:

• macOS support (will require macOS support for Uno.SkiaSharp.Views)
• More samples (porting from XF samples)
• Input support
• float -> double dependency properties
• Fix WASM build (I will probably need @jeromelaban)
• Make default foreground depend on current theme

[MartinZikmund]

@Happypig375 Does not build properly yet, need to resolve some WASM issues, plus add some samples :-)

[charlesroddie]

I read through the list of changed files.

• CSharpMath.Xaml/Views.cs: small changes and not part of the core of the repo so OK
• CSharpMath.Uno/CSharpMath.Uno.csproj : small and not part of the core repo so OK
• CSharpMath.SkiaSharp.Wasm: this is Uno-specific so is misnamed. Should be moved into CSharpMath.Uno or renamed CSharpMath.Uno.SkiaSharp. It references Uno.SkiaSharp.Wasm so would not be expected to work on other wasm platforms such as Blazor.

This is definitely a valuable spike if only to test that CSharpMath works with Uno.

Main issue with merging IMO is

+3,397 −4

The aim of this PR, as clarified in the linked issue, is to allow usage from CSharpMath in a way that doesn't require writing the 10 lines of code needed to interface with CSharpMath.SkiaSharp. Adding 3400 lines to the repo in order to save perhaps 1-3 end-users having to write 10 lines of code each doesn't seem like good arithmetic to me. If there were hundreds of projects dependent on CSharpMath it would be a different story.

An ultra-clean extreme would be: it's SkiaSharp's responsibility to show people how to install a SkiaSharp view in any .net platform, and CSharpMath's responsibility to inject manage latex rendering in this view: then we'd only need to maintain one example project.

[Happypig375]

@charlesroddie Most of it is for an example project. It is a CSharpMath.Uno.Example just like CSharpMath.Avalonia.Example and CSharpMath.Forms.Example.

[charlesroddie]

Understood that it is example projects but example projects still take maintenance (e.g. having to make updates, and adding to build times for the solution). As mentioned the my paragraph it doesn't need to be CSharpMath's responsibility to maintain a lot of example projects and have them build and work.

[MartinZikmund]

@charlesroddie so the suggestion would be to remove the example project or to create a completely separate repository for Uno support? Most of the added code are the samples, which are helpful, but I can provide them separately in my own repo if they do not fit here well.

The goal of the SkiaSharp.Wasm going forward is to be the official first-party solution for WebAssembly (not just Uno specific)

[Happypig375]

@charlesroddie Not really. Each platform make minimal breaking changes and maintenance is low-cost. Build times of one front end do not affect other front ends.

[Happypig375]

@MartinZikmund I don't like separating repos after what I saw with https://github.com/oxyplot: repos other than the main one get little maintenance.

[MartinZikmund]

@MartinZikmund I don't like separating repos after what I saw with https://github.com/oxyplot: repos other than the main one get little maintenance.

First party support is better, but if you preferred not to have here directly, I would create a Uno fork separately (this was my original plan, until I noticed Uno was among the ideas for a future update)

[charlesroddie]

As long as we don't require platform example builds to succeed for PRs, and for @Happypig375 and @MartinZikmund to maintain the additional projects then it's OK for then another examples project can go through.

We'll definitely need to tidy up the repo - inlcuding creating a folder structure for examples, platforms, etc.. And creating a solution without the peripheral projects would be a good idea too.

My note on CSharpMath.SkiaSharp.Wasm should be addressed as even if

The goal of the SkiaSharp.Wasm going forward is to be the official first-party solution for WebAssembly

, it's not at the moment as is clear from the naming, and when it becomes official it would probably be merged into SkiaSharp anyway so that part of this PR would be deleted at that point.

[Happypig375]

As long as we don't require platform example builds to succeed for PRs

Why? The whole solution should be buildable, updates should come in via PRs.

[charlesroddie]

It could hold back PRs. Currently you are fast at fixing issues so not a problem if you are happy to fix PRs where any online builds are failing. But contributors shouldn't have to have all the build tooling needed to build all the example platforms, so should not be expected to confirm that the entire solution builds if it contains all of these.

[Happypig375]

If they can't build all the platforms, then PR checks will do it for them. The errors are publicly visible.

[jeromelaban]

@MartinZikmund at this point, building on GitHub actions or Azure Devops using a WebAssembly dependencies (Uno.SkiaSharp being one) is not supported. The only way to create a valid binary in CI is to use this docker image unoplatform/wasm-build:2.0.

I've made a change in the bootstrapper to provide the ability to get non-failing windows builds (unoplatform/Uno.Wasm.Bootstrap#216), but the resulting binary will be invalid, as the WebAssembly static linking step will be disabled.

In your case, once the bootstrapper PR will be published, you'll need to add the following:

<WasmShellForceDisableWSL Condition="'$(CI)'=='true'">true</WasmShellForceDisableWSL>

using the GitHub actions default variables.

This will allow you to make your Windows build pass, and add another job that will run on Linux to have a proper application.

[jeromelaban]

@charlesroddie Indeed, Uno.SkiaSharp.Wasm will not stay alive on a long term. It's only required at this point because of some missing features in mono for WebAssembly. Once the features are added, the official SkiaSharp package will support WebAssembly, most likely around the .NET 5 release.

[MartinZikmund]

@jeromelaban I am getting the issue I mentioned when building locally as well, is there something I am missing to get it working there? Thanks :-)

[jeromelaban]

@jeromelaban I am getting the issue I mentioned when building locally as well, is there something I am missing to get it working there? Thanks :-)

If you're getting this error locally, it means you have not setup WSL. You can set it up using this.

[yoshiask]

Would support for just UWP (not tested on Uno Platform) be helpful?

[Happypig375]

Would support for just UWP (not tested on Uno Platform) be helpful?

Uno runs on UWP just fine. What's the problem?

[yoshiask]

What I mean to ask is if CSharpMath.UWP would be useful in UWP-only projects after CSharpMath.Uno is added.

[Happypig375]

There was never a CSharpMath.UWP.

[yoshiask]

I know, I've just started working on it.

[Happypig375]

You can probably just reference CSharpMath.Uno in a UWP project with no issues. In this PR, CSharpMath.Uno only references Uno on non-UWP platforms.

[MartinZikmund]

Sorry for the delay on commits, I am currently slowed down with several other commitments, but I will definitely get back to this :-)

[MartinZikmund]

@Happypig375 @charlesroddie What about putting the sample projects in a separate solution (under UWPUno folder)? It would not be part of the main solution, so the sample's buildability would not affect PRs (plus would not require build adjustments for WASM build), would that be good?

[MartinZikmund]

🚀🚀🚀

[Happypig375]

@charlesroddie Let's also get this in with #240.

[Happypig375]

With the introduction of single projects, this probably needs a redo. I'll take an attempt at it.

[charlesroddie]

The title of this is "Uno Platform Support" but CSharpMath already supports Uno via SkiaSharp. Perhaps the title should be "A Second Way to Support Uno via Skiasharp", in which case what this second way is and the benefit of introducing it should be articulated.

The costs are real. Something Avalonia-specific got merged despite Avalonia being similarly already supported (also via SkiaSharp), and that made updating the repo over the last 2 months annoying. It wasn't clear who the Avalonia maintainer was (turned out to be @Happypig375 in the end).

What if CI build or release breaks? What if tests fail? What if things become obsolete?

[Happypig375]

@charlesroddie The feature at hand should be one UI control that invokes CSharpMath.SkiaSharp behind the scenes. It can reuse the Xaml definitions shared across Avalonia and Maui.

I think Maui, Avalonia and Uno make up the big 3 UI frameworks for C#. It doesn't really make sense to not support one out of three here.

[charlesroddie]

It doesn't really make sense to not support one out of three here.

See above comment, in particular

CSharpMath already supports Uno via SkiaSharp. Perhaps the title should be "A Second Way to Support Uno via Skiasharp", in which case what this second way is and the benefit of introducing it should be articulated.

[Happypig375]

So I have attempted to add a Uno front end using the latest templates which replace the separate platform projects with a single project under the Uno SDK.

I have now hit a roadblock:

• Apparently Uno's MeasureOverride gets called with available width of Infinity.

All other frameworks, including MAUI and Avalonia and even native WinUI, do not exhibit this behavior - they supply a fixed available width even when nested inside a scroll element with horizontal scrolling disabled.

This results in a TextView that can't automatically break at available page width (note that the text box above also renders out of bounds):

This is a pretty serious bug that happens specifically on Uno. I am unsure how to work around this, so it makes me unsure if we should even support this at all.

---

There is also a question on which control to use - SkiaSharp.Views.Windows.SKXamlCanvas as used in the original PR and here is said to be non-hardware-accelerated, i.e. inefficient, compared to Uno.WinUI.Graphics2DSK.SKCanvasElement. It seems that Uno 6.0 and above recommends the Skia renderer for all controls, which means that SKCanvasElement would be superior for "most cases", and yet it doesn't work everywhere as it needs the "SkiaRender" feature to be turned on for Uno.

It may be better to leave this explicit choice to the user instead of maintaining potentially two controls that can't nicely fit into the existing View-defining file that uses #ifdef across frameworks.

---

Side note: The original PR attempted to support UWP and Uno together. I suppose this extends to combining WinUI and Uno now, but making the example projects exhibit the same behavior across WinUI and Uno is also a bit annoying with different Binding behaviors as shown in the latest commit on TryPage. This is less serious of a concern though.

[Happypig375]

@MartinZikmund Can you confirm the above? Thanks.

[Happypig375]

@charlesroddie The benefit would be a super easy and straightforward way to display LaTeX in an existing application - just embed a MathView or TextView instead of having to go through a custom rendering process in code-behind. The relevant properties also become bindable XAML properties which means that all the XAML tooling for C# UI applications automatically work.

The code that supports this is as minimal as it gets with overlaying on top of existing Avalonia and MAUI view definitions. Most of the added code is for the Example project which can be updated out-of-sync when needed.

That is - if they work, but my investigation revealed two serious questions that may block direct support of Uno here.

[Happypig375]

I have received an answer from Uno Discord about MeasureOverride:

But I still have no idea how to properly implement TextView here with a size that depends on line wrapping.

[charlesroddie]

@charlesroddie The benefit would be a super easy and straightforward way to display LaTeX in an existing application - just embed a MathView or TextView instead of having to go through a custom rendering process in code-behind. The relevant properties also become bindable XAML properties which means that all the XAML tooling for C# UI applications automatically work.

OK so maybe it becomes clearer what this addition is. Certianly not "Uno Platform Support" but "Support for xaml-only usage in Uno" for people using Uno who want to avoid writing dotnet code. A microscopic benefit in my opinion.

There were problems when I updated the repo. Builds and tests started to fail because of something similar that had been added around Avalonia. Someone could contribute a feature or a maintenance fix and have to work on Avalonia/MAUI/Uno for no reason. So if something like this goes in, can any builds/tests related to Avalonia/MAUI/Uno become not required for merging PRs?

[Happypig375]

@charlesroddie You did a whole repo package update. Of course it would touch the Avalonia projects and need update work done over there. Someone who contributes a feature or a maintenance fix and didn't touch the Avalonia/MAUI projects, nor the exposed APIs of painter objects, wouldn't need to work over there.

Also, this isn't specifically "XAML-only usage" but "a UI control that wraps around a Painter object" (i.e. also applies to C# definitions of UI controls) rather than needing to delegate to a painter. The delegation to painter is done inside the UI control.