xaml-math
xaml-math copied to clipboard
ForNeVeR
Xamarin Forms support
Xamarin Forms (Reference: https://github.com/ForNeVeR/wpf-math/issues/17#issuecomment-362284365)
Xamarin Forms is a cross-platform UI library that focuses on mobile platforms (iOS, Android, UWP), which got extended to desktop platforms very recently (Mac - UIKit, Linux - GTK#, Windows - WPF). It is better than Avalonia in that with the 2016 Microsoft acquisition of Xamarin, this has become Microsoft-supported and got a huge boost. As with Avalonia, this is an XAML-and-MVVM UI library too.
Btw, a C# LaTeX library has recently been ported to Xamarin.iOS (might worth a look): https://github.com/verybadcat/CSharpMath (It has died down a bit in the recent weeks though)
Well, I don't want to raise a discussion what's "better" and what's "worse", so please don't. The request about Xamarin Forms is valid and have all my support, although currently I personally have not enough resources to start working on it.
I case anybody else wants to start working no this topic: feel free to ask any questions. I'll be glad to help you to plan the development and manage the technicalities and the project architecture.
Yes this would be very good, but I would replace Xamarin.Forms with SkiaSharp, because:
- SkiaSharp is the standard 2D drawing library for Xamarin.Forms
- SkiaSharp also works directly on WPF and UWP and apparently now on any platform with .Net Core support.
@charlesroddie well, we're discussing various levels of integration here:
- on low level, we need a renderer engine such as WPF, DirectX or SkiaSharp
- for high-level integration (i.e. a component / control), we need WPF, Avalonia or Xamarin Forms
SkiaSharp will move us towards both Avalonia and XF I think.
Yes but as you said on the other thread the renderer is the most important part. The controls I can think of that would build on this, even some quite interesting ones, would usually need some framework-specific code but that would just be a few LOC on top of the renderer.
@charlesroddie you're right, and that's the exact thing I'm saying: controls require framework-specific code, while the renderer requires, well, drawing library (let's call it that)-specific code. These two aren't conflicting at all, and they will complement each other. To successfully port WPF-Math to other platform, we'll need both.