Repository navigation
Roadmap (0.10) #2239
Description
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
- Touch input and scroll support
- 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.
Activity
awb99 commentedon Feb 1, 2019
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 commentedon Feb 1, 2019
See #1387 (comment)
npolyak commentedon Dec 8, 2019
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 commentedon Jan 10, 2020
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 commentedon Jan 10, 2020
It should be possible to multi-target
netstandard2.1andnet48, but I'm not sure if that's worth the complications.jinyuttt commentedon May 1, 2020
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 commentedon May 11, 2020
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 commentedon May 11, 2020
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 commentedon May 31, 2020
So, I don't mean to upgrade to netstandard 2.1, but to NETCORE 3.1 directly
jmacato commentedon May 31, 2020
all of this TFM stuff will be sorted out when .NET 5 is up, so please be patient @jinyuttt :)
jinyuttt commentedon Jul 12, 2020
Half a year has passed. When will 1.0 be released?
kekekeks commentedon Jul 12, 2020
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.
HTGAzureX1212 commentedon Nov 12, 2020
Any plans for .NET 5 support?
kekekeks commentedon Nov 12, 2020
.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
24 remaining items
mrmandrake commentedon Nov 11, 2021
really impressive!!!
kekekeks commentedon Nov 11, 2021
@KieranDevvs
We are planning to get WASM support in preview this year. It seems to be 0.10.x compatible (in fact, the demo is running
0.10.10from nuget), so we don't need to wait for the next Avalonia release.romanholidaypancakes commentedon Aug 2, 2022
hi, is the wasm version stable now?
kekekeks commentedon Aug 2, 2022
More or less, yes. You might encounter some problems with shader compilation due to the old Skia version shipped by SkiaSharp, but that doesn't affect most apps
serefarikan commentedon Jan 28, 2023
Hi @kekekeks I found this page by chance, trying to understand where things got to with wasm. Your comment in response to @inaryart sounds positive. Current documentation says
Would you say the documentation is too behind reality now? What would you call its current state?
I'm trying to understand if this is a deployment option that is first class, as other platforms are, or if it is something that is still in incubation phase ? Is there a roadmap or issue I should follow for wasm?
Sorry for all the questions, really excited about the potential of this particular option.
timunie commentedon Jan 28, 2023
If you want to try wasm, use the preview packages. Or even better nightly builds. WASM was improved a lot, but not in current stable release.
Stay tuned for 11.0 release 🙂
serefarikan commentedon Jan 28, 2023
Thanks @timunie , sounds like this is going in the direction I was hoping it would! Do you have any pointers for someone who's trying to wrap their head around how a wasm deployment would work? A sample app, or documentation? I'm especially curious about how jsintrop (briefly mentioned in the documentation I linked above) and calls to rest api endpoints would work.
timunie commentedon Jan 28, 2023
Sorry, I only know some basics about WASM. I know that @wieslawsoltes has several apps online. Maybe you can check out his GitHub repos.
KieranDevvs commentedon Jan 28, 2023
Check out MAUI Blazor in the meantime. That might help you understand certain areas of .NET under WASM until v11 is stable.
npolyak commentedon Jan 29, 2023
People (including myself) are really looking forward to version 11!
Stannieman commentedon Feb 11, 2023
Is there a rough timeline for when version 11 will be finalized? Not asking because I am impatient but because of Caliburn-Micro/Caliburn.Micro#556 (comment)
We'd like to know if we should immediately go for 11 or stick with 10 for the time being.
timunie commentedon Feb 12, 2023
My last information is, that the next preview release may be already a RC-version. So I think v11 hopefully drops soon. But there is no guarantee as always in Open Source software. If you feel confident to use it already in production is up to you. ATM I've two branches of my App, so I can already prepare for v11, but still 0.10 is in the released version used.
[-]Roadmap[/-][+]Roadmap (0.10)[/+]