I was looking for the line: Microsoft sponsored us. Even then I would not understand why they would spend effort on a doomed project. I know Avalonia being a small company has a big task ahead of porting Avalonia UI to Wayland, which makes porting MS semi-abandonware all the more confusing.
But since these people aren't idiots, I gladly assume I am missing something.
In other words; Avalonia is coming for MAUIs turf.
Microsoft politics. Someone who’s aware please confirm but I want to say it’s something like…
Different orgs jockey for power and you can see when the wrong orgs and initiatives influence different products.
What I can’t tell is whether it’s established teams scrambling to stay relevant. Or if it’s new teams and products imposing their influence where they shouldn’t.
But the Windows team doesn’t want to see Linux get traction, so they’ll do their part to hamper any OS shims or any native-first functions in Office.
The Office org wants to expand beyond Windows but for political reasons, the only add-in tech without platform lock-in is JS so they ally with the Azure/Cloud team to allow third parties to create add-ins.
Because of this partnership, rather than making a streamlined add-in store, publishers are required to learn the full complexities of Entra and the Partner centers.
I imagine the UX and .NET orgs are caught in similar political battles; but without any direct income or product to influence.
If I had to guess, they were in the Windows team at one point; but with the platform-independent initiatives (good) it’s been a shitshow over the past 20+ years for desktop developers (bad).
Source: I made it up.
I recommend everyone to ignore all experiments, and go straight for AvaloniaUI, as it is quite similar to wpf, actively devloped and cross-platform. The only downside I see is that Wayland is still in progress yet.
When COM rolled out, every product was very much on board.
The need for Maui in-house is for…what?
Nowhere near production ready, got it.
We don’t expect this to graduate from a preview until November. There’s plenty of time to sort out Accessibility.
accessibility is like implementing braille and things for deaf and colourblind etc.
support is resetting password and helping with accounts etc.
so one is to get a certain category of users to be able to access your site in the general sense. the other (support) is about helping people who already can access your site or service.
or
- larger fonts
- Better contrast controls,
- Non abstract art iconography,
- larger buttons and keyboard navigation,
- understanding that there are many types of colourblindness with different requriements,
- the ability to set lightmode on your app and website due to the issues reading text for anyone with astigmatisms,
- reducing the amount of animation or motion blur
The range of what accessibility is isn't small and some of it is going to be required for the vast majority of products. Also accessibility requirements change over time. eyes and hearing degrade. the desire to waste energy trying to find some stylish button that has no border and almost no contrast to indicate where it is goes away
was there a point you wanted to make or did you just want to elaborate on what accessibility means? im sure google can churn up tons more examples if u need em....
By the way on macOS MAUI uses Catalyst as backend, not native macOS APIs.
Also it is kind of interesting that Miguel de Icaza, nowadays completely switched into Swift ecosystem, and is the responsible for making game development on iPad with Godot a reality. Or porting old .NET ideas of his into Swift.
What does this mean? Mac Catalyst is native. It’s just a thin bridge between iPhone’s UIKit and AppKit on MacOS, which are really the only two divergent frameworks in the entirety of the massive Apple SDK.
So am I understanding correctly that Avalonia, the OSS project, is contributing an AvaloniaUI backend upstream to Microsoft's MAUI library, which is itself OSS? Ergo, someone using MAUI can now use its integrated AvaloniaUI backend to target platforms that were previously not available using MAUI, mainly Linux?
Happy to be corrected if I'm misunderstanding something.
You won't need the paid offering if you build your stuff in AvaloniaUI directly.
Most import thing to look for are the components you need imho. You can build themselves, but if you can use something ready made, that helps of course. You would best take look at their gallery to see if you see something similar for your needs.
[0] https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/ma...
Why? Avalonia is a spiritual successor to WPF but FOSS and cross-platform.
I’m not sure platforms like Maui are necessary anymore.
I did note the comment “if you don’t want Liquid Glass” as a direct response to GenAI native development.
Time will tell.
> Avalonia renders through Skia compiled to WebAssembly
I'd guess it builds on Skia CanvasKit and renders to an HTML Canvas element.
MAUI is Open Source but Microsoft does not provide a Linux back-end. This is a non-Microsoft effort to bring Linux support to MAUI.
In Wayland you have multiple ways to render windows, not just the XDG top level window. It works via surfaces, and here is a list I've discovered so far:
There probably is others too.It is diffifcult to find high-level toolkits that support all of the above.
https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
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.
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.
That and studying smithay code.
* Core protocol drawing (lines, rectangles, arcs, the classics)
* XRender for compositing and alpha
* XShm for shared-memory blits
* GLX if you felt like bringing a GPU to a 2D fight
* XVideo for overlay video paths
* Pixmaps vs Windows, because why have one drawable when you can have two subtly different ones
* And of course, indirect rendering over the network if you enjoy latency as a design constraint
Perhaps https://github.com/X11Libre/xserver can revive the older ecosystem. Almost nobody writes for wayland. About two years ago I tried to switch, then gave up when I realised how many things are missing on wayland. And then I noticed that barely anyone wrote software for wayland. It feels like a corporate advertisement project really. GNOME and KDE push for wayland now.
If you write software using GTK, Qt, or FLTK then you are writing Wayland software.
The majority of Linux desktops are Wayland at this point. Nobody writes software for them?
The Steamdeck uses gamescope which is Wayland. GNOME, COSMIC, Budgie, Niri, and Hyprland are not just Wayland but Wayland only. KDE will be Wayland only soon. Cinnamon is switching to Wayland. XFCE is writing a Wayland compositor.
What percentage of Linux desktop users are not using one of the above? 10 at most?
Why is it so complicated if it's just a common backend? Surely you don't need 1/10th the complexity just to render gnome or kde (never heard of fltk before).
Also certain types of power tools for mac probably need use Quartz directly as well.
Honestly I think this is a pretty fair approximation of "no one". How many people are writing tools like this vs. the number of people writing regular applications? A very small number, I'd say.
And after working extensively with both libX11/libxcb and libwayland-client directly, I can say that none of them are particularly pleasant to work with. Actually, no, that's not true: libwayland-client wins, easily. Every single Wayland protocol has code generated for it that works exactly the same way. I suppose the same is (more or less) true of libxcb, but libX11 (and all the other libraries you might have to use, like libXrender, libXrandr, libXext...) are a complete mess.
And even then, libwayland-client has a much lower number of concepts you have to understand than libxcb does, simply because the Wayland protocol has a small number of concepts you need to understand. libxcb is definitely an improvement over libX11, but it can't magically make all the underlying X11 protocol concepts become unified.
As such it essentially cements the GTK/Qt duopoly. Both are extremely subpar low-quality bloated toolkits that are also responsible for the fact that the Linux desktop is still not a thing in 2026.
1.: https://www.p4m.dev/posts/29/index.html
1. Comparison with raylib
This is imo comparing apples with oranges. Raylib sits at a much higher level than wayland, and it in fact supports using wayland as a backend.
2. Wayland is littered with callbacks because it's an object oriented protocol
It's more due to wayland being an asynchronous protocol. When you send a request to the compositor, chances are that you wont hear back from it immediately. But it's also likely that the app can do other things while waiting for the response. X11 is also in fact an asynchronous protocol, it's just that XLib creates a synchronous API on top of it (and as a result suffers from unnecessary roundtrip delays). In comparison, the newer XCB library is a lot more faithful in terms of preserving the asynchronous nature of the protocol and is used by, for example, Qt's X11 backend and even XLib itself. Of course that also makes it more difficult to use, not unlike libwayland, but the main takeaway here is that you can build a sync API on top of an async one if you wish and not vice versa.
I think some parts of the author's frustration is misplaced because they see libwayland as a toolkit, and in that case yeah it's pretty painful. But I really don't agree with the conclusion that this somehow makes it a bad foundation to build upon. As an analogy, making raw syscalls to the kernel is also painful, but that's why libraries exist.
(edit for better formatting)
You can write a simple Wayland screenshot app with a few hundred lines of code[0], and a compositor that supports the ext-image-capture source and ext-image-copy-capture extensions implemented. (Or the older wlr-screencopy.)
I have plenty of criticism for Wayland and its ecosystem, but if you're going to criticize, don't spread FUD.
(I don't like being the guy who has to assert his credentials, but: I've implemented all three of those screenshot/screencast protocols in a Wayland compositor, just a month or so ago, and know how they work, and what it takes to talk to them from a client.)
Also I read through the link you posted. There's a lot of truth to many of those frustrations, but a lot of it is based on misunderstandings of what Wayland actually is. Yes, most people should be using a toolkit. No, it's not great that the main choices are GTK and Qt. I think there's absolutely room for a mid-level toolkit that lets you do the basics without requiring all the Wayland boilerplate. smithay-client-toolkit is one such effort, and I think it's a good start, though something even higher-level on top of it would be nice.
I also don't get the callback hate. I much prefer registering callbacks over a ginormous switch statement that has to dispatch every event under the sun. Toolkits use callbacks too; does the author hate all toolkits as well? You actually could talk to a Wayland compositor with a big switch statement if you wanted, though you'd need to modify libwayland-client to return events as you iterate its event queue rather than dispatch things to callbacks. That could be a fun project for someone who wanted to make Wayland event handling just like libX11 event handling. (See: just a fundamental misunderstanding of what Wayland is.)
And comparing raylib to libwayland-client is silly; they're fundamentally different things. And you can use raylib to talk to a Wayland compositor. It's just a bad-faith argument.
If you want to compare libwayland-client to something, you have to compare it to libX11 or libxcb. And while yes, getting a simple window on-screen is indeed simpler with libX11/libxcb, doing anything more complicated than that is on par with what you'd end up doing with libwayland-client.
[0] Not counting the protocol code that wayland-scanner will generate for you, because that's like saying you have to count the lines of code in libX11 to write an X11 screenshot app.