11.1.0-beta2

[maxkatz6]

Full Changelog: 11.1.0-beta1...11.1.0-beta2
API Diff for 11.1.0-beta2: https://gist.github.com/maxkatz6/9feb6029ef9a412fdab64ded4d7e2033
API Diff for 11.1.0-beta1: https://gist.github.com/maxkatz6/a7df42607cc7187b94e2e693ccf15f6d
NuGet: https://www.nuget.org/packages/Avalonia/11.1.0-beta2

Most of new features are still pending updated documentation.
You can follow progress on this issue - AvaloniaUI/avalonia-docs#384.

Continuing https://github.com/AvaloniaUI/Avalonia/releases/tag/11.1.0-beta1

New features

• New converters: ObjectConverters.Equal and ObjectConverters.NotEqual
• New ActivationKind.File with FileActivatedEventArgs.
• Avalonia is now compatible with SkiaSharp 3.0, see SkiaSharp 3.0 support #15503

Controls changes:

• DataGrid now supports basic automation integration.
• New ToolTip APIs: BetweenShowDelay, ServiceEnabled and ShowOnDisabled.
• ComboBox.SelectionBoxItemTemplate to redefine template of the selected content.
• TransitioningContentControl.TransitionCompleted event allowing to release any resources associated with the previous content.
• Window.SortWindowsByZOrder sorting input windows by their ZOrder.

New platform features

Linux

• New X11PlatformOptions.UseRetainedFramebuffer

Browser

• BrowserPlatformOptions now includes BrowserRenderingMode with possible values: WebGL2, WebGL1, Software2D

iOS

• It's now possible to override CreateAppBuilder.
• Various improvements in Mouse/Physical Keyboard handling.

Android

• AvaloniaActivity base class extracted from AvaloniaMainActivity.
• It's now possible to override CreateAppBuilder.

Tizen

• It's now possible to override CreateAppBuilder.

LinuxFramebuffer

• New LibInputBackendOptions and FbDevOutputOptions.

VNC

• VNC now supports wider set of clients and password protection.

This release also includes bug fixes, performance improvements and various smaller enhancements.

---

This discussion was created from the release 11.1.0-beta2.

[maxkatz6]

It's the last beta before 11.1 stable, if this release goes well.

[kyuranger]

Btw, what is the difference between SkiaSharp 3.0 and 2.x? It seems to just modify some Api without any performance improvement. But I feel like many people are looking forward to SkiaSharp 3.0.

[maxkatz6]

Biggest difference is in newer Skia (native) version.
SkiaSharp 2.x is based on Google Skia 88 that is couple of years old.
When SkiaSharp 3.0 is based on Google Skia 116.

It might include various bug fixes, potentially support for MacCatalyst+Metal rendering. Mostly stabilization improvements.

You can actually see full list of their changes between 88 and 116:
https://github.com/google/skia/blob/main/RELEASE_NOTES.md#milestone-88

[robloo]

Unless it's something on my end, I'm seeing some unexpected regressions in 11.1-beta2. This is without any detailed testing -- only starting up the app -- so who knows what more is broken. I've reverted back to 11.1-beta1 for continued development.

Do we actually test PRs before they are merged? At least on my end I only read the code and rarely have a chance to actually run it. I think our release process isn't quite robust enough here if stuff isn't actually tested. So, as much as I hate to say it, could we have a sign-off process on PRs where someone other than the author (not necessarily the core team) actually runs the new code and confirms it works as intended BEFORE the PR can be merged?

[maxkatz6]

It depends on the reviewer, presence of unit tests (if there are some, people tend to test less, at least me), area of the code itself and potential impact.
In general, I also want improvements on the release process (which is very different from PRs merging process). And we need to invest more into e2e automated testing, especially on Linux side. But we are not there yet.

Specifically, if you are referring to OnClosing PR, - it was tested by me. But I didn't test it with a combination of TryShutdown after cancelling. Also it seems our unit tests didn't cover this scenario either. And it got regressed. Sign-off wouldn't really help here either.

If you find more regressions, please let us know at least with a minimal issue ticket.

[maxkatz6]

Something like ExtendClientArea should also be e2e tested, as this feature highly depends on the platform code and cannot be simply unit tested.

[robloo]

I'm trying not to mention specific issues here as this was more of a general observation. I've noticed the window breaks recently and in the past the AutoCompleteBox was completely broken in a PR meant to fix it.

These types of issues getting through indicate testing isn't what it needs to be. And I personally am guilty of that in that I only have time to read other PRs, almost never test them myself. Of course I fully test my own submissions though. I wanted to make sure someone is actually testing these things instead of everyone doing what I do -- just reading them.

I think we probably need a few options here:

1. If the PR is obvious (spelling or something) no testing is needed
2. If the PR has unit tests that fully cover the issue being fixed, no extra testing is needed other than the author's testing and the unit tests
3. In all other cases someone other than the author needs to pull the package and actually test the code before it is approved and merged.

This should avoid the obvious regressions that keep slipping through.

[FirehawkV21]

Quick question: How will SkiaSharp 3.0 support work in 11.1? Do I add v3 to the project or is it brought over automatically?

[maxkatz6]

Yes, you need to add v3 to the project.

You also might need to add platform specific packages like:
https://www.nuget.org/packages/SkiaSharp.NativeAssets.Linux/3.0.0-preview.3.1
or
https://www.nuget.org/packages/SkiaSharp.NativeAssets.WebAssembly/3.0.0-preview.3.1

[FirehawkV21]

I see. Thank you!

[BreyerW]

Window.SortWindowsByZOrder sorting input windows by their ZOrder.

Special thanks for this one! :) It will definitely make developing multiplatform controls similar to dockable MDI (multiple documents interface) and multi-windows tools for others much easier