I wish they support Linux wholeheartedly, a lot of toolkits and GUI frameworks do it by half-assing things, mostly because Wayland is difficult to understand.<p>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:<p><pre><code> - XDG Top Level Window
- Child Window
- Popup Surface
- Layer surface (like task-bars, shell overlays)
- Subsurface (region in another surface)
- IME Panel Surface (surface that follows text cursor)
</code></pre>
There probably is others too.<p>It is diffifcult to find high-level toolkits that support all of the above.
For everyone interested in Avalonia's Linux / Wayland strategy:<p><a href="https://avaloniaui.net/blog/bringing-wayland-support-to-avalonia" rel="nofollow">https://avaloniaui.net/blog/bringing-wayland-support-to-aval...</a>
Why is Wayland so complicated? I thought half the reason for breaking with X11 was to produce a simpler window server. I was flabbergasted when I realized that there were competing compositors for seemingly no benefit to anyone.
Not to mention that there's no clear documentation for this anywhere. A while ago I was attempting to debug some Wayland-specific issues with a graphics library, it turns out the issue was that the little documentation there was, was wrong about what is and isn't nullable.
In X11 we kept things simple by offering:<p>* Core protocol drawing (lines, rectangles, arcs, the classics)<p>* XRender for compositing and alpha<p>* XShm for shared-memory blits<p>* GLX if you felt like bringing a GPU to a 2D fight<p>* XVideo for overlay video paths<p>* Pixmaps vs Windows, because why have one drawable when you can have two subtly different ones<p>* And of course, indirect rendering over the network if you enjoy latency as a design constraint
Wayland is a mess.<p>Perhaps <a href="https://github.com/X11Libre/xserver" rel="nofollow">https://github.com/X11Libre/xserver</a> 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.
What does “nobody writes for Wayland” mean?<p>If you write software using GTK, Qt, or FLTK then you are writing Wayland software.<p>The majority of Linux desktops are Wayland at this point. Nobody writes software for them?<p>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.<p>What percentage of Linux desktop users are not using one of the above? 10 at most?
> If you write software using GTK, Qt, or FLTK then you are writing Wayland software.<p>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).
It just means "noone" uses the wayland APIs directly, but instead they leave the wayland complexity to GTK,Qt or FLTK, and they call their app a Qt app, not a Wayland app.
Then in that case, the point is moot, as a similar version of "no one" uses the X11 APIs directly anymore, either.
Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.
It was/is mostly the same practice <i>except</i> for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use.<p>Also certain types of power tools for mac probably need use Quartz directly as well.
> <i>Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly.</i><p>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.<p>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.<p>And even then, libwayland-client has a much lower number of <i>concepts</i> 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.
Having written a new gtk program recently I had to implement Wayland and X -isms in the code. Off the top of my head X prefers using W_Class and Wayland prefers app-id with each window having a role set. Both are fine. I honestly think Wayland is nicer but realistically you code for both. To get a global hot key you register it with the compositor and it works. But you can run a background daemon to catch all keys if you really want.
It means that Wayland is the worst and most idiotic graphics API ever conceived. Talking to Wayland's "asynchronous object oriented protocol" directly is a fucking disaster [1]. Secondary and partly duplicated infrastructure in form of a dbus infested maze of "Desktop-Portals" is necessary to do things as simple as taking screenshots.<p>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.<p>1.: <a href="https://www.p4m.dev/posts/29/index.html" rel="nofollow">https://www.p4m.dev/posts/29/index.html</a>
Wayland isn't really a graphics API, it's just a protocol for clients to communicate with the compositor. Sure, there's a lot of boilerplate to get a window on the screen, but you also aren't supposed to use it directly if you want something super simple. It's really meant to be a low level interface for toolkits to be built on top of. Here are two disagreements I have with the linked article:<p>1. Comparison with raylib<p>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.<p>2. Wayland is littered with callbacks because it's an object oriented protocol<p>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.<p>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.<p>(edit for better formatting)
Once you set permissions the screenshot taking program always has them and you don't have to do grants more than once.
You have to go quite out of your way to not use Wayland. Pretty much all mainstream distros switched over long ago. This just feels like the systemd drama restarted. Some will complain and hold on to the past for as long as they can but the rest of the world moves on. Wayland is the better choice today.
I think Wayland is basically waiting for a higher level abstraction to fully replace X11, at least for the desktop. I'm currently playing with the River Wayland compositor (<a href="https://codeberg.org/river/river" rel="nofollow">https://codeberg.org/river/river</a>) which separates the window manager from the compositor and I think it could fill this gap left in the transition. Not as sure about non-toolkit (gtk,qt) application development...
Things like this remind me how much I love open source software. Choice is amazing shout out to all the contributors!
From a quick look, I can't find a reason. <i>why?</i> Even MS doesn't fully believe in Maui, as it seems they reblessed WPF. For Avalonia to do the work of MS seems weird, their own free regular WPF-like Avalonia UI toolkit is already the standard for cross desktop development.<p>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.<p>But since these people aren't idiots, I gladly assume I am missing something.
Between MAUI and Avalonia, Avalonia is the superior framework when it comes to technical quality as well as community response. What Avalonia doesn't have is the enterprise component libraries MAUI has. As part of this move Avalonia is about to reel in these libraries, as well as a whole bunch of MAUI teams.<p>In other words; Avalonia is coming for MAUIs turf.
> But since these people aren't idiots, I gladly assume I am missing something.<p>Microsoft politics. Someone who’s aware please confirm but I want to say it’s something like…<p>Different orgs jockey for power and you can see when the wrong orgs and initiatives influence different products.<p>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.<p>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.<p>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.<p>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.<p>I imagine the UX and .NET
orgs are caught in similar political battles; but without any direct income or product to influence.<p>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).
I agree that MS has often internal conflicts of interest. But that still leaves su with the question: why would Avalalonia do the work that MS did not bother to do, where is the benefit? I mean, Avalonia has AvaloniaUI already.
> Even MS doesn't fully believe in Maui<p>Source: I made it up.
MS doesn't believe in any of their toolkits, and the source is their actions. First off, they're addicting to introducing new toolkits instead of improving existing ones. But that doesn't even matter, because they just use Electron anyway.
MS has multiple personalities, so some might do, I will give you that. Meanwhile, WPF is getting rehabilitated. It seems like that not only the average developer has concluded that all the other UI frameworks since wpf are half-baked. Someone more involved than me makes the same assessment: <a href="https://news.ycombinator.com/item?id=47480056">https://news.ycombinator.com/item?id=47480056</a><p>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.
How many MS products are dog fooding Maui?<p>When COM rolled out, every product was very much on board.<p>The need for Maui in-house is for…what?
doesn't look like much; the seem to use electron for almost everything in this space. If they had faith in Maui something (VS Code, Teams, Outlook, ... calculator?) would use it.
Some of us have insider connections
<i>Accessibility bridging between .NET MAUI and Avalonia is currently limited.</i><p>Nowhere near production ready, got it.
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.<p>We don’t expect this to graduate from a preview until November. There’s plenty of time to sort out Accessibility.
Almost nobody needs accessibility; let's be realistic, it's obviously not a priority. The priority is to put this out the door (MVP style).
Unfortunately too many developers share your perspective. I'd be surprised if anyone building commercial software would move ahead without accessibility support though because, 1. it's required by law in many situations, and 2. it makes good business sense.
this was down voted but its correct. even if as a human j disagree and it sounds mean, this is how people think in general..too bad, but too true. accessibility will come after 'launch'.
If they mean "only a small subset of your users need accessibility support" this might be true, but I haven't worked for a organization selling software in the past 20+ years that hasn't needed to provide support, and those orgs are the audience for a .net cross-platform UI solution, so in that case they are wrong; almost everyone "needs accessibility support".
Accessibility isn't a binary, though. Without any level of accessibility, your software is innaccesible/unusable and your MVP is DBA.
The rewrite from Xamarin.Forms into MAUI, has given a bad taste to many in the community, and kudos to Avalonia to make it happen on GNU/Linux.<p>By the way on macOS MAUI uses Catalyst as backend, not native macOS APIs.<p>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.
> By the way on macOS MAUI uses Catalyst as backend, not native macOS APIs.<p>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.
What is unclear to me, is how does it work with Avalonia pricing wise? If I am having commercial application for Windows, Android, MacOS, iOS (Microsoft MAUI range) then according to [1] I would need to dish out 125000 EUR per application. But it was never clear to me what are the conditions which actually triggers the difference between free and paid plan.<p>[1] <a href="https://avaloniaui.net/xpf/pricing" rel="nofollow">https://avaloniaui.net/xpf/pricing</a>
Let me rephrase what sibling said: the paid offering is for you when you have gotten an existing traditional windows-only wpf application and you want to have that appplication cross-platform <i>as-is</i>, foregoing any effort to port it to AvaloniaUI.<p>You won't need the paid offering if you build your stuff in AvaloniaUI directly.
Avalonia is free and open-source. Avalonia MAUI currently appears to be MIT as well [0]. The pricing you’ve linked to is pricing for their paid offering, which wraps Avalonia and a WPF-style API for easy migration of legacy apps.<p>[0] <a href="https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/main/LICENSE" rel="nofollow">https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/ma...</a>
Maui was on Linux the whole time :-P<p><a href="https://mauikit.org/" rel="nofollow">https://mauikit.org/</a>
Nice, I love MAUI but hate that it has no support for Linux. The only option I have is Avalonia and Photino. I love .NET but when I want to make a GUI I reach for other languages because Microsoft despite reinventing their .NET GUI stack every few years, they never add Linux support. Personally I prefer to use their built-in stuff as much as possible.
I’ve been using Claude to build native versions of a couple of apps and what was once unthinkable (maintaining multiple code bases) is now fairly trivial. And Electron/Tauri implementations are high quality.<p>I’m not sure platforms like Maui are necessary anymore.<p>I did note the comment “if you don’t want Liquid Glass” as a direct response to GenAI native development.<p>Time will tell.
I like the possibilities this opens up but I'm struggling to understand how wasm is involved. I had the impression it doesn't have a user interface, but it's called by javascript instead.
Excited for this. I do wonder how much effort it will be to get an existing app working with this.
Just a reminder that this MAUI has nothing to do with the pre-existing cross platform UI framework MauiKit from MAUI Project.<p><a href="https://mauikit.org/" rel="nofollow">https://mauikit.org/</a>
Microsoft adding Linux support for yet another framework nobody asked for while WinForms still exists in 2026 is very on brand.
Why would anyone want .NET on Linux?
C# is cross platform, I'd bet money that most .Net services run on Linux these days (Azure runs more Linux VMs than Windows VMs after all) This just fills the client side gap so you can unify the full stack under one language a la node etc
Orgs that have their LOB software written in .NET and want to migrate to Linux without rewriting it. Avalonia's commercial offering is designed to do exactly that.
Hundreds of thousands of .NET applications run inside Linux Docker containers.
My guess would be so that they could make use of a single code base.