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.
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.
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 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.
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.
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.
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.
Nowhere near production ready, got it.
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.
That and studying smithay code.
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 creating Wayland software.
The majority of Linux desktops are Wayland at this point. Nobody writes software for them?
[1] https://avaloniaui.net/xpf/pricing
You won't need the paid offering if you build your stuff in AvaloniaUI directly.
Most import thing to look for are the components you need imho. You can build themselves, but if you can use something ready made, that helps of course. You would best take look at their gallery to see if you see something similar for your needs.
[0] https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/ma...
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.
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.
https://mauikit.org/
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.