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.
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.
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.
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.
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.
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.
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.
> I never understood the Wayland push and I still don’t.
What happened is basically this:
- X11 was fairly complex, had a lot of dead-weight code, and a whole bunch of fundamental issues that were building up to warrant an "X12" and breaking the core protocols to get fixed.
- Alongside this, at some point in the relatively distant past, the XFree86 implementation (the most used one at the time, which later begat Xorg) was massively fat and did a huge amount of stuff, including driver-level work - think "PCI in userspace".
- Over the years, more and more of the work moved out of the X server and into e.g. the Linux kernel. Drivers, mode setting, input event handling, higher-level input event handling (libinput). Xorg also got a bit cleaner and modularized, making some of the remaining hard bits available in library form (e.g. xkb).
- With almost everything you need for a windowing system now cleanly factored out and no longer in X, trying out a wholly new windowing system suddenly became a tractable problem. This enabled the original Wayland author to attempt it and submit it for others to appraise.
- A lot of the active X and GUI developer liked what they saw and it managed to catch on.
- A lot of the people involved were in fact not naive, and did not ignore the classic "should you iterate or start over" conundrum. Wayland had a fairly strong backward compat story very early on in the form of Xwayland, which was created almost immediately, and convinced a lot of people.
In the end this is a very classic software engineering story. Would it have been possible to iterate X11 toward what Wayland is now in-place? Maybe. Not sure. Would the end result look a lot like Wayland today? Probably, the Wayland design is still quite good and modern.
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.
Not to mention that the complexity of X11 shots through the roof once shared buffers comes into play.
X11 was ok for it's time, but fundamentally it's an really outdated design to solve 80s/90s issues over the network in the way you solved it back then.
It is INCREDIBLY outdated and forces all graphics to flow through a crappy 80s era network protocol even when there is no network. It is the recurrent laryngeal nerve of graphics technology.
If Wayland doesn't need network transparency why do Wayland clients and "server" still communicate through a socket though?
Why not use a much simpler command buffer model like on 3D APIs, and only for actually asynchronous commands (but not simple synchronous getters)?
PS: is io_uring using sockets for its "shared memory ringbuffers"? If not why? Too much overhead? And if there's notable socket overhead, why is Wayland using sockets (since it has to solve a simar problem as io_uring or 3D APIs).
Is it 99% of users? Of the linux (desktop/laptop) users I know, the majority use X-forwarding over ssh at least occasionally, while non-linux (desktop/laptop) also use X-forwarding (this is in an academic context), so while this may be an improvement for a subset of linux (desktop/laptop) users, across the whole linux user base (excluding both Android, which does not use wayland, and embedded, which I understand does use wayland), it's not.
I don't think I have used X-forwarding in the last 10 years unless for checking whether it's still there. Most of the time, it was, and running a browser even on a nearby machine was not a pleasant experience. Running Emacs was less bad, but the only things that actually worked well were probably xlogo and xload.
...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.
and then there are probably as many if not more that notice zero difference at all. and a sizable amount of people who notice things that are BETTER, such as for example actual support for HDR and 10bit, per-screen refresh rates etc
This is what I was thinking when I read this. Wouldn't it just be easier to use GTK (or Qt) everywhere? They are already well supported on every other platform and can look very native the last time I checked.
> Wouldn't it just be easier to use GTK (or Qt) everywhere?
Which of those? GTK apps look alien on KDE desktops, and Qt apps look alien on GNOME desktops. Also, if you only need to create a window with a GL or Vulkan canvas, pulling in an entire UI framework dependency is overkill. There's SDL, GLFW, winit etc etc - but those also don't fix the 'native window chrome' problem in all situations and they all have to work around missing Wayland features. The bare window system functionality (managing windows - including window chrome and positioning(!), clipboard, drag'n'drop, ...) should really be part of the OS APIs (like it is on *every other* desktop operating system). Why does desktop Linux have to do its own thing, and worse (in the sense of: more developer hostile) than other desktop operating systems?
Frankly I don't get your problem or how is it different on any other OS. So your solution to GTK or qt looking alien is to look alien to everyone? Like there is no universe where "GTK doesn't look good, I will go with a custom written vulkan canvas" is a realistic scenario. Especially when all this has been blown way out of proportion when companies happily wrap their web apps into a browser and ship it as their software.
So again, how is it different elsewhere? What about windows, where even their own frameworks look alien because they have 3-4 of them? How is that the fault of Wayland somehow?!
> So your solution to GTK or qt looking alien is to look alien to everyone?
No? Where did I write that? I want my window to look and feel consistent with all other Linux desktop applications, and this is mainly achieved by having common window decorations (a problem that had already been solved by any other desktop operating system in the last 50 years).
> a problem that had already been solved by any other desktop operating system in the last 50 years
I just gave you an example of Windows that by default fails this requirement (see settings vs control panel or what that is called), let alone when you install applications using sorts of different frameworks.
Maybe other OSs solved this, but Windows didn’t - it just kept adding new UI libraries replacing older ones so that old software could still run and look old.
It never worked very well - in the age of bitmaps (and that's not a recent invention) that ultra-dumb pixel pushing simply no longer scales.
We have eons better ways to transport graphical buffers around (also, what about sound? That seems reasonable - but now should the display server also be a sound server?), so building it into such a core protocol just doesn't make sense.
- Modern DX and old Direct Draw games often was a clusterfuck in order to keep them running fast in Windows 8 and up.
- XVideo and overlay video for Windows were 100% the same; green glitches on drawing, blue screens on screnshots et all.
- Same issue in Windows with pixmaps.
- RDP was fine there, even Gnome adopted it. But I prefer 9front's transparency, you don't need to get everything from the host to use it, with 9front you can just get the device you want, you can decouple auth from the GUI and a lot more, even the network and audio devices. Much fetter than X11's remote setups, VNC, RDP and whatnot.
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.
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.
> 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.
Most other Linux projects "just work" without any drama (usually those not originating at Red Hat?). Makes you wonder why Wayland is so special (or maybe it is something special about the Red Hat company culture?).
Sometimes a badly designed system is simply a badly designed system, and the main forces behind Wayland seem to be exceptionally tone deaf and defensive when it comes to feedback both from users and application developers (e.g. there seems to be a general "we know better what's good for you" attitude).
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?
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.
It was/is mostly the same practice except 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.
Also certain types of power tools for mac probably need use Quartz directly as well.
> 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.
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.
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.
And why should we optimize for "how many locs can I write a screenshot tool in"? I would prefer to having 1-2 decent ones that have all the necessary features and call it a day. They can then have a simple API so you can script whatever you want.
Why would I want to add more complexity to a display server?
Creating a window and Vulkan context and receiving input events (e.g. what game-like applications need) is fairly trivial via Xlib but far worse in Wayland. The Xlib API also sucks compared to Win32 or Cocoa, but writing a Wayland client for something as trivial as creating and managing a window is much worse than on any other platform (see: https://www.p4m.dev/posts/29/index.html)
Basic window system functionality really needs to be provided by the OS, not by 3rd-party libraries. And there's no reason why simple things like creating a window should be drastically more code in an OS API than in a wrapper library like SDL.
I actually wrote some stuff directly because I was young, poor and stupid.
First year in uni my windows laptop broke, had to lug around a heavy second hand underpowered ppc powerbook and wrote some application I needed that I didn't want "bloated".
Font handling, shared memory backbuffers, network api, etc.. as I wrote in another comment. It is an API to solve over the wire graphics in the late 80s/early 90s era using idioms of that time, and already by year 2000 the problems (rasterization power) didn't exist nor is it even a suitable API surface (even less so 25 years later).
> If you write software using GTK, Qt, or FLTK then you are writing Wayland software.
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 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.
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.
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:
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.
I agree the portals thing is a horrid mess, but you don't need them to take a screenshot unless you're a sandboxed application. Which is probably a good thing.
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.
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.
The MATE DE is fairly popular among the small (not so small in India) but growing (thanks to Windows 11 no doubt) Linux desktop market, isn't it? They strive for Wayland compatibility, but aren't quite there (such I take from their release notes; I myself use an ancient version of Ubuntu/Mate here, right now).
I'm not all that informed regarding Waylands benefits and shortcomings (just being puzzled when "performance" or "overhead" is quoted as reason to move away from X11, remembering that the latter didn't seem unbearable slow 30 years ago and that performance of computers in general and computer graphics in particular increased manifold since then). There are however some who should know, who don't seem all that excited: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...
> You have to go quite out of your way to not use Wayland. Pretty much all mainstream distros switched over long ago.
Whether you use Wayland or not depends on what DE/Window Manager/Session Manager you are using and not what distro.
Cinnamon, XFCE don't really work with Wayland. Cinnamon just hangs on my system, and I don't believe XFCE even support. I am on Debian 13, so things may have changed on the latest versions.
Making Gnome using X was as simple as disabling Wayland. A one line change in GDM config somewhere and restart the session manager.
> 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.
That because a similar things happen fairly regularly in Linux land. It seems every 5 years (or so it seems) There are things that are working perfectly fine, and then someone/some group decided that half of a particular stack needs rewriting/replacing at <large corp> and we go through a rigmarole of bugs, breakage, stability issues.
It isn't people being irrational. It is people not wanting to go through another 5 years of churn on their desktops. If people are happy with something that works fine in their opinion and it is replaced by something else that causes a lot of churn and it isn't substantially better a lot of people are going to be left pissed off about it and thus the drama and resentment.
This also causes issues for other operating systems e.g. BSDs/Solaris forks etc. Their users have to deal with all the Linuxisms.
> Wayland is the better choice today.
The problem is that a lot of stuff still doesn't work properly. I am using a modern AMD card. I get weird hang ups in Chrome/Brave that don't happen in X. Sometimes the windows "stick", other times the whole desktop just locks up. Doesn't happen in X at all. I am a web developer, so this is very annoying.
There is another problem and that is that I don't think Wayland even works on non-Linux *nix like FreeBSD.
The things that Gnome did well with Wayland is things like Different Refresh rates, display scaling etc. That all worked nicely. However the way Gnome works with Games can be a PITA.
When I was using Wayland BTW, I was using it with Gnome 48, GDM on Debian 13. I think they just released Gnome 50. I went to Cinnamon and can't really go back because I updated too many dependencies from back-ports to reinstall Gnome.
> That because a similar things happen fairly regularly in Linux land. It seems every 5 years (or so it seems) There are things that are working perfectly fine, and then someone/some group decided that half of a particular stack needs rewriting/replacing at <large corp> and we go through a rigmarole of bugs, breakage, stability issues.
You are free to use whatever you feel like, no one stops you.
At the same time, you are not free to request for/expect other people's free work in maintaining stuff forever for you. If you want it to continue to work, feel free to step up and maintain Xorg/your DE of choice, whatever.
Also, both systemd and Wayland are just factually better stuff than their predecessors. Not everything is NIH, there are legitimate technological advances we are better off adapting at one point - see git, not managing the complex process of system boot via hacky bash scripts, or package management (we are not yet ready, but nix is the future, all other package management systems are objectively worse).
It is just sometimes in an easier context to be replaced. Display stack is tightly depended on by all kinds of software and no matter how good an interop it has (xwayland), people will always find problems and blame the new tool. The network effect should not be underestimated.
> You are free to use whatever you feel like, no one stops you.
I was merely explaining to the person why people become resentful as they didn't seem to grasp it.
It was neither condoning or condemning the position. Simply why it happens.
> At the same time, you are not free to request for/expect other people's free work in maintaining stuff forever for you. If you want it to continue to work, feel free to step up and maintain Xorg/your DE of choice, whatever.
1) I wasn't doing anything of the sort. I am also allowed to criticise anything I like and for any reason I like. I don't expect anyone to take any notice of it either. Statements such as this is done by people simply to shut people up.
2) You and I both know that isn't possible for the vast majority of people. Further more even if it were, it is basically a second full time job, which most people don't have the time to do.
Therefore I treat statements such as this as disingenuous.
> Also, both systemd and Wayland are just factually better stuff than their predecessors.
So says you. The fact that there is a huge amount of disagreement and discussion over it would suggest otherwise.
All I will say is that. I was using Linux distros way before Wayland and SystemD were even conceived and things worked about as well as they do now, outside of hardware support.
I use Debian 13 that comes with Wayland and SystemD as default. So I don't care what I use, as long as it works.
> Package management (we are not yet ready, but nix is the future, all other package management systems are objectively worse).
Thomas Sowell is often quoted as saying "there are no solutions, only tradeoffs". When people make statements like this, I honestly don't think they fundamentally understand what Engineering is really about. Every solution has a bunch of trade offs.
I don't know much about NixOS, but spending 5 minutes searching there are a bunch of trade offs you have to make when using it. Which means it is at best not objectively better. Not mentioning those makes me think you are a fanboy, and you can never get an honest assessment from fanboy.
> It is just sometimes in an easier context to be replaced. Display stack is tightly depended on by all kinds of software and no matter how good an interop it has (xwayland), people will always find problems and blame the new tool.
People will blame the replacement if it doesn't substantially offer anything new, while introducing news defects and limitations.
That is the issue. Not that they are just curmudgeon. It is a completely rational and correct to be critical of change when the perceived benefit at best marginal.
Sure, but we are talking about desktop OSs which do specify a set of requirements to fulfill, and in that scenario I do believe both systemd and especially nix brings a whole lot of benefits at the price of insignificant/small tradeoffs.
I also agree with you that one should be critical of change, especially change of change's sake. But at the same time it does get old, similarly to when you are surrounded by people still using an FTP server with .V2.4.final.beforeRelease suffices instead of learning git. It took time to make git the default and people naturally resist change. But not always for a good reason.
> Sure, but we are talking about desktop OSs which do specify a set of requirements to fulfill, and in that scenario I do believe both systemd and especially nix brings a whole lot of benefits at the price of insignificant/small tradeoffs.
I can buy SystemD as it IIRC it ties into the whole Desktop spec that most DEs use now.
NixOS and general discussions about packaging is IMO is bikeshedding. Most of the distros these days have reasonably decent packaging systems and are "good enough". I don't need my desktop OS configuration to be declared in a configuration file somewhere. It is unnecessary. In other contexts, I think it is probably really useful.
> I also agree with you that one should be critical of change, especially change of change's sake. But at the same time it does get old, similarly to when you are surrounded by people still using an FTP server with .V2.4.final.beforeRelease suffices instead of learning git. It took time to make git the default and people naturally resist change. But not always for a good reason.
Equating people not using Source control to those that are isn't a valid analogy.
A more valid analogy would be more like someone wondering why they should use Git when they are perfectly happy with SVN. If SVN is working fine for you and your team, why would you wish to move to git?
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 (https://codeberg.org/river/river) 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...
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.
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.
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.
In other words; Avalonia is coming for MAUIs turf.
It actually has the enterprise component libraries that WPF has, and those are much more, and still it isn't as if those will magically work on GNU/Linux, due to how Component One, Telerik and co implement them.
> 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).
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.
Step 1: "use Avalonia to run your existing MAUI or WPF applications on any platform!"
Step 2: "now that your devs have seen how good Avalonia is, why not use it in your future projects directly? It's our core business, so we won't do a regular rug-pull like MS"
.NET finally going cross platform (not counting Mono/Xamarin) wasn't only because some folks at Microsoft felt like it, rather a survival decision to get uptake from newer generations, as UNIX/POSIX settled the server room and headless deployments.
Except that outside Windows, .NET is only another option among many.
Add to it the way cloud infrastructure key offerings are based on, and Azure wanting to play against Google and AWS for first place, naturally the Azure team isn't that focused on being known as the Windows only cloud, as it used to be on the early days.
This naturally plays a role in what programming languages they end up adopting.
Parallel to it, note how Microsoft also plays a role in Python based tooling nowadays.
Do you know if the .net team had they authority to make that decision, or did they need the backing from the Azure team to persuade the top leadership?
> Parallel to it, note how Microsoft also plays a role in Python based tooling nowadays.
Yes, I do. I feel MS doesn't even know the distinction between "pragmatic" and "negligent" anymore. The last language they ever should push is that non-typesafe, self undefining, non-optimisable, compute wasting language called Python. I know, shouldn't mention it, programming langues and religion... I am sorry in advance, but I think MS given their PL research accolades should show taste and technical judgement, rather than endless go-with-the-flow pragmatism.
> Do you know if the .net team had they authority to make that decision, or did they need the backing from the Azure team to persuade the top leadership?
It all started with the folks that joined ASP.NET team with a FOSS culture, with Damian Edwards and David Fowley being the driving force of those early .NET Core day, JSON solution format (which ended up being dropped), replacing IIS with Kestrel, and so on. Eventually they got the backing from Scott Hanselmann and Scott Guthrie, both Scotts nowadays enjoy a very high management position.
If you listen to random interviews of them, at known .NET podcasts like .NET Rocks, Coding After Work, Nick Chapsas, and so forth, they often refer the identity crisis of .NET outside Windows and bringing in new generations, as an ongoing issue.
Example, Maddy Montaquilla, the product lead for .NET Aspire, on her Coding After Work interview, from minute 27 until 32:20.
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: https://news.ycombinator.com/item?id=47480056
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.
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.
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.
> 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.
It's still extremely weird. The difference between iOS UIKit and macOS AppKit is extremely small and already designed for 'cross-platform synergy', e.g. serving both macOS and iOS with mostly the same code.
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”
How are any of these divergent between MacOs and iOS? You still link against the same framework, and the code is nearly identical between the two except for occasional differences in the hardware limitations.
Go look at any of Apple’s sample code. Outside of UIKit/Appkit, most of their samples target both platforms simultaneously
OpenGL isn't really supported, it limps along for existing code, nowadays depending on the OS version, it actually has Metal underneath, but not what Metal is capable of doing with the hardware.
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.
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.
It doesn't actually make good business sense to prioritize accessibility. The simple fact that it is required by law is proof: if it was more profitable to bake in accessibility features, then you wouldn't need to require it, companies would do it on their own without being pushed.
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".
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.
> 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
sure, its much more likely even than your examples too...
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....
Sadly accessibility often lands at the bottom of priorities because developers mostly don't care. Yet, it's relatively straight forward to implement in most modern systems if you start building it with that in mind. Similarly, adding i18n to an application as an afterthought requires more effort than if you would have done it from the start.
Accessibility doesn't only mean easing access to your application to people with disabilities. Accessibility makes it also easier for people with temporary or situational impairment to use your software. A simple example that comes to mind is single finger zooming on map applications, where you tap once and then hold-swipe up/down to zoom in/out, which makes it easy to be used with one hand. I know it's difficult to relate to people with permanent disabilities, but we can definitely relate to situational ones where we wish something was easier to use with one hand because the other was busy. Now imagine if it's the only way you can ever use it :-)
Ultimately, it leaves out no one and benefits everyone.
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.
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.
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.
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.
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.
avalonia xpf is xplat wpf runtime on top avalonia, paid. avalonia maui is xplat maui runtime on top avalonia, mit for now. avalonia have they own ui called avaloniaUI also xplat, free.
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/. Looks like what is announced in the article is something different.
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 :(
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.
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.
> 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.
> For some reason employers are weird about non-Microsoft dependencies in the .NET space.
UI toolkits are probably the only space where a third-party vendor can challenge the MS. They can just ask the CTO how many unsupported or badly supported frameworks from Microsoft he or she can name.
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.
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.
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.
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.
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:
There probably is others too.It is diffifcult to find high-level toolkits that support all of the above.
For everyone interested in Avalonia's Linux / Wayland strategy:
https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
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.
Server Side Decorations are a wayland extension though. Its not in the baseline spec.
[dead]
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.
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.
I found https://wayland.app/protocols/ very helpful so far.
That and studying smithay code.
That was the documentation with the incorrect nullability I was referencing.
I doubt there is anything incorrect there. See the note here: https://wayland.freedesktop.org/docs/book/Message_XML.html#a...
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.
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.
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-book.com/
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.
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?
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
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.
> I never understood the Wayland push and I still don’t.
What happened is basically this:
- X11 was fairly complex, had a lot of dead-weight code, and a whole bunch of fundamental issues that were building up to warrant an "X12" and breaking the core protocols to get fixed.
- Alongside this, at some point in the relatively distant past, the XFree86 implementation (the most used one at the time, which later begat Xorg) was massively fat and did a huge amount of stuff, including driver-level work - think "PCI in userspace".
- Over the years, more and more of the work moved out of the X server and into e.g. the Linux kernel. Drivers, mode setting, input event handling, higher-level input event handling (libinput). Xorg also got a bit cleaner and modularized, making some of the remaining hard bits available in library form (e.g. xkb).
- With almost everything you need for a windowing system now cleanly factored out and no longer in X, trying out a wholly new windowing system suddenly became a tractable problem. This enabled the original Wayland author to attempt it and submit it for others to appraise.
- A lot of the active X and GUI developer liked what they saw and it managed to catch on.
- A lot of the people involved were in fact not naive, and did not ignore the classic "should you iterate or start over" conundrum. Wayland had a fairly strong backward compat story very early on in the form of Xwayland, which was created almost immediately, and convinced a lot of people.
In the end this is a very classic software engineering story. Would it have been possible to iterate X11 toward what Wayland is now in-place? Maybe. Not sure. Would the end result look a lot like Wayland today? Probably, the Wayland design is still quite good and modern.
It's a lot like Python 2.x vs. 3.x in the end.
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.
Not to mention that the complexity of X11 shots through the roof once shared buffers comes into play.
X11 was ok for it's time, but fundamentally it's an really outdated design to solve 80s/90s issues over the network in the way you solved it back then.
It is INCREDIBLY outdated and forces all graphics to flow through a crappy 80s era network protocol even when there is no network. It is the recurrent laryngeal nerve of graphics technology.
If Wayland doesn't need network transparency why do Wayland clients and "server" still communicate through a socket though?
Why not use a much simpler command buffer model like on 3D APIs, and only for actually asynchronous commands (but not simple synchronous getters)?
PS: is io_uring using sockets for its "shared memory ringbuffers"? If not why? Too much overhead? And if there's notable socket overhead, why is Wayland using sockets (since it has to solve a simar problem as io_uring or 3D APIs).
It's only using sockets to pass a handle to a buffer though. Sockets are plenty fast, but not moving stuff in the first place can't be beaten.
Is it 99% of users? Of the linux (desktop/laptop) users I know, the majority use X-forwarding over ssh at least occasionally, while non-linux (desktop/laptop) also use X-forwarding (this is in an academic context), so while this may be an improvement for a subset of linux (desktop/laptop) users, across the whole linux user base (excluding both Android, which does not use wayland, and embedded, which I understand does use wayland), it's not.
I don't think I have used X-forwarding in the last 10 years unless for checking whether it's still there. Most of the time, it was, and running a browser even on a nearby machine was not a pleasant experience. Running Emacs was less bad, but the only things that actually worked well were probably xlogo and xload.
X-forwarding isn't used nearly enough to justify it having to be used all the time.
...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.
and then there are probably as many if not more that notice zero difference at all. and a sizable amount of people who notice things that are BETTER, such as for example actual support for HDR and 10bit, per-screen refresh rates etc
I'm pretty sure it simplifies the code a lot.
That doesn't help when the code talking to Wayland becomes much more complicated.
Why would it be more complicated?
Most apps are just using GTK and qt and doesn't even care about their x or Wayland backends.
This is what I was thinking when I read this. Wouldn't it just be easier to use GTK (or Qt) everywhere? They are already well supported on every other platform and can look very native the last time I checked.
> Wouldn't it just be easier to use GTK (or Qt) everywhere?
Which of those? GTK apps look alien on KDE desktops, and Qt apps look alien on GNOME desktops. Also, if you only need to create a window with a GL or Vulkan canvas, pulling in an entire UI framework dependency is overkill. There's SDL, GLFW, winit etc etc - but those also don't fix the 'native window chrome' problem in all situations and they all have to work around missing Wayland features. The bare window system functionality (managing windows - including window chrome and positioning(!), clipboard, drag'n'drop, ...) should really be part of the OS APIs (like it is on *every other* desktop operating system). Why does desktop Linux have to do its own thing, and worse (in the sense of: more developer hostile) than other desktop operating systems?
Frankly I don't get your problem or how is it different on any other OS. So your solution to GTK or qt looking alien is to look alien to everyone? Like there is no universe where "GTK doesn't look good, I will go with a custom written vulkan canvas" is a realistic scenario. Especially when all this has been blown way out of proportion when companies happily wrap their web apps into a browser and ship it as their software.
So again, how is it different elsewhere? What about windows, where even their own frameworks look alien because they have 3-4 of them? How is that the fault of Wayland somehow?!
> So your solution to GTK or qt looking alien is to look alien to everyone?
No? Where did I write that? I want my window to look and feel consistent with all other Linux desktop applications, and this is mainly achieved by having common window decorations (a problem that had already been solved by any other desktop operating system in the last 50 years).
> a problem that had already been solved by any other desktop operating system in the last 50 years
I just gave you an example of Windows that by default fails this requirement (see settings vs control panel or what that is called), let alone when you install applications using sorts of different frameworks.
Maybe other OSs solved this, but Windows didn’t - it just kept adding new UI libraries replacing older ones so that old software could still run and look old.
[dead]
It never worked very well - in the age of bitmaps (and that's not a recent invention) that ultra-dumb pixel pushing simply no longer scales.
We have eons better ways to transport graphical buffers around (also, what about sound? That seems reasonable - but now should the display server also be a sound server?), so building it into such a core protocol just doesn't make sense.
Not very different from Windows:
- Modern DX and old Direct Draw games often was a clusterfuck in order to keep them running fast in Windows 8 and up.
- XVideo and overlay video for Windows were 100% the same; green glitches on drawing, blue screens on screnshots et all.
- Same issue in Windows with pixmaps.
- RDP was fine there, even Gnome adopted it. But I prefer 9front's transparency, you don't need to get everything from the host to use it, with 9front you can just get the device you want, you can decouple auth from the GUI and a lot more, even the network and audio devices. Much fetter than X11's remote setups, VNC, RDP and whatnot.
9front is nice, but I'm not sure how much you'd get out of it without implementing the rest of Plan 9 in the target OS.
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.
> 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.
> 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.
Most other Linux projects "just work" without any drama (usually those not originating at Red Hat?). Makes you wonder why Wayland is so special (or maybe it is something special about the Red Hat company culture?).
Sometimes a badly designed system is simply a badly designed system, and the main forces behind Wayland seem to be exceptionally tone deaf and defensive when it comes to feedback both from users and application developers (e.g. there seems to be a general "we know better what's good for you" attitude).
Wayland introduced unwanted and unnecessary fermentation that even Xorg users will have to suffer from.
Well, bloated just got a whole new meaning! Hopefully the gases are temporary only!
Making each one implement input handling was also a dazzlingly bizarre design choice.
Are they not just using libinput and that's it?
Wayland is a mess.
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.
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?
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.
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 except 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.
Also certain types of power tools for mac probably need use Quartz directly as well.
> 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.
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.
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.
And why should we optimize for "how many locs can I write a screenshot tool in"? I would prefer to having 1-2 decent ones that have all the necessary features and call it a day. They can then have a simple API so you can script whatever you want.
Why would I want to add more complexity to a display server?
Creating a window and Vulkan context and receiving input events (e.g. what game-like applications need) is fairly trivial via Xlib but far worse in Wayland. The Xlib API also sucks compared to Win32 or Cocoa, but writing a Wayland client for something as trivial as creating and managing a window is much worse than on any other platform (see: https://www.p4m.dev/posts/29/index.html)
That's what stuff like SDL meant to abstract away.
Sure, but SDL can also only do so much to plaster over missing or optional Wayland features:
https://wiki.libsdl.org/SDL3/README-wayland
Basic window system functionality really needs to be provided by the OS, not by 3rd-party libraries. And there's no reason why simple things like creating a window should be drastically more code in an OS API than in a wrapper library like SDL.
Then in that case, the point is moot, as a similar version of "no one" uses the X11 APIs directly anymore, either.
No one who loved themselves wrote Xlib apps directly either.
I actually wrote some stuff directly because I was young, poor and stupid.
First year in uni my windows laptop broke, had to lug around a heavy second hand underpowered ppc powerbook and wrote some application I needed that I didn't want "bloated".
Font handling, shared memory backbuffers, network api, etc.. as I wrote in another comment. It is an API to solve over the wire graphics in the late 80s/early 90s era using idioms of that time, and already by year 2000 the problems (rasterization power) didn't exist nor is it even a suitable API surface (even less so 25 years later).
Athena widgets were great! /s
> If you write software using GTK, Qt, or FLTK then you are writing Wayland software.
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 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.
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
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:
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)
Once you set permissions the screenshot taking program always has them and you don't have to do grants more than once.
I agree the portals thing is a horrid mess, but you don't need them to take a screenshot unless you're a sandboxed application. Which is probably a good thing.
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.
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.
The MATE DE is fairly popular among the small (not so small in India) but growing (thanks to Windows 11 no doubt) Linux desktop market, isn't it? They strive for Wayland compatibility, but aren't quite there (such I take from their release notes; I myself use an ancient version of Ubuntu/Mate here, right now).
I'm not all that informed regarding Waylands benefits and shortcomings (just being puzzled when "performance" or "overhead" is quoted as reason to move away from X11, remembering that the latter didn't seem unbearable slow 30 years ago and that performance of computers in general and computer graphics in particular increased manifold since then). There are however some who should know, who don't seem all that excited: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...
You pretty much just have to use an Xfce distro, as I don't think Xfce fully supports Wayland yet.
As I am an Xfce user, I'm happy to wait.
> You have to go quite out of your way to not use Wayland. Pretty much all mainstream distros switched over long ago.
Whether you use Wayland or not depends on what DE/Window Manager/Session Manager you are using and not what distro.
Cinnamon, XFCE don't really work with Wayland. Cinnamon just hangs on my system, and I don't believe XFCE even support. I am on Debian 13, so things may have changed on the latest versions.
Making Gnome using X was as simple as disabling Wayland. A one line change in GDM config somewhere and restart the session manager.
> 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.
That because a similar things happen fairly regularly in Linux land. It seems every 5 years (or so it seems) There are things that are working perfectly fine, and then someone/some group decided that half of a particular stack needs rewriting/replacing at <large corp> and we go through a rigmarole of bugs, breakage, stability issues.
It isn't people being irrational. It is people not wanting to go through another 5 years of churn on their desktops. If people are happy with something that works fine in their opinion and it is replaced by something else that causes a lot of churn and it isn't substantially better a lot of people are going to be left pissed off about it and thus the drama and resentment.
This also causes issues for other operating systems e.g. BSDs/Solaris forks etc. Their users have to deal with all the Linuxisms.
> Wayland is the better choice today.
The problem is that a lot of stuff still doesn't work properly. I am using a modern AMD card. I get weird hang ups in Chrome/Brave that don't happen in X. Sometimes the windows "stick", other times the whole desktop just locks up. Doesn't happen in X at all. I am a web developer, so this is very annoying.
There is another problem and that is that I don't think Wayland even works on non-Linux *nix like FreeBSD.
The things that Gnome did well with Wayland is things like Different Refresh rates, display scaling etc. That all worked nicely. However the way Gnome works with Games can be a PITA.
When I was using Wayland BTW, I was using it with Gnome 48, GDM on Debian 13. I think they just released Gnome 50. I went to Cinnamon and can't really go back because I updated too many dependencies from back-ports to reinstall Gnome.
> That because a similar things happen fairly regularly in Linux land. It seems every 5 years (or so it seems) There are things that are working perfectly fine, and then someone/some group decided that half of a particular stack needs rewriting/replacing at <large corp> and we go through a rigmarole of bugs, breakage, stability issues.
You are free to use whatever you feel like, no one stops you.
At the same time, you are not free to request for/expect other people's free work in maintaining stuff forever for you. If you want it to continue to work, feel free to step up and maintain Xorg/your DE of choice, whatever.
Also, both systemd and Wayland are just factually better stuff than their predecessors. Not everything is NIH, there are legitimate technological advances we are better off adapting at one point - see git, not managing the complex process of system boot via hacky bash scripts, or package management (we are not yet ready, but nix is the future, all other package management systems are objectively worse).
It is just sometimes in an easier context to be replaced. Display stack is tightly depended on by all kinds of software and no matter how good an interop it has (xwayland), people will always find problems and blame the new tool. The network effect should not be underestimated.
> You are free to use whatever you feel like, no one stops you.
I was merely explaining to the person why people become resentful as they didn't seem to grasp it.
It was neither condoning or condemning the position. Simply why it happens.
> At the same time, you are not free to request for/expect other people's free work in maintaining stuff forever for you. If you want it to continue to work, feel free to step up and maintain Xorg/your DE of choice, whatever.
1) I wasn't doing anything of the sort. I am also allowed to criticise anything I like and for any reason I like. I don't expect anyone to take any notice of it either. Statements such as this is done by people simply to shut people up.
2) You and I both know that isn't possible for the vast majority of people. Further more even if it were, it is basically a second full time job, which most people don't have the time to do.
Therefore I treat statements such as this as disingenuous.
> Also, both systemd and Wayland are just factually better stuff than their predecessors.
So says you. The fact that there is a huge amount of disagreement and discussion over it would suggest otherwise.
All I will say is that. I was using Linux distros way before Wayland and SystemD were even conceived and things worked about as well as they do now, outside of hardware support.
I use Debian 13 that comes with Wayland and SystemD as default. So I don't care what I use, as long as it works.
> Package management (we are not yet ready, but nix is the future, all other package management systems are objectively worse).
Thomas Sowell is often quoted as saying "there are no solutions, only tradeoffs". When people make statements like this, I honestly don't think they fundamentally understand what Engineering is really about. Every solution has a bunch of trade offs.
I don't know much about NixOS, but spending 5 minutes searching there are a bunch of trade offs you have to make when using it. Which means it is at best not objectively better. Not mentioning those makes me think you are a fanboy, and you can never get an honest assessment from fanboy.
> It is just sometimes in an easier context to be replaced. Display stack is tightly depended on by all kinds of software and no matter how good an interop it has (xwayland), people will always find problems and blame the new tool.
People will blame the replacement if it doesn't substantially offer anything new, while introducing news defects and limitations.
That is the issue. Not that they are just curmudgeon. It is a completely rational and correct to be critical of change when the perceived benefit at best marginal.
> there are no solutions, only tradeoffs
Sure, but we are talking about desktop OSs which do specify a set of requirements to fulfill, and in that scenario I do believe both systemd and especially nix brings a whole lot of benefits at the price of insignificant/small tradeoffs.
I also agree with you that one should be critical of change, especially change of change's sake. But at the same time it does get old, similarly to when you are surrounded by people still using an FTP server with .V2.4.final.beforeRelease suffices instead of learning git. It took time to make git the default and people naturally resist change. But not always for a good reason.
> Sure, but we are talking about desktop OSs which do specify a set of requirements to fulfill, and in that scenario I do believe both systemd and especially nix brings a whole lot of benefits at the price of insignificant/small tradeoffs.
I can buy SystemD as it IIRC it ties into the whole Desktop spec that most DEs use now.
NixOS and general discussions about packaging is IMO is bikeshedding. Most of the distros these days have reasonably decent packaging systems and are "good enough". I don't need my desktop OS configuration to be declared in a configuration file somewhere. It is unnecessary. In other contexts, I think it is probably really useful.
> I also agree with you that one should be critical of change, especially change of change's sake. But at the same time it does get old, similarly to when you are surrounded by people still using an FTP server with .V2.4.final.beforeRelease suffices instead of learning git. It took time to make git the default and people naturally resist change. But not always for a good reason.
Equating people not using Source control to those that are isn't a valid analogy.
A more valid analogy would be more like someone wondering why they should use Git when they are perfectly happy with SVN. If SVN is working fine for you and your team, why would you wish to move to git?
I'm currently using XFCE on Arch, and have no incentives or motivation to use Wayland at all. I have no issues whatsoever with Xorg.
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 (https://codeberg.org/river/river) 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...
lol, has it ever occoured to you that the ones who ACTUALLY do write software, such as for example KDE, GNOME, actually prefer wayland?
not to mention GTK and Qt, both supporting wayland.
Most software vendors never talked to X directly either. You seem extremely misinformed
Things like this remind me how much I love open source software. Choice is amazing shout out to all the contributors!
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.
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.
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.
In other words; Avalonia is coming for MAUIs turf.
It actually has the enterprise component libraries that WPF has, and those are much more, and still it isn't as if those will magically work on GNU/Linux, due to how Component One, Telerik and co implement them.
> 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).
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.
Step 1: "use Avalonia to run your existing MAUI or WPF applications on any platform!"
Step 2: "now that your devs have seen how good Avalonia is, why not use it in your future projects directly? It's our core business, so we won't do a regular rug-pull like MS"
.NET belongs to DevDiv, which is under Azure and AI.
Notice how many languages DevDiv supports nowadays, see languages dropdown on https://devblogs.microsoft.com.
Thus even .NET has to fight for internal relevance, most Azure contributions to CNCF are in Go and Rust, they even have a "Rust for C#/.NET Developers" (https://microsoft.github.io/rust-for-dotnet-devs/latest) tutorial.
Azure is also mostly doing Azure Linux nowadays, even if Azure Host OS is still Windows based.
Oh god. So .NET is just one of many frameworks/platforms? And competing with Azure for attention? Talk about being dwarfed.
.NET finally going cross platform (not counting Mono/Xamarin) wasn't only because some folks at Microsoft felt like it, rather a survival decision to get uptake from newer generations, as UNIX/POSIX settled the server room and headless deployments.
Except that outside Windows, .NET is only another option among many.
Add to it the way cloud infrastructure key offerings are based on, and Azure wanting to play against Google and AWS for first place, naturally the Azure team isn't that focused on being known as the Windows only cloud, as it used to be on the early days.
This naturally plays a role in what programming languages they end up adopting.
Parallel to it, note how Microsoft also plays a role in Python based tooling nowadays.
> Do you know if the .net team had they authority to make that decision, or did they need the backing from the Azure team to persuade the top leadership?
It all started with the folks that joined ASP.NET team with a FOSS culture, with Damian Edwards and David Fowley being the driving force of those early .NET Core day, JSON solution format (which ended up being dropped), replacing IIS with Kestrel, and so on. Eventually they got the backing from Scott Hanselmann and Scott Guthrie, both Scotts nowadays enjoy a very high management position.
If you listen to random interviews of them, at known .NET podcasts like .NET Rocks, Coding After Work, Nick Chapsas, and so forth, they often refer the identity crisis of .NET outside Windows and bringing in new generations, as an ongoing issue.
Example, Maddy Montaquilla, the product lead for .NET Aspire, on her Coding After Work interview, from minute 27 until 32:20.
https://codingafterwork.com/episodes/26f166e4-0f0f-43d7-8a00...
> Even MS doesn't fully believe in Maui
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: https://news.ycombinator.com/item?id=47480056
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?
When COM rolled out, every product was very much on board.
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.
Actual source (there are many others): https://github.com/dotnet/maui/discussions/29483
Their actions show how much of a shit they don’t give about Maui. Or frankly any of the air biscuits they’ve launched as UI toolkits since winforms
Some of us have insider connections
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.
> 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.
It's still extremely weird. The difference between iOS UIKit and macOS AppKit is extremely small and already designed for 'cross-platform synergy', e.g. serving both macOS and iOS with mostly the same code.
For those who have never heard of catalyst: https://developer.apple.com/documentation/uikit/mac-catalyst
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.
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”
OpenGL and Metal?
The various incantations of AI frameworks that have been introduced throughout the years?
SwiftUI vs UIKit vs AppKit vs Cocoa Touch vs Catalyst?
SceneKit vs RealityKit?
I understand as target platform also the various versions of macOS.
How are any of these divergent between MacOs and iOS? You still link against the same framework, and the code is nearly identical between the two except for occasional differences in the hardware limitations.
Go look at any of Apple’s sample code. Outside of UIKit/Appkit, most of their samples target both platforms simultaneously
OpenGL is still supported, and Metal has been around for 12 years.
Cocoa Touch is just the umbrella term for iOS frameworks including UIKit, and Catalyst also uses UIKit.
OpenGL isn't really supported, it limps along for existing code, nowadays depending on the OS version, it actually has Metal underneath, but not what Metal is capable of doing with the hardware.
Accessibility bridging between .NET MAUI and Avalonia is currently limited.
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.
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.
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.
> 2. it makes good business sense.
What expected ROI are you basing this on? If it made good business sense on its own, it wouldn't be required by law.
It doesn't actually make good business sense to prioritize accessibility. The simple fact that it is required by law is proof: if it was more profitable to bake in accessibility features, then you wouldn't need to require it, companies would do it on their own without being pushed.
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".
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.
> 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
sure, its much more likely even than your examples too...
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....
Sadly accessibility often lands at the bottom of priorities because developers mostly don't care. Yet, it's relatively straight forward to implement in most modern systems if you start building it with that in mind. Similarly, adding i18n to an application as an afterthought requires more effort than if you would have done it from the start.
Accessibility doesn't only mean easing access to your application to people with disabilities. Accessibility makes it also easier for people with temporary or situational impairment to use your software. A simple example that comes to mind is single finger zooming on map applications, where you tap once and then hold-swipe up/down to zoom in/out, which makes it easy to be used with one hand. I know it's difficult to relate to people with permanent disabilities, but we can definitely relate to situational ones where we wish something was easier to use with one hand because the other was busy. Now imagine if it's the only way you can ever use it :-)
Ultimately, it leaves out no one and benefits everyone.
Accessibility isn't a binary, though. Without any level of accessibility, your software is innaccesible/unusable and your MVP is DBA.
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.
Yes, you got it right. Beside Linux target, Avalonia also opens WASM target.
Thank you for confirming!
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
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.
How mature is Avalonia for an universal app? Big 3 desktop plus big 2 mobile?
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.
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/ma...
avalonia xpf is xplat wpf runtime on top avalonia, paid. avalonia maui is xplat maui runtime on top avalonia, mit for now. avalonia have they own ui called avaloniaUI also xplat, free.
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/. Looks like what is announced in the article is something different.
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 :(
MAUI is a Microsoft project, this is not?
Maui was on Linux the whole time :-P
https://mauikit.org/
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.
> 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.
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.
> 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.
> 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.
> For some reason employers are weird about non-Microsoft dependencies in the .NET space.
UI toolkits are probably the only space where a third-party vendor can challenge the MS. They can just ask the CTO how many unsupported or badly supported frameworks from Microsoft he or she can name.
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.
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/
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/
Nor MediaTek's UI framework: https://lpcwiki.miraheze.org/wiki/MediaTek_MAUI
Wonder how would it looks like if we run MAUI over Avalania over Flutter Impeller over browser's WebGPU.
I think that's the trajectory they are on https://avaloniaui.net/blog/avalonia-partners-with-google-s-...
Excited for this. I do wonder how much effort it will be to get an existing app working with this.
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.
Microsoft, please keep your shit out of Linux
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.
This isn't Microsoft. This is an open source project.
.NET has been on Linux for ages.
Microsoft adding Linux support for yet another framework nobody asked for while WinForms still exists in 2026 is very on brand.
Avalonia is not made by Microsoft and is often considered as one of the best way to make desktop app with .NET.
I can understand the confusion, Microsoft also has a framework called MAUI.
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.
The Microsoft MAUI framework is the one being brought to Linux by Avalonia, yes.
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
Hundreds of thousands of .NET applications run inside Linux Docker containers.
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.
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.
My guess would be so that they could make use of a single code base.
At work we have over ten major products written in .NET and running as Linux containers in the Cloud.