This is the first preview release. It’s targeting a preview of .NET 11, which should help you understand that it’s not intended to be used in production right now.
We don’t expect this to graduate from a preview until November. There’s plenty of time to sort out Accessibility.
A question I'm sure you might have been asked before - will this support mobile too? It would be nice if it did. I would certainly like to try it. It does feel like being able to use Avalonia and MAUI in mobile would be extremely beneficial.
We’re actively working on Wayland support for Avalonia 12. While we considered dual licensing it, we ultimately decided to keep things simple and make it MIT licensed.
> [Article] What works in GNOME might not work in KDE. What works in both might not work in Sway.
If you subtract GNOME from the set then things become a lot more sane. "Compositor-specific extensions" are really "everyone besides GNOME extensions." The system tray extension isn't KDE-specific. Sure, window positions might not be available at all (because they don't make sense for a TWM), or a user might not have a system tray bar (or you might be on GNOME). However, if they did have a system tray it would be the StatusNotifierItem protocol. Ideally, these should be handled like other platform features like accelerometers etc.. That may not be possible, either way a lot of them can safely noop.
> [Article] For Avalonia, this means "Wayland support" isn't one implementation, it's potentially dozens. We're not just writing a Wayland backend; we're writing a GNOME-Wayland backend, a KDE-Wayland backend, a Sway-Wayland backend,
If you're making per-WM backends then you've fundamentally misunderstood how extensions are supposed to work. Other Wayland client libraries do not have a independent backends for KDE, Sway, and GNOME. Maybe quirks would be needed because you're attempting to support an existing UI library - but those should be few and far between.
IIRC Avalonia supports Vulkan as a rendering backend? Wayland protocols are the same line of thinking as Vulkan extensions.
wlroot and smithay are good examples of what extensions are used in the real world.
My experience was the same while helping to adapt a Steam Deck game for wider Linux support. The issue wasn't Waylandisms, most of those have already by figured out. It was GNOME. Their preferred resolution to issues seems to be dropping support rather than bug fixes, and they go out of their way to adopt implementations that are against the momentum of the wider community. I can get why they make some of their decisions, but things like killing the tray indicator or server side decorations are insane. To be an outlier in name of a greater or grander goal is one thing, then there is whatever GNOME is doing.
Fwiw on Vulkan or GL it also often makes sense to implement entirely different code paths for different *sets* of supported extensions, instead of handling all possible extension combinations in a single code path (which leads to messy code and a combinatorial explosion of test cases, since each unique extension might theoretically be supported or unsupported independently from all other extensions - but you need to test each combination).
The whole idea of granular and independent extensions is pretty stupid across GL, Vulkan and Wayland. It makes more sense to have a handful "tiers" or "profiles" which guarantee a specific set of features (eg how all other 3D APIs do it) - e.g. Wayland should have a "desktop profile" instead of dozens of optional extensions needed for desktop scenarios, other profiles could be "mobile" and "kiosk".
> For Avalonia, this means "Wayland support" isn't one implementation, it's potentially dozens. We're not just writing a Wayland backend; we're writing a GNOME-Wayland backend, a KDE-Wayland backend, a Sway-Wayland backend, and so on.
What? No, that's not the case. Yes, different Wayland compositors often support different extensions, but everyone has the basics (Wayland core, xdg_shell, and probably a few others). You need one backend, and then you can support extensions to implement more advanced features, but you of course have to be able to continue to work without any extensions present.
Yes, there are some features that might require a different extension on GNOME than it does on KDE (for example), but you don't need a full "backend" to handle those differences.
As someone who has always been skeptical of Wayland, frustrated with its shortcomings, and who has written both a compositor and XEMBED-workalike library for Wayland, it just feels like author is trying to play up the difficulties for PR purposes here.
> there are some features that might require a different extension on GNOME than it does on KDE
More likely you have to use a GNOME Extension (as in the plugin, not a wayland extension), or maybe a gnome-specific, possibly undocumented D-bus protocol.
To name a few: Schneider Electric, JetBrains, GitHub, Datadog, AMD, KLM, Moodys Analytics and tons more.
There’s no catch. The project is OSS (MIT license) and has been since the projects inception over a decade ago. There isn’t a paid version of Avalonia at all, so no gatekeeping of features. We instead generate revenue from support agreements, development services and selling our cross-platform fork of WPF. You can read a little more about it on our blog: https://avaloniaui.net/Blog/balancing-growth-and-sustainabil...
We've been working on making WPF cross-platform, having tackled macOS and Linux first. We recently started work on bringing it to the browser using WASM. If you've any questions, ask!
We don’t expect this to graduate from a preview until November. There’s plenty of time to sort out Accessibility.