Avalonia support

[gsomix]

Avalonia

TODO

• create a branch for Avalonia stuff (and we will then proceed to work on that branch using PRs with the usual branching policy, almost as with the master): feature/17-avalonia
• make PR [WIP] Port to Avalonia #98 non-destructive (because currently it destroys stuff, and that's unwanted) and merge it into the branch
• fix builds and add CI support for both modes (WPF and Avalonia)
• rebase work of @ahopper from WIP: Avalonia wpf combined #170 on top of the branch
• make sure tests work for WPF part
• make FormulaBlock public
• solve Extract WPF-dependent code into a separate project #63 in the branch
• remove the code duplication (at least most of it) — that's why Extract WPF-dependent code into a separate project #63 was necessary
• update the documentation
• after all of that, Avalonia may land into the master branch
• add packaging for Avalonia, but explicitly mark the packages as alpha (Publish Avalonia version to NuGet #192)
• check issue \colorbox renders root index invisible #128: it should'nt be reproducible for WPF and for Avalonia
• currently we're planning to only allow for solid colors in the portable code base; we'll have to think about supporting for non-solid colors (aka Brushes) for WPF- and Avalonia-dependent code
• Make sure the resources (.xml and .ttf) are deduplicated properly.

[ForNeVeR]

It isn't still clear what kind of support we can offer to Avalonia. Probably we could add the control like your FormulaControl (see #23). Anyways, it seems that it depends on #18.

[gsomix]

We can use drawing infrastructure of Avalonia that looks similar to WPF's one.

https://github.com/AvaloniaUI/Avalonia/tree/master/src/Avalonia.Visuals/Media

I will look into it later. And yes, I want to make a similar user control but for the xplat UI framework.

[Happypig375]

Would make sense to support Xamarin Forms at the same time too.

[ForNeVeR]

Hello, @Happypig375!

Your request totally makes sense. Could you please raise another issue about Xamarin Forms? I'd like to support it, although I've no knowledge of Xamarin at all. I'd consider this request as up-for-grabs at the moment.

[ForNeVeR]

Okay, here's the current plan.

• create a branch for Avalonia stuff (and we will then proceed to work on that branch using PRs with the usual branching policy, almost as with the master): feature/17-avalonia
• make PR [WIP] Port to Avalonia #98 non-destructive (because currently it destroys stuff, and that's unwanted) and merge it into the branch
• fix builds and add CI support for both modes (WPF and Avalonia)
• rebase work of @ahopper from WIP: Avalonia wpf combined #170 on top of the branch
• make sure tests work for WPF part
• make FormulaBlock public
• solve Extract WPF-dependent code into a separate project #63 in the branch
• remove the code duplication (at least most of it) — that's why Extract WPF-dependent code into a separate project #63 was necessary
• update the documentation
• after all of that, Avalonia may land into the master branch
• add packaging for Avalonia, but explicitly mark the packages as alpha (Publish Avalonia version to NuGet #192)
• check issue \colorbox renders root index invisible #128: it should'nt be reproducible for WPF and for Avalonia
• currently we're planning to only allow for solid colors in the portable code base; we'll have to think about supporting for non-solid colors (aka Brushes) for WPF- and Avalonia-dependent code

[rstm-sf]

Hello!

* make `FormulaBlock` public

Need to do just that? Or is it supposed to further improve the API?

I ask, because, as I understand it, we need to do this in order to upgrade to version 0.9 support:

System.MethodAccessException: 'Attempt by method 'AvaloniaMath.Example.Views.MainWindow.!XamlIlPopulate(System.IServiceProvider, AvaloniaMath.Example.Views.MainWindow)' to access method 'AvaloniaMath.Controls.FormulaBlock..ctor()' failed.'

Because

Class constructors and codebehind event handlers must be public
Avalonia / Breaking Changes / 0.8 -> 0.9 / XAML

P.S. I settled on the next in the switching to 0.9:

[ForNeVeR]

@rstm-sf, initial plan is just make it public, but, if you have any particular improvements for API, then feel free to apply them and drop me a PR.

Regarding the Avalonia changes: I think it's okay to make the class and any constructors public.

Regarding 0.9 update: well, it looks bad. I understand that Avalonia may be pretty much unstable (especially its font-based API), and we'll have to struggle with the instability. I heard that some release of Avalonia (0.9.x? 0.10?) will receive more proper GlyphRun API, we may/should use that.

[ahopper]

Hi sorry for my absence from this project, my initial use which faded may be starting up again. The 0.9.x release of Avalonia is very stable, the mods to text based stuff will probably happen between 0.9 and 0.10, How can I help?

[ForNeVeR]

Thank you so much, everyone. We did it!

The next release will likely have full Avalonia support.