Avalonia: Roadmap

[kekekeks]

Since people are asking where we currently are and what is planned next, here is a somewhat updated roadmap for the immediate future. I hope that here it would be more visible and get updates more often.

Current state

Project is ready for use on Desktop platforms for projects targeting systems with "west-friendly" locales (CJK text input and RTL text aren't supported yet) and people who are able to see (screen readers aren't supported yet either).

For the list of issues to be addressed for mobile platform support see Mobile section below.

0.9 release

• Text layout engine for Skia backend. Will add support for Unicode surrogate pairs, RTL text and inlines
• Global menu bar for macOS and some Linux distros
• Input method support. Right now we are just handling whatever events are sent by keyboard which isn't suitable for CJK text
• [x] [Touch input](https://www.youtube.com/watch?v=0hGsIFjchqE) and scroll support
• [x] Ahead of time XAML to MSIL compilation

1.0 release

We don't want people to get TypeLoadException when using 3rd party controls and components, so the main focus there would be ensuring future API/ABI stability.

So we will most likely focus on features that would break API compatibility when implementedl. Notable examples are IME support currently planned for 0.9 release and Wayland backend for Linux that will probably require some rework of Popup API.

We'll also need to integrate some API diff to our CI process, something like Mono's API diff tool that generates nice API diffs for PRs

Mobile

For running properly on mobile platforms we still lack several features. They aren't tied to a particular release because of the general lack of manpower. But we are getting there.

General infrastructure:

• [DONE] Touch event support (I've got a laptop with touchscreen, to things will speed up a little)
• Touch selection controls in TextBox
• A way for controls to announce that they want text input, will be resolved by Input Method support
• [DONE] XAML compilation to IL. It's fine to parse XAML at runtime on Desktop/iOS, since either device is powerful enough or parser is compiled using LLVM and is a bit faster.

Missing bits in mobile backends:

• Enable GPU acceleration. We currently have a generic infrastructure for enabling OpenGL(ES) rendering that we are utilizing on desktop platforms, so it should be relatively easy to wire it up on mobile.
• [DONE] (managed overlays) - Add support for overlays for iOS (yes, they aren't implemented at all)
• [DONE] (managed overlays) - Fix overlays for Android (they were working before, no idea what's happened)

WebAssembly

I've spent a weekend tinkering with WASM using Blazor and SVG render target to avoid Skia linking issues. It turned out that while our ControlCatalog being somewhat operational, the current performance of Mono interpreter is way too slow.
It also might be the fault of our layout algorithms or me missing something since the debugging story on WASM is currently non-existant.

You can see the incomplete demo here: http://testapp.keks-n.net/ don't even try to open calendar or datagrid pages, they take ages to load.

So, for now we are waiting for SkiaSharp to be updated to a more-recent release of Skia, our core framework becoming faster and Mono optimizing its interpreter.

Historically writing a new backend for Avalonia has taken a week or two, it was usually the lack of features in the core framework that prevented us from utilizing platform features before.

[awb99]

HI! I see that it is quite easy to add new runtime engines to your platform. So I wonder if it would be possible / make sense to render AvaloniaUI applications via WebAssembly on a web browser. This way one could develop applications for Desktop, Mobile and Web. :-)

[kekekeks]

WebAssembly

See https://github.com/AvaloniaUI/Avalonia/issues/1387#issuecomment-389758464

[npolyak]

I am new to Avaloniaui, but very excited about possibility to build multi-platform applications with mmore than full power of WPF. My question is when are you moving to .net core 3.1? Currently the application is still using .netstandard2.0 from what I see. I bet a lot of code and dependencies can be removed if .net core 3.1 is utilized.

[MartenF]

An upgrade to .netstandard2.1 will permanently break compatibility with .net framework. I am not sure if that is a good idea before the release of .net 5.0

[kekekeks]

It should be possible to multi-target netstandard2.1 and net48, but I'm not sure if that's worth the complications.

[jinyuttt]

My point of view may not be correct, I just hope to exchange it.

First of all, the. Net framework is not worthy of attention in cross platform UI, and the focus should be NETCORE. WPF has met all the needs. If it needs a complete cross platform, it should also turn to NETCORE. It's what Microsoft does now to discard the burden, and Microsoft doesn't insist on all synchronization.

In addition, whether there can be related branches to let some people who are good at it complete common controls, such as ribbon, dockpanel or vs common components, especially chart controls. I also agree with developers from companies like devexpress to work together to develop on the basis of avaloniaui, or directly draw on OpenGL and integrate it into avaloniaui. I feel that Microsoft always wants to bind things of windos.

Can we open up a forum area in the official (http://avaloniaui.net/docs/) for people to exchange views directly instead of just various issues.

[ceremony]

I absolutely agree - .Net framework is increasingly a thing of the past - and frankly if Avalonia did not support it at all, there would be little detriment.

All focus should be on .Net Core moving forward, whether v3.1 or v5.0.

If I were using .Net framework, I'd (un)happily go back to my days of WPF.

[jmacato]

AFAIK the targets for netframework are for Xamarin support and not necessarily a support for the legacy .NET framework. When .NET5 drops then we can happily switch to whatever target .NET5 would be.

[jinyuttt]

So, I don't mean to upgrade to netstandard 2.1, but to NETCORE 3.1 directly

[jmacato]

all of this TFM stuff will be sorted out when .NET 5 is up, so please be patient @jinyuttt :)

[jinyuttt]

Half a year has passed. When will 1.0 be released?

[kekekeks]

We are most likely do the React thing at some point and switch from 0.X.Y numbering to X.Y.Z numbering while keeping the X number.

The overall quality of the product was sufficient for "1.0" for quite a while, but there are known areas with inevitable breaking API changes in the future.

Changing the major number from zero will require us to implement more strict API review process and keep more obsolete APIs for compatibility, so breaking changes will only occur when absolutely inevitable.

All of that requires automatic tooling that I hope to get going in 0.10-0.11 timeframe.

[HTG-YT]

Any plans for .NET 5 support?

[kekekeks]

.NET 5 should work with 0.9 out of the box. Window background blur effect from 0.10 isn't yet supported with .NET 5 on Windows

[NHodgesVFX]

I was wondering what the current state is for mobile platforms and when they might be finished? Thanks for the work on avalonia.

[kekekeks]

I was wondering what the current state is for mobile platforms and when they might be finished?

0.11, next year

[danwalmsley]

@NHodgesVFX there is active work happening on iOS.

[MichalSy]

.NET 5 should work with 0.9 out of the box. Window background blur effect from 0.10 isn't yet supported with .NET 5 on Windows

Unfortunately I can't get a project running with dotnet 5.0:
Avalonia.ReactiveUI 0.10.0-preview6 is not compatible with dotnet (.NETPlatform,Version=v5.0).
Package Avalonia.ReactiveUI 0.10.0-preview6 supports: netstandard2.0 (.NETStandard,Version=v2.0)

What do I have to do to use dotnet 5.0?

[danwalmsley]

this is fixed on master... you can either use a nightly build i.e. 0.10.999-cibuild0011763-beta

Or simply for now add a package reference to System.Reactive 5.0.0