Linux support in .NET MAUI

[jsuarezruiz]

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)?

[Suriman]

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.

[lmartinedreira]

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.

[lucasfolino]

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.

[trampster]

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.

[SCLDGit]

Avalonia is the most solid implementation of a xaml-backed GUI running on Linux today. I'd look there for inspiration.

[trampster]

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.

[charlesroddie]

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.

[ADD-Eugenio-Lopez]

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.

[ZeProgFactory]

Our main target will be Raspbian. Running typically, on Raspberry Pi 4.

[knuxbbs]

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?

[chunky]

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.

[atrauzzi]

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.

[knuxbbs]

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

[lucasfolino]

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.

[lmartinedreira]

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

[knuxbbs]

@lmartinedreira I thought this issue was more of a "call to action". Anyway, let's see what @jsuarezruiz has to say.

[jsuarezruiz]

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

[atrauzzi]

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)

[chunky]

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

[saint4eva]

Use GTK4 as a container, but use drawn controls: https://github.com/dotnet/GraphicsControls

[trampster]

Using drawn controls would make linux the only Maui platform to not use native controls.

[SCLDGit]

Who cares? Any concept of "native look and feel" on Linux is a charade anyway.

[RChrisCoble]

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.

[webczat]

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.

[saint4eva]

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.

[atrauzzi]

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.

[trampster]

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.

[jsuarezruiz]

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.

[atrauzzi]

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?

[just1a-person]

Developers would be frustrated if their app looks different in Linux from what the developer intended.

[atrauzzi]

They'll be more frustrated if their application rips through battery life and is slow and unresponsive on devices with weaker CPUs (Chromebook, RPI).

This is a problem you can already observe today when running electron apps. Especially on ARM Chromebooks.

[webczat]

I agree you can achieve accessibility on native drawn controls, however it would have to be worked on, tested and fixed, so I am afraid I'd wait long for that even compared to the maui for linux release date. Of course if it would be done, I have no problem with that. However being able to get it for free, with possibly minor bugs needing to be fixed, is an argument for not using drawn controls, still.

[atrauzzi]

I don't agree with your rationale for compromise. You're basically settling for something that will be a sub-par solution on the basis that you'd want it faster. It's not a solution at that point, it's a half-measure and will likely end up becoming a permanent flaw that nobody will want to revist in the future because "the work is already done".

[webczat]

well. this remains true every other platform support uses native controls, why linux would be an exception to the rule? I am not looking for a compromise, but my experiences show that at least in case of community supported linux port, there is a high risk that accessibility support, in case of drawn controls, will be done either unacceptably late, or not at all. Of course it depends on the amount of work it requires. Not counting qt and gtk on linux (where as I've commented qt is actually consistently broken in that regard on all platforms but at least usable), no one single other cross platform ui supports accessibility on linux, even if it supports it on everything else. With the exception of electron (but even chromium got that support only recently like last year!), and eclipse's swt that uses gtk under the hoot. So, the less work one has to do to make accessibility work, the better it is for us. Not saying it cannot be done othervise. And it won't likely be that bad if, when using drawn controls, you could reuse gtk's own accessibility apis. Anyway, everything has pros and cons and drawn controls don't preclude accessibility, so whatever... I am definitely open to testing this in the future.

[josejavierromo]

It is very interesting to implement a desktop application with Xamarin for Linux. It will be of great help in the development of the Desktop application of the company in which I work. Hope this goes on! Thank you for opening this possibility.

[knuxbbs]

Developers would be frustrated if their app looks different in Linux from what the developer intended.

Off-topic, but I think @itsme-alan refers to this: https://stopthemingmy.app/

About this issue, I think that integrating GtkSharp with MAUI is the way to go. This will require the implementation of handler properties, I guess.

[lucasfolino]

If Microsoft does decide to use GtkSharp will they support and contribute to the project. I would hate to see something that gets backing to change dramatically that causes code to be thrown out, or no support for bug fixes and what not. Microsoft has a level of commitment to make sure the projects they incorporate into their stack should have a similar life cycle or support structure as the project. If Microsoft includes GtkSharp in dotnet6 which is LTS how would that effect my projects support?

What I think may be best path forward is to use GtkSharp in the short team and if that seems to work well for users then see Microsoft roll their own. I think I would rather see complete support and Microsoft technology for cross platform than to rely on third party for something. I could see it being similar to how NewtonSoft JSON was remove from the platform. Start with something internal that has the Interfaces and default to GtkSharp so the plumbing is there, but then roll their own and have us change over if we want or continue using the third party library.

[dag23]

I think it will be great if this is achieved. The numbers of Linux desktop are smaller than Windows sure, but that are a lot of Linux desktop customers that we can reach with our products if Xamarin can render to them.

[jsuarezruiz]

Adding Linux support to GraphicsControls: https://github.com/dotnet/GraphicsControls/pull/17 (First steps, still a lot to implement)

[schmitch]

i would prefer any linux support in maui. it would make the framework more superior because it would be an official solution and might be even a killer for other cross platform applications (at least if it works smoothly) types, mainly the electron ones which are way more memory hungry than maui would be.

[knuxbbs]

Adding Linux support to GraphicsControls: dotnet/GraphicsControls#17 (First steps, still a lot to implement)

Doesn't the current Xamarin.Forms GTK backend uses drawn controls inside a GTK container? So why add another layer over it? Will GraphicsControls replace the current implementation?

Great work, but I expected to see something in .NET 6.

[lucasfolino]

@knuxbbs I think the current Xamraian.Forms relies on an outdated version of GTKSharp which is not dotnet core compatible. I am not 100% sure on that though. I think it is GKT2 or something, and work would need to be done to port it to the newer version of GTKSharp. Someone with more knowledge please comment on clarification.

[trampster]

@lucasfolino that's correct, Xamarin.Forms uses the old mono version of GTKSharp that was abandoned by Xamarin/Microsoft. It only supports GTK2 (the GTK3 support was never finished).

That project was forked by the community into https://github.com/GtkSharp/GtkSharp and the GTK3 support was finished and was ported to .net core and even has nuget packages.

I'm not sure about the exact history but the Xamarin.Forms GTK support seems to have been created after the community fork happened, but for some reason still used the outdated abandoned mono version of GTK#, I've seen some comments that they didn't use GTK3 because of memory leaks, but I think this was them trying to use the unfinished mono GTK3 and not the community version.

Because Xamarin.Forms lacked GTK3 support and dotnet core support it has largely been ignored as unsuitable by the community. And for this same reason cannot be used in .net MAUI.

There where a few other odd things about the Xamarin.Forms GTK support, The official Microsoft documentation described how to use it on windows using Visual Studio, which as far as I can tell no one would want to do. And didn't tell you how to use it on Linux. At the same time Microsoft abandoned MonoDevelop for linux which was up until then the preferred way of creating GTK applications on linux. Leaving only vscode which was geared mainly towards .net core development which Xamarin.Forms GTK didn't support.

[badcel]

Hi,

currently @mjakeman and myself are working over at https://github.com/gircore/gir.core/ at modern GObject bindings.

We started the project because the current UI options on linux are limited for C# Devs and we wanted to support more modern GTK versions.

Our goal is to unify the gobject stack for c# Devs, which includes GTK.

We build directly on GOBject introspection which is well established and used for other language bindings like python and rust.

We are currently pretty much in protyping mode. The public API is manually done at the moment and we are working right now towards more automated code generation.

There are a few Demos available which cover basic GTK, GStreamer and DBus. However the API is in no way complete or stable and gir.core is not viable for serious projects at the moment.

In case you do plan to deliver linux support in a later state of the MAUI project hopefully we have reached a point where gir.core could be an option.

[jsuarezruiz]

@badcel Really interesting project. A quick question, what kind of license will used?

[lytico]

i already did a spike (compiling, but not usable at all) using https://github.com/GtkSharp, just to get a feeling how much afford it would be: https://github.com/lytico/maui/tree/lytico_gtksharp/System.Maui.Platform.GTK this time MAUI was in an early stage without stable api, so i didn't continue. i think this would be the fastest solution in terms of afford and time to release. if https://github.com/gircore/gir.core/ becomes production ready with gtk 4, refactor then to gircore.

[badcel]

@jsuarezruiz it is MIT.

[lytico]

anyway, some .netstandard2 ff compatible Gtk-Library is needed, as https://github.com/dotnet/GraphicsControls depends on Gtk.

[jsuarezruiz]

@lytico Right, for now use Gtk 2.12 but must be updated to Gtk 3 or 4.

[mfkl]

What do you think is the best option to add Linux support to .NET MAUI?

In my opinion, this would be the best option:

• Use the Xamarin.Forms backend by updating Handlers and other changes. It could also be upgraded to GTK 3: https://github.com/GtkSharp/GtkSharp

What would you use it for (Raspberry PI Apps, IoT, Desktop App, etc)?

All of these, for libvlcsharp support.