1. 5
  1.  

  2. 5

    How ironic that Xamarin, originally designed for .NET applications on Linux, is now not for Linux anymore. I wonder what De Icaza would think of that.

    1. 5

      Considering how the Linux community treated Mono, who can blame them?

      1. 1

        I’m not sure who would have backed up Mono on Linux. Permanent second class, living in the shadow of an uncooperative giant. Icaza’s long term vision was always unclear to me, but history shows what it was: assimilation, annihilation ;)

        1. 4

          I have a different view of it, informed by rms’ fatwa against it that became the closest the Linux community got to an angry mob (i.e; screaming about Mono-based applications on distro CDs, trying to cancel a Debian developer for packaging it, etc.).

          Microsoft in the 2000s seemed fairly cool towards it (i.e. adding Unix to the OS enum), but they were too Windows focused to promote such a thing. I understand why Mono had to wither away for MS’ own push for .NET on Linux (Windows users didn’t think it was viable, Linux users had prejudice), but I’m sad that a good project spent years in the weeds because of it.

          1. 3

            I understand why Mono had to wither away for MS’ own push for .NET on Linux (Windows users didn’t think it was viable, Linux users had prejudice), but I’m sad that a good project spent years in the weeds because of it.

            I don’t think this is quite what’s happened. One of the goals of .NET 5 was to merge the Mono and .NET Core codebases. Various bits of Mono infrastructure are used in the Xamarin components.

            This makes me somewhat sad because Mono was very portable but the .NET Core-derived bits are Linux/Windows/macOS and often lose *BSD/whatever support that Mono has had for ages.

      2. 1

        Too much money to care about that

      3. 2

        I was curious to see if this was built on top of GTK, but it seems like desktop Linux/BSD is not a target at all.

        1. 3

          So much for “Write cross-platform apps in XAML and C#, from a single shared code-base”.

          1. 2

            https://docs.microsoft.com/en-us/dotnet/maui/supported-platforms mentions that Linux support is provided by the community. Maybe somebody else can comment on the quality. Honestly, it feels like a lost opportunity/oversight if I’m generous and if not, it just goes on to highlight that not much has actually changed about M$ w.r.t. to Linux, i.e. do the bare minimum to make money of/with it but not more.

            1. 7

              It’s difficult to support ‘Linux’ because there’s no ‘Linux’ GUI toolkit. It’s possible to support Android. It’s possible to support GTK. It’s possible to support Qt. If you support GTK, the KDE folks will hate you. If you support Qt, the GNOME folks will hate you. In both cases, you’re taking dependencies on LGPL’d things and everyone shipping the code needs to understand the legal obligations that this comes with (the cross-platform bits are all MIT licensed so the legal obligations are trivial to comply with).

              If the community maintains GTK or Qt (or both) integrations then anyone wanting to use them is picking up an extra dependency (the community-maintained version) and needs to do the same due diligence on licensing that they’d need to for any other dependency.

              Personally, I’d love to see something based on Skia added for a completely portable MIT-licensed GUI toolkit but it’s not something I have time to work on.

              1. 1

                see my comment above, it seems that they are moving in that direction. Microsoft.Maui.Graphics supports Linux via GTK and states that it implements SkiaSharp APIs.

                Although, since you work your probably have more preview then just my searches

                1. 3

                  see my comment above, it seems that they are moving in that direction. Microsoft.Maui.Graphics supports Linux via GTK and states that it implements SkiaSharp APIs

                  The links you found make it look as if they’re moving towards a pure .NET widget set. SWING did that and it was awful for a couple of reasons. The first is that Java was painfully slow 20 years ago. The CLR is a lot better than a 20-year-old JVM and computers are a lot faster, so that’s not a problem. The second is common with things like Qt that do the same: Your apps don’t feel native unless you put in a lot of work. For example, on macOS it took 15 years for Qt to use the same keyboard shortcuts for navigation in a text field as every other application on the system. NSTextView automatically integrates with text services so I can, for example, hit a shortcut key in any NSTextView with rich text enabled and have a LaTeX math expression replaced with a PDF rendering of it (which embeds the source in the PDF metadata so I can hit another key combination to get back the original). There’s a huge amount of plumbing required to get that kind of thing right and you have to redo a lot of if if the system APIs change.

                  For X11/Wayland, the UIs are so inconsistent that it probably doesn’t matter. For iOS / macOS, it’s really noticeable when things bring their own widget set (or even don’t properly port their UI. For example, command-shift-z is redo on every Mac application, except on Office where it’s command-y). For Windows / Android it’s mildly annoying but there’s already quite a bit of inconsistency.

                  Although, since you work your probably have more preview then just my searches

                  I try to meet up with some of the .NET folks when I’m in Redmond to get their perspective on Verona, but I haven’t managed to visit for two years because of the pandemic. I’m not working on anything in the .NET space so I don’t know anything that isn’t public.

                2. 1

                  Personally, I’d love to see something based on Skia added for a completely portable MIT-licensed GUI toolkit but it’s not something I have time to work on.

                  I haven’t looked but I’d assume that’s what Flutter uses across the board, incl. the recently announced Linux implementation.

                  1. 1

                    Flutter, unfortunately, is tightly coupled with Dart. This is great if you want to use Dart, but it means that you don’t have a language-agnostic toolkit and so doesn’t look like something that MAUI could use.

                3. 2

                  There is

                  https://github.com/dotnet/Microsoft.Maui.Graphics

                  “…. Microsoft.Maui.Graphics is a cross-platform graphics library for iOS, Android, Windows, macOS, Tizen and Linux completely in C#. With this library you can use a common API to target multiple abstractions allowing you to share your drawing code between platforms, or mix and match graphics implementations within a singular application.

                  …”

                  Even now (de-prioritized ?) Tizen is there.

                  The Linux seems to be supported via GTK

                  This is a graphics only library (means Canvas + fonts + PDF ), not a library of GUI controls. The graphics library implements mono’s SkiaSharp APIs. Noteable that mono’s SkiaSharp itself does not appear to support Linux, at least from its readme). So MAUI’s support for Linux’s graphic’s primitives is moving in a right direction, compared to previous SkiaSharp.

                  There is an experimental project on top of Microsoft.Maui.Graphics, that aims to build Controls for all the operating systems:

                  https://github.com/dotnet/Microsoft.Maui.Graphics.Controls

                  However, this project does not have anything in its https://github.com/dotnet/Microsoft.Maui.Graphics.Controls/tree/main/src/GraphicsControls/Platform for Linux, yet.

                  I certainly would hope that .NET ecosystem would support Linux and the 3 BSD as first class citizen. MAUI’s summary emphasizes support for various sensors, and I think Linux and the couple of BSDs have a reasonably noticeable presence in the device + sensors space.

                  Also I wish MS would have a consolidated, easy to consume strategy for all of their cross platform UI efforts (graphics, controls, etc) – right now it is really difficult to grok.