forms-gtk-progress
forms-gtk-progress copied to clipboard
jsuarezruiz
Linux support in .NET MAUI
Linux runs on a high diversity of devices of different form factors and possibilities.
.NET MAUI will give official support to Android, iOS, macOS and Windows. The purpose of this issue is to collect feedback to specify possible actions at the community level to review Linux support in .NET MAUI.
Linux support in Xamarin.Forms is achieved thanks to a backend using GTK Sharp 2.12.
Possible options for .NET MAUI:
- Use the Xamarin.Forms backend by updating Handlers and other changes. It could also be upgraded to GTK 3: https://github.com/GtkSharp/GtkSharp
- Reuse as much as possible from the actual GTK 2 Backend and create bindings library for GTK 4?
- Use GTK as a container, but use drawn controls: https://github.com/dotnet/GraphicsControls
- Other? (Add your feedback)
Add your feedback!. What do you think is the best option to add Linux support to .NET MAUI? What would you use it for (Raspberry PI Apps, IoT, Desktop App, etc)?
Thank you very much for considering Linux support on .NET MAUI. It's something that many of us have been asking for for a long time.
My humble opinion is to use the option where Linux support is available as soon as possible. Later, in successive versions of .NET MAUI, other options could be evaluated.
In order to consider MAUI as our UI framework, it is very important to us to be able to reach customers that work with Linux (such as many public organizations, etc). We would mainly use it for our Desktop version of the product. Thank you for opening this path for Linux support.
For me the target platforms I would use would be mostly personal or small apps for Raspberry PI or ChromeOS. As for desktop apps I would use it for Ubuntu mainly for a full blown OS. On a side note what would there be any sort of WSL support. I know there aren't any UI specific supported apps for WSL currently, but WSL is a Linux platform. Having something that is cross platform for WSL would be nice and work well for a developer that is using windows to developer for cross compile and test on WSL. Currently I use Electron for cross compile app that need to be desktop bound. There are some limitations when it comes to USB support and some hardware issues I have run into. Mainly Electron uses libusb which is for Linux only and still working on a way to have true cross platform support.
I think the fastest way to a good solution is to use GTK3 https://github.com/GtkSharp/GtkSharp. This project is what ETO.Forms uses, which I have used to target linux in the past.
It seems like they have plans to support GTK4 https://github.com/GtkSharp/GtkSharp/issues/166
So contributing to that effort going forward would be the most productive way to get to GTK4 support in the future.
Avalonia is the most solid implementation of a xaml-backed GUI running on Linux today. I'd look there for inspiration.
Avalonia manually draws it's controls using skia. This doesn't fit with the ethos of Xamarin.Forms/Maui which is to use native controls on each platform. This gives you a more native look and feel.
Maui currently doesn't have a Skia backend, so using SkiaSharp to do drawing would be quite an extensive exercise, all the controls would have to be drawn from the ground up using primitives.
Maui currently doesn't have a Skia backend, so using SkiaSharp to do drawing would be quite an extensive exercise, all the controls would have to be drawn from the ground up using primitives.
But see the great work being pursued in the linked projects https://github.com/dotnet/GraphicsControls (which depends on https://github.com/dotnet/System.Graphics). Extensive exercise yes, but actually extremely efficient since it's done once for all platforms, and would therefore benefit from combined effort, usage, and contributions.
Even without linux many people are going to want to use this library as soon as it's ready, since the demand for platform-independent rendering is much greater than the demand for platform-specific rendering. Then linux comes for free.
Linux is an important platform among our customers, we believe that including MAUI support for Linux would save a lot of time and effort in the development of cross-platform applications.
Our main target will be Raspbian. Running typically, on Raspberry Pi 4.
Linux is an important platform among our customers, we believe that including MAUI support for Linux would save a lot of time and effort in the development of cross-platform applications.
Your company can hire a professional to only focus on that? Or sponsor an open-source maintainer?
I'm the lead developer on a bunch of stuff at my company that runs on multiple platforms. It's modeling & simulation that has resource-intensive native/local-desktop components. Several of the underlying simulations are command-line dotnetcore/.NET5, with a GUI harness around.
I personally do 95% of my development on Linux, hopping to Windows and Mac mostly to debug platform-specific things that come up. I have users on all three platforms. For me, when looking at creating a new GUI, I need it to have a good Linux development path with deployment options to other OSs. Currently that usually ends up meaning Java.
The GUI options drive architecture decisions; fully supported Linux+Win+Mac GUI in .NET would be a preferred option that opens lots of doors. Non-first-party support for my primary development platforms largely takes it off the table.
I have a preference for things that "look native", but in this day and age, virtually nothing has a consistent "native" look or would even know what an HIG is. Truly clean integration with a decent 3d pipeline [eg an openGL panel] would help a lot but isn't a deal-breaker.
To the question as posed: I don't know about implementation of the GUI framework; only that it should exist, perform adequately, and be receive reliable support+maintenance. Everything else is frosting.
I think GTK is favourable to target, preferrably GTK4 as it's right around the corner. Ubuntu and ChromeOS would be the two platforms I'd like to see things working on. I'll echo most of the sentiment from @chunky.
If projects support packaging in any kind of way, Ubuntu Snaps would be a nice target to have.
@chunky As I've said, without allocating resources to make this happen, hardly this will become true. Companies like your have to invest in projects like this.
Linux does not have a native feel all the desktops "native" looks vary drastically. I think the two main ones would be KDE and GNOME if I had to guess, but there are a lot of other "native" ones out there. I think most likely you would see some form of interface that these UI can maybe share and wire in to use them. If Microsoft plans to support anything would guess it would need to be one of the mainstream first.
I agree that if we need to choose one to start with GNOME/GTK would be the safest route to go. Microsoft already has relationships with Canonical/Ubuntu and GNOME is the default of a lot of distros. I think Redhat and a lot of enterprise distros also have GNOME as default. I believe and please someone correct me if I am wrong that KDE and other UIs can run GTK front end apps without the need for GNOME. I know a while back there was a bug or issue that GTK apps didn't render well in KDE. Not sure if that has been resolved or not, but something to consider that even though it may run in a non GNOME environment there could still be UI issues. I think this is the fundamental problem with supporting Linux in the first place. The only other option is Microsoft roll there own and have it skinned and do some kind of detection to try to match as best as possible, or let the developer configure for GNOME ,KDE, XFCE, MATE, Cinnamon you see the problem.
@knuxbbs It seems to be a possibility, otherwise this issue would not have been opened by @jsuarezruiz. There are some frameworks, like UNO that have worked for a while now in offering a way to work with the same technology addressing different platforms (including web). Performance was quite an issue when we tested this framework but I heard they have improved it since then. Hiring a specialist and mantaining several UI technologies is something we would like to avoid.
@lmartinedreira I thought this issue was more of a "call to action". Anyway, let's see what @jsuarezruiz has to say.
Thank you all for the feedback. For clarifying the expectations or doubts of what is the objective of this issue. In the launch, .NET MAUI will support iOS, Android, Windows, and macOS. Official Linux support could come, but it would be later. My initial objective is to gather information mainly about interest, use and if possible about the expected/desired technological stack. After gathering the information, I would be interested in doing a call to action to get help with some tests (Example: port current backend to GTK3/4, drawn controls etc).
From the feedback received (here and elsewhere), there is interest in Linux. The use is varied between Desktop, Raspberry Pi, etc.
I have some questions, but probably my main question is, would you want a native UI (using GTK Widgets) or, having a native container (GTK window) and drawn controls cover your needs?
To consider, doing everything native using GTK 4 for example, requires creating the C# bindings libraries for GTK 4, testing the performance and functionality of the library well and then creating a backend, one Handler for each control. As against, give support with drawn controls requires only the native container with GTK and creating the drawn controls. In effort, there may be a certain similarity but this second option also brings benefits for the rest of the platforms (and even other possible platforms).
GTK4 widgets would be my vote. That's by far the most harmonious. Maybe even better for performance and battery life? (would have to see side by side, but I'm just assuming at this point)
I recognise that Linux support in MAUI is very much a second-tier requirement. With that in mind, the idea of a widget layer that works on all platforms and happens to have a tiny shim to make it work on Linux is actually fairly compelling to me; it's less to support/break/etc. Presumably it also significantly smooths the complexity of a programmer-available drawing canvas because that comes as essentially a freebie. I could think of other benefits [custom theming is also accidentally free, albeit something I probably wouldn't use].
I have a preference for "proper" GTK widgetry for a bunch of reasons [integration, native L&F, accessibility, etc]. But if custom-drawn is the best way to get MAUI to have Linux support, then I wouldn't poo-poo it.
[By way of example of integration woes: Many Linux desktops let you alt-right-click-drag to resize a window, and alt-left-click-drag to move a window. Many tools that bring their own widgetry don't support those shortcuts, and it's an absurdly painful paper cut every time].
Use GTK4 as a container, but use drawn controls: https://github.com/dotnet/GraphicsControls
Using drawn controls would make linux the only Maui platform to not use native controls.
Who cares? Any concept of "native look and feel" on Linux is a charade anyway.
Yes for Linux, but only in the context of supporting a Blazor PWA running native with however Mobile Blazor Bindings is folding into .Net 6.
My two cents: I am a native desktop linux user, and I am also blind/screenreader user. Supporting gtk3 (maybe 4?) native controls is better for accessibility, because gtk is and always was the most accessible thing on linux, compared only to win32 apps on windows side and winforms apps. I believe people using wpf apps with a screenreader find wpf less natural (although that doesn't mean inaccessible). I hope gtk4 does not break accessibility once and for all, but it's another thing and unrelated to that discussion. If you would do all custom and just use gtk for the top level window, you would increase the complexity of your work very much, and if you add accessibility to the picture, I would be afraid it wouldn't even be included or at least not in first release. On a side note no one mentioned qt here, and I am actually happy of it, because qt is so much cross platform so that it has cross platform accessibility bugs. To all blind/screenreader users, or at least to me, it feels unnatural on every platform. And this does not even improve. There is also the use case of blazor desktop, I would be happy to be able to use it on linux in an accessible way, even if that would be the only thing supported in dotnet6, as an alternative to electron. Of course if that's going to be deferred I'd have to live with it. Not sure if it's going to embed chromium or some other engine, though. Depending of how it's done doing it wrongly may break accessibility for linux users, for example webkit is not so nice in some respects. Note avalonia (not sure about uno but possibly applies too) is not an alternative to me. I not only don't have any first party xplat ui I could use nowadays on dotnet, but I don't even have a third party alternative, with exception of per platform ui libs like gtk#. And of course with exception of pure web apps or blazor electron apps.
Thank you all for the feedback. For clarifying the expectations or doubts of what is the objective of this issue. In the launch, .NET MAUI will support iOS, Android, Windows, and macOS. Official Linux support could come, but it would be later. My initial objective is to gather information mainly about interest, use and if possible about the expected/desired technological stack. After gathering the information, I would be interested in doing a call to action to get help with some tests (Example: port current backend to GTK3/4, drawn controls etc).
From the feedback received (here and elsewhere), there is interest in Linux. The use is varied between Desktop, Raspberry Pi, etc.
I have some questions, but probably my main question is, would you want a native UI (using GTK Widgets) or, having a native container (GTK window) and drawn controls cover your needs?
To consider, doing everything native using GTK 4 for example, requires creating the C# bindings libraries for GTK 4, testing the performance and functionality of the library well and then creating a backend, one Handler for each control. As against, give support with drawn controls requires only the native container with GTK and creating the drawn controls. In effort, there may be a certain similarity but this second option also brings benefits for the rest of the platforms (and even other possible platforms).
Just use GTK and drawn controls.
I don't think GTK toplevel with drawn controls makes sense. Neither does coupling anything to do with MAUI to blazor, which has its own life expectancy concerns. 😆
Native GTK4 makes the most sense.
If you do drawn controls, can you guarantee the following:
- Accessibility - Will blind people be able to use it?
- Platform theme support - if I change my GTK theme will the app adjust
With GTK you are going to get these for free.
With drawn controls and a community supported project, potentially only a few people working in there own time with no help from Microsoft. I don't think you can be sure these will happen.
We can achieve accessibility support with drawn controls. Similarly, can have RTL support, adapt to system theme changes (light, dark), etc. But, if drawing controls are used, there would be native elements (Window etc) but, GTK themes would not work in the drawn controls.
As someone who uses a GTK theme, it would be frustrating to not have that support. On top of all the other missed benefits if this was done using drawing.
It just seems like a workaround to do drawing. Even down to the impact on battery life by refusing to just use what the system already has natively.
Like, haven't we been down this road enough on other platforms to avoid repeating the same mistakes?
Developers would be frustrated if their app looks different in Linux from what the developer intended.
