7 ms·

MAUI Is Coming to Linux

253 points by DeathArrow 7mo ago

Ciantic 7mo ago
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. 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: - 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) There probably is others too. It is diffifcult to find high-level toolkits that support all of the above.
- Pay08 7mo ago
  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.
  - OtomotO 7mo ago
    I found https://wayland.app/protocols/ https://wayland.app/protocols/ very helpful so far. That and studying smithay code.
    - Pay08 7mo ago
      That was the documentation with the incorrect nullability I was referencing.
      - mahkoh 7mo ago
        I doubt there is anything incorrect there. See the note here: https://wayland.freedesktop.org/docs/book/Message_XML.html#allow-nulltrue--false https://wayland.freedesktop.org/docs/book/Message_XML.html#a...
      - kelnos 7mo ago
        wayland.app just HTML-renders the contents of the specification XML files. If a compositor or client is not interpreting nullability the same way wayland.app says it should be interpreted, then that's a bug in the compositor or client.
        Pay08 7mo ago
        What if no compositor is interpreting it correctly? We tested on Weston, GNOME (this was shortly after it went Wayland-only) and Plasma and the same problems persisted on all 3. In all fairness, the exact functions with wrong nullability might have been different, I don't remember, but the nullability issue itself was persistent on all 3.
    - mroche 7mo ago
      What's needed beyond API docs is a review, refresh, and possible merging of the two Wayland Books by active Wayland contributors. https://wayland.freedesktop.org/docs/book/ https://wayland.freedesktop.org/docs/book/ https://wayland-book.com/ https://wayland-book.com/
  - torginus 7mo ago
    This is what I dislike about a lot of open source projects (not all, but a significant amout of the notable ones) - publicly it's proclaimed that the code's open, and you are free to fix bugs and implement your changes. But when you try to do so, you see there's very little documentation and help out in the open, and by the commit history, you can see there's been like three dozen people who have ever contributed to the project. The rate of code change and the obscurity means the knowledge simply does not build up over time. So it's unclear how to fix an issue you've encountered, or add a feature, and if you've done so, how to get your changes merged.
  - pjc50 7mo ago
    Not that I normally support this kind of thing, but.. how are the AI results in this context? Are they bad due to lack of docs?
- audidude 7mo ago
  In X11 we kept things simple by offering: * 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
  - smackeyacky 7mo ago
    And it worked very well for a remarkably long time. Even over dialup if you were patient. It still seems bizarre that the security flaws couldn’t be addressed, I never understood the Wayland push and I still don’t.
    - UltraSane 7mo ago
      Once applications moved local and GPUs became the rendering path X11's network transparency became pure overhead for 99% of users. Wayland fixes this by making shared-memory buffers the core primitive and remote access a separate concern.
      - cindyllm 7mo ago
        [dead]
      - Underphil 7mo ago
        ...and then you have long time Linux users (like me) who cannot feel any of the benefit of removing that overhead. The only difference I can tell between X and Wayland on my machines is that Wayland doesn't work with some stuff.
        UltraSane 7mo ago
        I'm pretty sure it simplifies the code a lot.
- shevy-java 7mo ago
  Wayland is a mess. Perhaps https://github.com/X11Libre/xserver 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.
  - LeFantome 7mo ago
    What does “nobody writes for Wayland” mean? 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?
    - deleted 7mo ago
      [deleted]
    - noselasd 7mo ago
      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.
      - simonh 7mo ago
        Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.
        deleted 7mo ago
        [deleted]
        7mo ago
- sandreas 7mo ago
  For everyone interested in Avalonia's Linux / Wayland strategy: https://avaloniaui.net/blog/bringing-wayland-support-to-avalonia https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
  - MikeCodesDotNET 7mo ago
    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.
    - zamalek 7mo ago
      > [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.
      - a_vanderbilt 7mo ago
        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.
- throwaway27448 7mo ago
  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.
  - endgame 7mo ago
    Making each one implement input handling was also a dazzlingly bizarre design choice.
    - gf000 7mo ago
      Are they not just using libinput and that's it?
  - sho_hn 7mo ago
    > Why is Wayland so complicated? It's not particularly complicated, and certainly a lot simpler and cleaner than X11 in almost every way. The reality of the situation is that there's sort of a hateful half-knowledge mob dynamic around the topic, where people run into a bug, do some online search, run into the existing mob, copy over some of its "arguments" and the whole thing keeps rolling and snowballing. Sometimes this innocent, like OP discovering that UIs are actually non-trivial and there's different types of windows for different things (like in really any production-grade windowing system). So they share their new-found knowledge in the form of a list. Then the mob comes along and goes "look at this! they have a list of things, and it's probably too long!" and then in the next discussion it's "Did you know that Wayland has a LONG LIST OF THINGS?!" and so on and so forth. It's like politics, and it's cyclic. One day the narrative will shift again. The mob will not believe me either, for that matter, but FWIW, I've worked on the Linux desktop for over 20 years, and as the lead developer of KDE Plasma's taskbar and a semi-regular contributor to its window manager, I'm exposed to the complexity of these systems in a way that only relatively few people in the world are. And I'd rather keep the Wayland code than the X11 one, which I wrote a lot of.
    - flohofwoe 7mo ago
- vrighter 7mo ago
  it's not just "difficult to understand". It's that it doesn't allow the functionality the apps need. And you can't have a generic library targeting each wayland compositor implementation separately.
soumyaskartha 7mo ago
Microsoft adding Linux support for yet another framework nobody asked for while WinForms still exists in 2026 is very on brand.
- louhike 7mo ago
  Avalonia is not made by Microsoft and is often considered as one of the best way to make desktop app with .NET.
  - Pay08 7mo ago
    I can understand the confusion, Microsoft also has a framework called MAUI.
    - pie_flavor 7mo ago
      The Microsoft MAUI framework is the one being brought to Linux by Avalonia, yes.
      - deleted 7mo ago
        [deleted]
    - LeFantome 7mo ago
      The MAUI they are talking about is the Microsoft framework you are referencing. 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.
tonyedwardspz 7mo ago
Excited for this. I do wonder how much effort it will be to get an existing app working with this.
general1465 7mo ago
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. [1] https://avaloniaui.net/xpf/pricing https://avaloniaui.net/xpf/pricing
- Kwpolska 7mo ago
  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. [0] https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/main/LICENSE https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/ma...
- exceptione 7mo ago
  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 as-is, foregoing any effort to port it to AvaloniaUI. You won't need the paid offering if you build your stuff in AvaloniaUI directly.
  - oblio 7mo ago
    How mature is Avalonia for an universal app? Big 3 desktop plus big 2 mobile?
    - exceptione 7mo ago
      I can't comment on that specifically, but it works with MVVM extensions toolkit, which is handy for decoupling of event handling and is helpful in complex scenario's. 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.
politelemon 7mo ago
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.
- CodesInChaos 7mo ago
  https://avaloniaui.net/platforms/wasm https://avaloniaui.net/platforms/wasm > Avalonia renders through Skia compiled to WebAssembly I'd guess it builds on Skia CanvasKit and renders to an HTML Canvas element. https://skia.org/docs/user/modules/canvaskit/ https://skia.org/docs/user/modules/canvaskit/
pjmlp 7mo ago
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. 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.
- fingerlocks 7mo ago
  > By the way on macOS MAUI uses Catalyst as backend, not native macOS APIs. 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.
  - throwaway27448 7mo ago
    For those who have never heard of catalyst: https://developer.apple.com/documentation/uikit/mac-catalyst https://developer.apple.com/documentation/uikit/mac-catalyst
  - pjmlp 7mo ago
    It isn't really the same, exactly because of that divergence, and platform differences not covered by Catalyst. Also they aren't the only frameworks that are divergent, although that is another discussion.
    - fingerlocks 7mo ago
      Let’s have that discussion. I’m all ears. Can you name any other pair of frameworks that provide identical functionality, but they are divergent such that each framework is mutually exclusive to its target platform? And no just because the compass is #ifdef’d out when CoreLocation is compiled for MacOs does not count as “divergent”
      - 7mo ago
exceptione 7mo ago
From a quick look, I can't find a reason. why? 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. 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.
- nobodyandproud 7mo ago
  > But since these people aren't idiots, I gladly assume I am missing something. 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).
  - exceptione 7mo ago
    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.
blendergeek 7mo ago
Just a reminder that this MAUI has nothing to do with the pre-existing cross platform UI framework MauiKit from MAUI Project. https://mauikit.org/ https://mauikit.org/
- userbinator 7mo ago
  Nor MediaTek's UI framework: https://lpcwiki.miraheze.org/wiki/MediaTek_MAUI https://lpcwiki.miraheze.org/wiki/MediaTek_MAUI
robin_reala 7mo ago
Accessibility bridging between .NET MAUI and Avalonia is currently limited. Nowhere near production ready, got it.
- siwatanejo 7mo ago
  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).
  - saidnooneever 7mo ago
    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'.
    - skeeter2020 7mo ago
      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".
      - saidnooneever 7mo ago
        provide support on a product and accessibility are really different things. 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.
        tacticus 7mo ago
        > accessibility is like implementing braille and things for deaf and colourblind etc. 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
zteppenwolf 7mo ago
Why would anyone want .NET on Linux?
- jeremycarter 7mo ago
  Hundreds of thousands of .NET applications run inside Linux Docker containers.
- dardeaup 7mo ago
  My guess would be so that they could make use of a single code base.
- orthoxerox 7mo ago
  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.
- drzaiusx11 7mo ago
  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
- DeathArrow 7mo ago
  At work we have over ten major products written in .NET and running as Linux containers in the Cloud.
- bigstrat2003 7mo ago
  Because .net is a good set of libraries, C# is a really nice language to program in, and because having cross platform software under the same code base is a good thing.
giancarlostoro 7mo ago
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.
- Rohansi 7mo ago
  > Personally I prefer to use their built-in stuff as much as possible. Why? Avalonia is a spiritual successor to WPF but FOSS and cross-platform.
  - giancarlostoro 7mo ago
    Drastically less likely to get a rug pull, licensing wouldn't really be an issue for any commercial project, and easy to sell to an employer.
    - Rohansi 7mo ago
      > Drastically less likely to get a rug pull Microsoft's list of abandoned UI libraries says otherwise. > licensing wouldn't really be an issue for any commercial project It's MIT licensed. Simpler for commercial use than Qt. > easy to sell to an employer That's a tough one. For some reason employers are weird about non-Microsoft dependencies in the .NET space. It makes no sense to me personally. They likely aren't nearly as strict for web or mobile apps. But that'll definitely be a dealbreaker if your employer is like that.
      - giancarlostoro 7mo ago
        > That's a tough one. For some reason employers are weird about non-Microsoft dependencies in the .NET space. It makes no sense to me personally. They likely aren't nearly as strict for web or mobile apps. But that'll definitely be a dealbreaker if your employer is like that. We had a vendor go from "this license is fully royalty free" or whatever, to, we need to charge for all devs in your org, to then, for every single user of your app, we want to be paid. Ridiculous. The problem is companies who start getting license cost hungry and wanna squeeze every dollar out of you, when the project you're using it on might not even bring revenue.
ChicagoDave 7mo ago
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. 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.
MrDrMcCoy 7mo ago
Maui was on Linux the whole time :-P https://mauikit.org/ https://mauikit.org/
troad 7mo ago
This is a relatively opaque article for someone who isn't up on dotnet's GUI frameworks. 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.
- DeathArrow 7mo ago
  Yes, you got it right. Beside Linux target, Avalonia also opens WASM target.
  - troad 7mo ago
    Thank you for confirming!
sombragris 7mo ago
I read the title and thought it was odd that the MAUI project "is coming to Linux", because I had it in mind the KDE project with that name, https://mauikit.org/ https://mauikit.org/. Looks like what is announced in the article is something different.
sakesun 7mo ago
Wonder how would it looks like if we run MAUI over Avalania over Flutter Impeller over browser's WebGPU.
- alkonaut 7mo ago
  I think that's the trajectory they are on https://avaloniaui.net/blog/avalonia-partners-with-google-s-flutter-t-eam-to-bring-impeller-rendering-to-net https://avaloniaui.net/blog/avalonia-partners-with-google-s-...
cagz 7mo ago
I am a big fan of MAUI, but I'd really wish they fixed existing issues instead of extending it further. 3.9k open issues and counting. I've got 5 open, verified bugs, some from 2023 :(
- alkonaut 7mo ago
  MAUI is a Microsoft project, this is not?
grougnax 7mo ago
Microsoft, please keep your shit out of Linux
- pjmlp 7mo ago
  Too late, plenty of their shit is already on the Linux kernel, and some of the Rust on Linux kernel contributors are on Microsoft payroll. Just like IBM, Google, Facebook, Oracle and other so beloved FOSS companies.
- alkonaut 7mo ago
  This isn't Microsoft. This is an open source project. .NET has been on Linux for ages.

253 points by DeathArrow 7mo ago

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. 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: - 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) There probably is others too. It is diffifcult to find high-level toolkits that support all of the above.

Pay08 7mo ago
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.
- OtomotO 7mo ago
  I found https://wayland.app/protocols/ https://wayland.app/protocols/ very helpful so far. That and studying smithay code.
  - Pay08 7mo ago
    That was the documentation with the incorrect nullability I was referencing.
    - mahkoh 7mo ago
      I doubt there is anything incorrect there. See the note here: https://wayland.freedesktop.org/docs/book/Message_XML.html#allow-nulltrue--false https://wayland.freedesktop.org/docs/book/Message_XML.html#a...
    - kelnos 7mo ago
      wayland.app just HTML-renders the contents of the specification XML files. If a compositor or client is not interpreting nullability the same way wayland.app says it should be interpreted, then that's a bug in the compositor or client.
      - Pay08 7mo ago
        What if no compositor is interpreting it correctly? We tested on Weston, GNOME (this was shortly after it went Wayland-only) and Plasma and the same problems persisted on all 3. In all fairness, the exact functions with wrong nullability might have been different, I don't remember, but the nullability issue itself was persistent on all 3.
  - mroche 7mo ago
    What's needed beyond API docs is a review, refresh, and possible merging of the two Wayland Books by active Wayland contributors. https://wayland.freedesktop.org/docs/book/ https://wayland.freedesktop.org/docs/book/ https://wayland-book.com/ https://wayland-book.com/
- torginus 7mo ago
  This is what I dislike about a lot of open source projects (not all, but a significant amout of the notable ones) - publicly it's proclaimed that the code's open, and you are free to fix bugs and implement your changes. But when you try to do so, you see there's very little documentation and help out in the open, and by the commit history, you can see there's been like three dozen people who have ever contributed to the project. The rate of code change and the obscurity means the knowledge simply does not build up over time. So it's unclear how to fix an issue you've encountered, or add a feature, and if you've done so, how to get your changes merged.
- pjc50 7mo ago
  Not that I normally support this kind of thing, but.. how are the AI results in this context? Are they bad due to lack of docs?
audidude 7mo ago
In X11 we kept things simple by offering: * 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
- smackeyacky 7mo ago
  And it worked very well for a remarkably long time. Even over dialup if you were patient. It still seems bizarre that the security flaws couldn’t be addressed, I never understood the Wayland push and I still don’t.
  - UltraSane 7mo ago
    Once applications moved local and GPUs became the rendering path X11's network transparency became pure overhead for 99% of users. Wayland fixes this by making shared-memory buffers the core primitive and remote access a separate concern.
    - cindyllm 7mo ago
      [dead]
    - Underphil 7mo ago
      ...and then you have long time Linux users (like me) who cannot feel any of the benefit of removing that overhead. The only difference I can tell between X and Wayland on my machines is that Wayland doesn't work with some stuff.
      - UltraSane 7mo ago
        I'm pretty sure it simplifies the code a lot.
shevy-java 7mo ago
Wayland is a mess. Perhaps https://github.com/X11Libre/xserver 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.
- LeFantome 7mo ago
  What does “nobody writes for Wayland” mean? 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?
  - deleted 7mo ago
    [deleted]
  - noselasd 7mo ago
    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.
    - simonh 7mo ago
      Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.
      - deleted 7mo ago
        [deleted]
      - 7mo ago
sandreas 7mo ago
For everyone interested in Avalonia's Linux / Wayland strategy: https://avaloniaui.net/blog/bringing-wayland-support-to-avalonia https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
- MikeCodesDotNET 7mo ago
  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.
  - zamalek 7mo ago
    > [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.
    - a_vanderbilt 7mo ago
      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.
throwaway27448 7mo ago
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.
- endgame 7mo ago
  Making each one implement input handling was also a dazzlingly bizarre design choice.
  - gf000 7mo ago
    Are they not just using libinput and that's it?
- sho_hn 7mo ago
  > Why is Wayland so complicated? It's not particularly complicated, and certainly a lot simpler and cleaner than X11 in almost every way. The reality of the situation is that there's sort of a hateful half-knowledge mob dynamic around the topic, where people run into a bug, do some online search, run into the existing mob, copy over some of its "arguments" and the whole thing keeps rolling and snowballing. Sometimes this innocent, like OP discovering that UIs are actually non-trivial and there's different types of windows for different things (like in really any production-grade windowing system). So they share their new-found knowledge in the form of a list. Then the mob comes along and goes "look at this! they have a list of things, and it's probably too long!" and then in the next discussion it's "Did you know that Wayland has a LONG LIST OF THINGS?!" and so on and so forth. It's like politics, and it's cyclic. One day the narrative will shift again. The mob will not believe me either, for that matter, but FWIW, I've worked on the Linux desktop for over 20 years, and as the lead developer of KDE Plasma's taskbar and a semi-regular contributor to its window manager, I'm exposed to the complexity of these systems in a way that only relatively few people in the world are. And I'd rather keep the Wayland code than the X11 one, which I wrote a lot of.
  - flohofwoe 7mo ago
vrighter 7mo ago
it's not just "difficult to understand". It's that it doesn't allow the functionality the apps need. And you can't have a generic library targeting each wayland compositor implementation separately.

soumyaskartha 7mo ago

Microsoft adding Linux support for yet another framework nobody asked for while WinForms still exists in 2026 is very on brand.

louhike 7mo ago
Avalonia is not made by Microsoft and is often considered as one of the best way to make desktop app with .NET.
- Pay08 7mo ago
  I can understand the confusion, Microsoft also has a framework called MAUI.
  - pie_flavor 7mo ago
    The Microsoft MAUI framework is the one being brought to Linux by Avalonia, yes.
    - deleted 7mo ago
      [deleted]
  - LeFantome 7mo ago
    The MAUI they are talking about is the Microsoft framework you are referencing. 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.

tonyedwardspz 7mo ago

Excited for this. I do wonder how much effort it will be to get an existing app working with this.

general1465 7mo ago

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. [1] https://avaloniaui.net/xpf/pricing https://avaloniaui.net/xpf/pricing

Kwpolska 7mo ago
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. [0] https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/main/LICENSE https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/ma...
exceptione 7mo ago
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 as-is, foregoing any effort to port it to AvaloniaUI. You won't need the paid offering if you build your stuff in AvaloniaUI directly.
- oblio 7mo ago
  How mature is Avalonia for an universal app? Big 3 desktop plus big 2 mobile?
  - exceptione 7mo ago
    I can't comment on that specifically, but it works with MVVM extensions toolkit, which is handy for decoupling of event handling and is helpful in complex scenario's. 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.

politelemon 7mo ago

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.

CodesInChaos 7mo ago
https://avaloniaui.net/platforms/wasm https://avaloniaui.net/platforms/wasm > Avalonia renders through Skia compiled to WebAssembly I'd guess it builds on Skia CanvasKit and renders to an HTML Canvas element. https://skia.org/docs/user/modules/canvaskit/ https://skia.org/docs/user/modules/canvaskit/

pjmlp 7mo ago

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. 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.

fingerlocks 7mo ago
> By the way on macOS MAUI uses Catalyst as backend, not native macOS APIs. 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.
- throwaway27448 7mo ago
  For those who have never heard of catalyst: https://developer.apple.com/documentation/uikit/mac-catalyst https://developer.apple.com/documentation/uikit/mac-catalyst
- pjmlp 7mo ago
  It isn't really the same, exactly because of that divergence, and platform differences not covered by Catalyst. Also they aren't the only frameworks that are divergent, although that is another discussion.
  - fingerlocks 7mo ago
    Let’s have that discussion. I’m all ears. Can you name any other pair of frameworks that provide identical functionality, but they are divergent such that each framework is mutually exclusive to its target platform? And no just because the compass is #ifdef’d out when CoreLocation is compiled for MacOs does not count as “divergent”
    - 7mo ago

exceptione 7mo ago

From a quick look, I can't find a reason. why? 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. 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.

nobodyandproud 7mo ago
> But since these people aren't idiots, I gladly assume I am missing something. 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).
- exceptione 7mo ago
  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.

blendergeek 7mo ago

Just a reminder that this MAUI has nothing to do with the pre-existing cross platform UI framework MauiKit from MAUI Project. https://mauikit.org/ https://mauikit.org/

userbinator 7mo ago
Nor MediaTek's UI framework: https://lpcwiki.miraheze.org/wiki/MediaTek_MAUI https://lpcwiki.miraheze.org/wiki/MediaTek_MAUI

robin_reala 7mo ago

Accessibility bridging between .NET MAUI and Avalonia is currently limited. Nowhere near production ready, got it.

siwatanejo 7mo ago
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).
- saidnooneever 7mo ago
  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'.
  - skeeter2020 7mo ago
    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".
    - saidnooneever 7mo ago
      provide support on a product and accessibility are really different things. 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.
      - tacticus 7mo ago
        > accessibility is like implementing braille and things for deaf and colourblind etc. 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

zteppenwolf 7mo ago

Why would anyone want .NET on Linux?

jeremycarter 7mo ago
Hundreds of thousands of .NET applications run inside Linux Docker containers.
dardeaup 7mo ago
My guess would be so that they could make use of a single code base.
orthoxerox 7mo ago
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.
drzaiusx11 7mo ago
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
DeathArrow 7mo ago
At work we have over ten major products written in .NET and running as Linux containers in the Cloud.
bigstrat2003 7mo ago
Because .net is a good set of libraries, C# is a really nice language to program in, and because having cross platform software under the same code base is a good thing.

giancarlostoro 7mo ago

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.

Rohansi 7mo ago
> Personally I prefer to use their built-in stuff as much as possible. Why? Avalonia is a spiritual successor to WPF but FOSS and cross-platform.
- giancarlostoro 7mo ago
  Drastically less likely to get a rug pull, licensing wouldn't really be an issue for any commercial project, and easy to sell to an employer.
  - Rohansi 7mo ago
    > Drastically less likely to get a rug pull Microsoft's list of abandoned UI libraries says otherwise. > licensing wouldn't really be an issue for any commercial project It's MIT licensed. Simpler for commercial use than Qt. > easy to sell to an employer That's a tough one. For some reason employers are weird about non-Microsoft dependencies in the .NET space. It makes no sense to me personally. They likely aren't nearly as strict for web or mobile apps. But that'll definitely be a dealbreaker if your employer is like that.
    - giancarlostoro 7mo ago
      > That's a tough one. For some reason employers are weird about non-Microsoft dependencies in the .NET space. It makes no sense to me personally. They likely aren't nearly as strict for web or mobile apps. But that'll definitely be a dealbreaker if your employer is like that. We had a vendor go from "this license is fully royalty free" or whatever, to, we need to charge for all devs in your org, to then, for every single user of your app, we want to be paid. Ridiculous. The problem is companies who start getting license cost hungry and wanna squeeze every dollar out of you, when the project you're using it on might not even bring revenue.

ChicagoDave 7mo ago

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. 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.

MrDrMcCoy 7mo ago

Maui was on Linux the whole time :-P https://mauikit.org/ https://mauikit.org/

troad 7mo ago

This is a relatively opaque article for someone who isn't up on dotnet's GUI frameworks. 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.

DeathArrow 7mo ago
Yes, you got it right. Beside Linux target, Avalonia also opens WASM target.
- troad 7mo ago
  Thank you for confirming!

sombragris 7mo ago

I read the title and thought it was odd that the MAUI project "is coming to Linux", because I had it in mind the KDE project with that name, https://mauikit.org/ https://mauikit.org/. Looks like what is announced in the article is something different.

sakesun 7mo ago

Wonder how would it looks like if we run MAUI over Avalania over Flutter Impeller over browser's WebGPU.

alkonaut 7mo ago
I think that's the trajectory they are on https://avaloniaui.net/blog/avalonia-partners-with-google-s-flutter-t-eam-to-bring-impeller-rendering-to-net https://avaloniaui.net/blog/avalonia-partners-with-google-s-...

cagz 7mo ago

I am a big fan of MAUI, but I'd really wish they fixed existing issues instead of extending it further. 3.9k open issues and counting. I've got 5 open, verified bugs, some from 2023 :(

alkonaut 7mo ago
MAUI is a Microsoft project, this is not?

grougnax 7mo ago

Microsoft, please keep your shit out of Linux

pjmlp 7mo ago
Too late, plenty of their shit is already on the Linux kernel, and some of the Rust on Linux kernel contributors are on Microsoft payroll. Just like IBM, Google, Facebook, Oracle and other so beloved FOSS companies.
alkonaut 7mo ago
This isn't Microsoft. This is an open source project. .NET has been on Linux for ages.