Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux support in .NET MAUI #31

Open
jsuarezruiz opened this issue Mar 1, 2021 · 122 comments
Open

Linux support in .NET MAUI #31

jsuarezruiz opened this issue Mar 1, 2021 · 122 comments

Comments

@jsuarezruiz
Copy link
Owner

jsuarezruiz commented Mar 1, 2021

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:

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
Copy link

Suriman commented Mar 1, 2021

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
Copy link

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
Copy link

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
Copy link

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 GtkSharp/GtkSharp#166

So contributing to that effort going forward would be the most productive way to get to GTK4 support in the future.

@SCLDGit
Copy link

SCLDGit commented Mar 1, 2021

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

@trampster
Copy link

trampster commented Mar 1, 2021

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
Copy link

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
Copy link

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
Copy link
Contributor

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

@knuxbbs
Copy link

knuxbbs commented Mar 2, 2021

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
Copy link

chunky commented Mar 2, 2021

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
Copy link

atrauzzi commented Mar 2, 2021

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
Copy link

knuxbbs commented Mar 2, 2021

@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
Copy link

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
Copy link

lmartinedreira commented Mar 2, 2021

@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
Copy link

knuxbbs commented Mar 2, 2021

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

@jsuarezruiz
Copy link
Owner Author

jsuarezruiz commented Mar 3, 2021

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
Copy link

atrauzzi commented Mar 3, 2021

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
Copy link

chunky commented Mar 3, 2021

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
Copy link

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

@trampster
Copy link

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

@SCLDGit
Copy link

SCLDGit commented Mar 3, 2021 via email

@RChrisCoble
Copy link

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
Copy link

webczat commented Mar 5, 2021

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
Copy link

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
Copy link

atrauzzi commented Mar 5, 2021

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
Copy link

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.

@brunoais
Copy link

brunoais commented Nov 3, 2021

Is battery consumption really that bad for a web browser? It depends on what you put there, of course...

True. However, nearly any framework you put there will be a resource hog. If you stick with straightforward HTML (without overlaps over overlaps like google does with their products and Angular usually does) and <1MB (uncompressed) of CSS and <1MB (uncompressed) of JS (just as a principle to provide an objective value), then the performance should be manageable.
If using web tech, the very important parts are usually summarized to:

  1. Avoid animations but do them with CSS
  2. Don't use useless tags over useless tags. If you can do something with a single HTML tag, don't use 3, 4 or even 7 like google does with their stuff.
  3. Don't generate HTML nor CSS with javascript. In this case, use C# and templates to generate the HTML. Then, for interactivity, you can use javascript to place such blocks of HTML into the DOM tree.

Those are the principles for fast, low power consumption web pages.

It is a managed language, the GC will kill your battery. But it won't.

You have no idea how much longer a phone's battery can last just by running a C++ OS instead of running something heavy such as Android and their apps. I have because I've done tests on that. Think more like 1.7x longer.

@Shadowblitz16
Copy link

Please use native linux controls.
This means supporting gtk2, gtk3/4 and qt.

  • gtk2 is for distros like linux mint which refuse to use modern versions of gtk due to the gnome devs removing theming support in gtk3.
  • gtk3 to 4 is for other gnome distros. you probably only need to support the latest.
  • qt is for distros like kde that use a qt rendering backend.

@lucasfolino
Copy link

How is this not proof that "fragmentation" exists. The least used OS have arguably three mainstream and probably more UI front ends used. If this isn't fragmentation I do not know what is. This is exactly the reason MS wouldn't support because they can't just support one. @Shadowblitz16 how would you feel if MS only supported QT? If you had to choose one which would it be? Ultimately, I would rather see Microsoft have their own front end written from the ground up and have skins/styling to emulate these UIs. This would be the most future proof than just supporting one. With that said this also is a lot of work to do this for an OS that is arguably used less than the current ones supported.

@brunoais
Copy link

brunoais commented Nov 17, 2021

@Shadowblitz16
I think that is too much to ask. At least, at this point.
For now, It'd stick with qt and use container of sorts. I think flatpak is the best choice nowadays.

Then expansion can proceed to other frameworks.

@Shadowblitz16 There's more toolkits than just GTK and Qt.

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 17, 2021

@brunoais

@Shadowblitz16 I think that is too much to ask. At least, at this point. For now, It'd stick with qt and use container of sorts. I think flatpak is the best choice nowadays.

Then expansion can proceed to other frameworks.

@Shadowblitz16 There's more toolkits than just GTK and Qt.

I would guess like 90% of distros out there use qt or gtk rendering backend.
I have yet to see one that doesn't besides serenity os and that not even linux technically.
Can you give examples in which they don't?

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 17, 2021

@lucasfolino

How is this not proof that "fragmentation" exists. The least used OS have arguably three mainstream and probably more UI front ends used. If this isn't fragmentation I do not know what is. This is exactly the reason MS wouldn't support because they can't just support one. @Shadowblitz16 how would you feel if MS only supported QT? If you had to choose one which would it be? Ultimately, I would rather see Microsoft have their own front end written from the ground up and have skins/styling to emulate these UIs. This would be the most future proof than just supporting one. With that said this also is a lot of work to do this for an OS that is arguably used less than the current ones supported.

There is fragmentation but most distros support qt, gtk2 a gtk3 backends.
I mean if eto forms and pure basic forms can do it why can't a billion dollar company?

@trampster
Copy link

trampster commented Nov 17, 2021

Here is a list of cross platform .NET gui tools with linux desktop support.

  • Avalonia
  • Uno
  • Eto.Forms

But please go ahead an tell me why supporting linux desktop is just to hard for Microsoft to do.

Microsoft has more resources then all these put together by orders of magnitude. There are no technical problems preventing .NET Maui from being on linux.

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 17, 2021

Yep eto forms even uses native back ends for linux, mac and windows.
And it doesn't even support qt that i know of.
Its just kubuntu that styles gtk apps to look like it's a qt app.

I just would rather native rendering then uno or avalonia which use custom drawn controls.
Custom drawn controls are fine if you recreate the look and feel of other native tookkits like qt does but its not perfect.

@lucasfolino
Copy link

You have entire companies dedicated to one single problem. No other company supports all the plumbing that is there. I think at this point dotnet may be the largest of frameworks out there. Java is larger with choice, but I am talking about what comes in the box that is provided by one single provider. So if you where to build an app using only MS packages vs Oracle only you would see MS supplies a lot more out of the box. This takes resources, so yes Microsoft has more resources, but they also have a lot higher burden. No single framework supports as much out of the box than dotnet does. No frameworks supports, web, desktops, mobile and other use cases as much as dotnet. This is all provided by Microsoft. Java is close, but it relies on a lot of third party libraries. Let alone thrown in all the tools to support these things.

Microsoft supports 6 languages I can think of. C#, VB, Python, Java, Typescript. F# four of those are all Microsofts burden. Three of those all work with dotnet with no third party additions. You could say IronPython counts too since that is binding for dotnet in python, but it hasn't been updated. You then have the CLR. Which has another language associated with it in IL. You could also say there are WASM binding for dotnet too. This is just the languages. Then you have the dotnet framework itself. It has binding for SQL Server, Entity Framework, DI, web libraries, crypto libraries, desktop libraries, mobile, image libraries, json, xml and the list goes on. I am just throwing stuff out there, but this is ALL provided by MS themselves. Everything I mentioned is MS only other than the the few languages they support in VS. This is your baseline of what MS uses their resources on. Not only is this baseline, but this is all JUST the DOTNET FRAMEWORK. Let alone a slew of other opensource projects, like Typescript, VS Code, and Azure Data Studio to name a few. They are still adding more to the whole thing.

So I would say that a desktop platform for a community that only complains about the company is going to be low on their list of support. Because 1 they don't care, and 2 the Linux community is going to hate it any way. They will just use this as "more proof of embrace, extend, extinguish" because isn't that what MS supporting Linux desktop would look like? It must really be MS trying to just make it so everyone is dependent on them for everything so they can pull the carpet out from under them and finally destroy the cancer that is Linux.

So to summarize. Yes Microsoft has more resources, but they also support a lot more than any other company out there when it comes to developers. I too want Linux support but stop throwing shade at MS. It makes the rest of the community look like a bunch of whiny peasants. If you have something to add to the conversation please add it, but to say MS doesn't have the resource, or know how is just wrong and misinformed.

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 17, 2021

finally destroy the cancer that is Linux.

That right there is the reason why the linux community hates Microsoft.
Microsoft for a long time was trying to kill off its competition.
And while today they are mostly open source, they still use restrictive licenses and put spyware and bloat in their own os and software.

Maybe there is a reason a lot of the linux community hates microsoft.

I think your attitude is why there is only 1 active native cross platform C# gui. Eto.Forms

I think its time Microsoft provided a good cross platform GUI library that doesn't try to (force) its xaml and custom rendering crap onto linux and mac users.

Custom rendering is fine for web and newer versions of windows if microsoft so chooses,
but linux and mac users for the most part want their apps to look and feel like the rest of their OS, and in linux's case support the same theming the rest of the ui does.

Microsoft, Lets stop creating a new ui every 4 years and actually make this one good.

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 18, 2021

Also to answer your questions @lucasfolino

how would you feel if MS only supported QT? If you had to choose one which would it be

I would choose gtk2 since it seems to be the most compatible across all linux distros.
But that's only if we are talking linux.

I would rather see Microsoft have their own front end written from the ground up and have skins/styling to emulate these UIs. This would be the most future proof than just supporting one.

Your going to write a skin for every OS, distro and theme out there?
That sound like much more work then just providing a native backend which does all the work for you.

@sgf
Copy link

sgf commented Dec 23, 2021

The open source community should not use ethics to kidnap each other, so as to provide open source solutions for free.
Open source authors are generally not obligated to provide free services to everyone (to meet everyone's requirements). The problem with Linux is that there is no standard desktop environment, so if you want to develop a unified and compatible UI, it must be a dirty job and a huge workload.

So obviously, if the peoples want it, they should do it themselves.Moreover, the advantage of linux is not in its desktop part.

I support the community in launching such projects like this project.

@larsth
Copy link

larsth commented Jul 30, 2022

Regarding other,
Uno platform uses SkiaSharp: https://platform.uno/how-it-works/

The idea is to paint the widgets.

SkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Google's Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.

Skia's website (not SkiaSharp): https://skia.org/

Mono Project uses Skia (via SkiaSharp) to draw the Win.Forms widgets

This is interesting : https://www.mono-project.com/docs/gui/winforms/#why-not-use-native-widgets
It basically states that using a UI toolkit to implement another UI toolkit is a mistake.

@redradist
Copy link

redradist commented Aug 9, 2022

Regarding other, Uno platform uses SkiaSharp: https://platform.uno/how-it-works/

The idea is to paint the widgets.

SkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Google's Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.

Skia's website (not SkiaSharp): https://skia.org/

Mono Project uses Skia (via SkiaSharp) to draw the Win.Forms widgets

This is interesting : https://www.mono-project.com/docs/gui/winforms/#why-not-use-native-widgets It basically states that using a UI toolkit to implement another UI toolkit is a mistake.

I completely agree with you, my vote for rendering UI using Graphics API like Skia.
Solution to base UI toolkit on platform controls is a mistake, even a new Google approach for drawing is based on Skia (see JetPack)

Why is it bad idea ? Because mistakes done in underlying system will be multiplied on mistakes in .NET MAUI and it will be support hell !!

Also see my issue posted on:
dotnet/Microsoft.Maui.Graphics.Controls#91

@DerbyRussell
Copy link

Finally, I have Maui for GTK working pretty good. I did not want to say anything until I had it working.

Open to the public:
https://github.com/DerbyRussell/maui/tree/derby-gtk3-integration-prism

Check it out!

@DerbyRussell
Copy link

DerbyRussell commented May 3, 2023

My version contains Prism for Maui GTK too:

https://github.com/DerbyRussell/maui/tree/derby-gtk3-integration-prism

@CommonLoon102
Copy link

CommonLoon102 commented May 4, 2023

My version contains Prism for Maui GTK too:

What Prism? This?
https://github.com/PrismLibrary/Prism

@DerbyRussell
Copy link

Yes, that is where I got the source code for Prism. But now works with GTK in my repository

@DerbyRussell
Copy link

Sorry Guys and Gals,
I hadn't tried building my samples in a while. Just updated the code so they are working again.
https://github.com/DerbyRussell/maui/tree/derby-gtk3-integration-prism

The samples are a starting point and absolutely must be working!

@CommonLoon102
Copy link

The samples are a starting point and absolutely must be working!

Sorry for not trying it but just asking because it is quicker:
Does BlazorWebView work as well under Linux via GTK?

@DerbyRussell
Copy link

No, I didn't work at all on BlazorWebView

@DerbyRussell
Copy link

BlazorWebView shouldn't be hard because I already have the buttons, labels, check boxes etc ready for MAUI and BlazorWebView is simply HTML converted to all these items.

@DerbyRussell
Copy link

I haven't had time for BlazorWebView.

@DerbyRussell
Copy link

I also did not have time for Menu or Menu Bar, Flyout Page. And because Microsoft is only supporting ListView control in a backwards compatibility mode only, I did not work on the ListView control. The ListView is actually very similar to the BlazorWebView control in terms of difficulty.

@stevexuzeta
Copy link

Sorry Guys and Gals, I hadn't tried building my samples in a while. Just updated the code so they are working again. https://github.com/DerbyRussell/maui/tree/derby-gtk3-integration-prism

The samples are a starting point and absolutely must be working!

How to build on Windows visual studio and publish to Linux?

@DamianSuess
Copy link

DamianSuess commented Oct 2, 2023

Sorry Guys and Gals, I hadn't tried building my samples in a while. Just updated the code so they are working again. https://github.com/DerbyRussell/maui/tree/derby-gtk3-integration-prism
The samples are a starting point and absolutely must be working!

How to build on Windows visual studio and publish to Linux?

At my org, we use VS Linux Debugger. Self-plugs aside, this will help you to deploy your C# apps onto your remote Linux machine.

While auto-attaching to GUI apps for debugging is a work-in-progress, you can still launch your app and manually attach to the remote process in Visual Studio. These steps are outlined on the Marketplace and GitHub pages 👍

@lytico
Copy link

lytico commented Mar 25, 2024

another attempt is here: jsuarezruiz/maui-linux#66

@amirvenus
Copy link

is android not supported on dotnet 8.0 arm Ubuntu?

dotnet workload search

Workload ID Description

aspire .NET Aspire SDK (Preview)
macos .NET SDK Workload for building macOS applications.
maui-tizen .NET MAUI SDK for Tizen
maui-windows .NET MAUI SDK for Windows
wasi-experimental workloads/wasi-experimental/description
wasm-experimental workloads/wasm-experimental/description
wasm-tools .NET WebAssembly build tools

dotnet workload install android
Workload ID android isn't supported on this platform.

@DerbyRussell
Copy link

DerbyRussell commented Apr 4, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests