Avalonia support

[gsomix]

Avalonia

[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.

• [x] 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
• [x] make PR #98 non-destructive (because currently it destroys stuff, and that's unwanted) and merge it into the branch
• [x] fix builds and add CI support for both modes (WPF and Avalonia)
• [x] rebase work of @ahopper from #170 on top of the branch
• [x] make sure tests work for WPF part
• [x] make FormulaBlock public
• [x] solve #63 in the branch
• [x] remove the code duplication (at least most of it) — that's why #63 was necessary
• [x] update the documentation
• [x] after all of that, Avalonia may land into the master branch
• [x] add packaging for Avalonia, but explicitly mark the packages as alpha (#192)
• [x] check issue #128: it should'nt be reproducible for WPF and for Avalonia
• [x] 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?

[rstm-sf]

I am new to using avalonia / wpf

How can I help?

I think you can close this issue :)

Next, I will share previously unspecified actions when updating

• Breaking Changes

x:Class is now mandatory for XAML files with codebehind (windows, user controls, App.cs, etc)

• Here the order of the parameters is changed (or something else?) https://github.com/ForNeVeR/wpf-math/blob/ffd65d971943fd60bc549efff893e8463893be89/src/AvaloniaMath/DefaultTexFontParser.cs#L225-L226

[ForNeVeR]

@ahopper, no worries, we're still working on this project.

@rstm-sf, which of that it a problem? I believe we could easily update our markup and add x:Class, right? Aaand is it a resm syntax that was changed, or something else?

We have our resources defined as EmbeddedResource: https://github.com/ForNeVeR/wpf-math/blob/ffd65d971943fd60bc549efff893e8463893be89/src/AvaloniaMath/AvaloniaMath.csproj#L36-L45

I've heard of something called AvaloniaResource, should we maybe change the way our resources are defined?

[rstm-sf]

I've heard of something called AvaloniaResource, should we maybe change the way our resources are defined?

We can do this , thereby obtaining a slightly simplified code.

[ForNeVeR]

@rstm-sf, will it fix the 0.9 migration issue?

[rstm-sf]

@rstm-sf, will it fix the 0.9 migration issue?

No

[rstm-sf]

Maybe this thread can help us? Although I do not know how this can help

[ForNeVeR]

Thanks to @rstm-sf, we were able to fix the migration issue, and now AvaloniaMath is looking good, again.

The last step would be to fix the code duplication in the Avalonia branch: our current code should be generalized and decoupled from WPF (to create a common core library and two dependent ones for Avalonia and WPF). After that, we could merge the result into master, and support it as usual.

[ForNeVeR]

Thank you so much, everyone. We did it!

The next release will likely have full Avalonia support.