Maui: Plattformübergreifende UX für .NET 5

Ich mag diese Idee. In der Praxis wird dies jedoch eher vom Xamarin.Forms-Team behandelt.
Vielleicht würde das Core-Team einige Low-Level-Konstrukte beitragen, um das UX-Framework „besser“ zu machen (wie das, was CoreFxLab tut).

Bearbeiten: Könnte WebAssembly auch eine unterstützte Plattform werden?

Ich mag die Idee. Ich habe Menschen (mich eingeschlossen) gesehen, die unter mehreren UI-Technologien für mehrere Umgebungen litten.

Ich bin mir ziemlich sicher, dass wir in absehbarer Zeit sehen werden, wie .net Core auf Android- und iOS-Geräte portiert wird, wobei die native Anwendung als Ersatz für corehost verwendet wird. Vor diesem Hintergrund sind UI-Funktionen erforderlich.

Für 2D-xplat-Zeichnungsbibliotheken (einschließlich beschleunigtem Zeichnen) haben wir zum Beispiel Skia.

In allen Szenarien glaube ich, dass XAML-Standard eine gute Sache sein wird, um zusammen mit den Fluent Design-Richtlinien eine Standardmethode zur "Beschreibung" der Benutzeroberfläche zu erreichen.

Ich bin jedoch skeptisch, ob das .Net-Team plant, mehr Zeit dafür zu investieren, als nur einige xplat System.Drawing.X -Primitive zurückzubringen ...

@4creators Vielleicht ist diese Diskussion für Sie von Interesse

@vibeeshan025 WebAssembly ist kein Ersatz für JavaScript, daher ergeben die meisten Ihrer Kommentare keinen Sinn. Sie benötigen weiterhin JavaScript, um eine WebAssembly mit dem DOM zu verbinden. Also, nein, Sie können nicht einfach etwas in wasm kompilieren und erwarten, dass es alles, was Sie zuvor getan haben, durch JavaScript ersetzt. So geht es nicht. Es wird keine UI-Technologie sein.

Hey Leute, ich will nur meine 5c hier reinstellen.
System.Drawing.X ist für die .NET Core-Entwicklung unerlässlich. (kam gerade von https://github.com/dotnet/corefx/issues/20325 hierher)

Ab UI - fragen Sie Web (Front-End)-Entwickler. Sie verwenden viele moderne Tricks wie Hot Reload.
Mir persönlich gefällt, wie sich die Dinge rund um React/ReactNative entwickeln. Es wäre großartig, C# zum Schreiben von React zu verwenden und dann verschiedene Render-Engines für verschiedene Plattformen zu verwenden.

FWIW, Mono übernimmt WebAssembly . Wenn es also in Mono funktioniert, funktioniert es (oder wird funktionieren) in WebAssembly. Das ist zumindest die gegenwärtige Idee/Verständnis.

Außerdem muss ich die Meinung über die Wahrscheinlichkeit wiederholen, dass .NET/MSFT diese Aufgabe erfüllt. Ihr gesamter Fokus/IQ wurde auf Core/Internals/Framework/Just-get-it-working gelegt und ich denke, das wird noch etwa ein Jahr so ​​bleiben. Aber wer weiß, ich könnte (angenehm) überrascht sein.

Meine Meinung dazu ist, dass einige externe Bemühungen an Dynamik gewinnen und vielleicht von MSFT, ala Xamarin, gekauft werden, aber mehr auf die Benutzeroberfläche ausgerichtet sind (im Gegensatz zu Framework/Tooling-fokussiert, was meiner Meinung nach die Kernstärke von Xamarin ist). Also so etwas wie Avalonia oder Noesis , die ihr Leistungsversprechen über Open Source bzw. kostenpflichtige Kanäle anbieten. Übrigens sind beide eingebaut/unterstützt Mono.

XAML-Standard hat sich mit der Veröffentlichung von XAML-Standard (Vorschau) für Xamarin.Forms und dem längst überfälligen Update zum Projektfortschritt etwas verschoben. Es gibt eine sehr interessante Diskussion in PR dotnet/designs#111 über Projektziele, die in eine Richtung zu gehen scheint, die diesem Vorschlag zugute kommt

Silverlight ist eine großartige Lösung, der Code existiert bereits

1. Open-Source-Silverlight-Code
2. Lassen Sie es auf der dotnet Core-Laufzeit laufen
3. Verwenden Sie Moonlight für die Linux-Distribution
4. Erstellen Sie eine Dotnet-Core-Alternative für „Electron“, es wird die Welt erfreuen (weniger Speicherverbrauch + enorme Leistungsverbesserung + xaml-Güte)
5. native Compliation (wenn eines Tages das Corrt-Projekt das Licht der Welt erblickt)

Fand es relevant - http://platform.uno

@gulshan Interessant, großartiges Projekt, unterstützt es die meisten UWP-Features, wie sie in sehr kurzer Zeit mit nur 4 Mitwirkenden eine so reichhaltige Reihe von Featears implementieren konnten.

@ vibeeshan025 Sie haben eine Firma, die es IIRC finanziert ...

Eine weitere Zukunft, die es wert ist, erkundet zu werden – HTML/CSS + .net (anstelle von JS/TS). Wird hier schon probiert-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

Nach Recherchen scheint es, dass tcl/tk eine GUI-Option für alle Plattformen sein könnte. Nicht sicher, ob tcl/tk unter Windows das eigentliche gdiplus-Zeug aufruft, aber es könnte eine Option sein, WPF und Winforms auf Linux, Mac, Windows, Android?, iOS? Und vielleicht Webforms zu bringen? Ich bin mir nicht sicher, ob tcl/tk diese 3 letzten noch unterstützt. Wenn dies der Fall ist, wird die GUI mit einer einzigen Codebasis viel einfacher zu warten.

Mögliche zu verwendende GUI-Bibliotheken:

• TclBridge (scheint nicht kostenlos oder Open Source zu sein)
• der Mono (wahrscheinlich der beste vielleicht)
• Adler (nicht sicher, wie gut es ist)
• Vielleicht auch andere.

Ich hatte die Idee, tcl/tk aus dem tkinner-Modul von cpython zu verwenden.

Ich bin mir auch nicht sicher, ob .NET Core das Laden von Ressourcen aus *.resources (compiled resx) oder sogar aus *.resx noch unterstützt. Wenn es das tut, wäre es großartig.

Microsoft.DesktopUI.App derzeit ist v3.0.0-alpha-26921-3 mit täglichen Builds von Windows .NET Core SDK verfügbar. Ich bin neugierig, was nötig wäre, um es unter Linux unter einigen Übersetzungsschichten für GDC und DirectX zum Laufen zu bringen.

Es muss viel mehr als plattformübergreifendes UX sein, es muss ein plattformübergreifendes Anwendungsentwicklungs-Framework sein.
Es nur auf die UX zu beschränken, ist ein Fehler. Es sollte mindestens die gesamte Funktionalität von SilverLight + RIA-Services haben.
Wenn Sie riesige benutzerdefinierte Systeme für größere Unternehmen schreiben, die jahrzehntelang bestehen bleiben, müssen Sie sich alle Optionen offen halten, da Sie keine Ahnung haben, welche Anforderungen in einem Jahr (oder in 10 Jahren) hinzugefügt werden, also eine geschlossene und begrenzte Umgebung wie UWP wird niemals in Betracht gezogen, dasselbe gilt für etwas, das in einem Browser ausgeführt wird. Es muss vollen, unbegrenzten und nativen Zugriff auf jede einzelne Funktion, API und jeden Dienst auf den verschiedenen Plattformen geben.
Und wenn Sie ein System entwickeln, in dem Sie sowohl den Server als auch den Client schreiben, möchten Sie kein REST oder ähnliches verwenden (das verwendet werden soll, wenn Sie den Server schreiben und jemand anderes den Client schreibt). Stattdessen sollte es im Geiste von RIA sein, wo Sie die Server-API definieren und sie dann automatisch vom Client aufrufen, indem Sie dieselben (===) Klassen und Methoden wie auf dem Server verwenden. Alles muss stark typisiert werden. Die Datenvalidierung beginnt mit den harten Grenzen, die aus Feldern im SQL-Server (oder einer beliebigen von Ihnen verwendeten Datenquelle) abgerufen werden, und wird durch DataAnnotations erweitert, die automatisch bis zum Client weitergegeben werden (unter Berücksichtigung der Lokalisierung).

Das ist nötig, weniger ist nicht akzeptabel:
Erstellen Sie ein allgegenwärtiges .NET-Client-Anwendungsentwicklungsmodell

Es ist jetzt 20 Jahre her, seit Visual Basic 6 veröffentlicht wurde, und wir haben noch lange nicht die Produktivität erreicht, die wir damals im Jahr 1998 hatten.Microsoft muss seine Vision präsentieren, wie ein größeres benutzerdefiniertes System in einer „Microsoft-Welt“ gemacht werden sollte und wie sie die Produktivität zurückbringen, die wir vor 20 Jahren hatten.

Microsoft muss sich zusammenreißen und die Verantwortung übernehmen, die sie haben. Microsoft muss erkennen, dass all seine Kunden, Partner und Entwickler, die jahrzehntelang stark in MS-Technologie investiert haben, zutiefst enttäuscht sind und ihr Vertrauen in MS sehr gering ist. MS müssen anfangen, ihre Kunden, Partner und Entwickler zu respektieren und ihren Ruf und Respekt wieder aufzubauen, aber wenn ich sehe, was sie jetzt mit Skype machen und wie sie ihre Skype-Kunden und -Benutzer behandeln, habe ich wenig Hoffnung, dass dies passieren wird.

Und vergessen Sie Xamarin, Microsoft verwendet es nicht einmal selbst , und entscheiden Sie sich lieber für ein Single-Thread-Framework, das Speicher beansprucht, wie das ElectronJS-Framework (basierend auf Chromium, Node.js, JavaScript und CSS), als Xamarin zu verwenden, das sie besitzen und volle Kontrolle haben und die echten nativen Code für jede Plattform erzeugen würden.

@ Bartolomeus-649

Es ist jetzt 20 Jahre her, seit Visual Basic 6 veröffentlicht wurde, und wir haben noch lange nicht die Produktivität erreicht, die wir damals im Jahr 1998 hatten.

Und die Verbreitung der Computer- und Internetnutzung sowie die Vielfalt der Plattformen (OS / Mobilität / Formfaktoren) ist längst nicht mehr so ​​gering wie 1998.

Was Sie meiner Meinung nach verlangen, ist "jemand, der alle Ihre Probleme löst". Die Gründe für diese Vielfalt sind vielfältig, oder wir würden alle dasselbe Gerät mit demselben Betriebssystem verwenden. Der Aufbau einer „Abstraktion über alles“ ist schwierig und bietet Ihnen normalerweise nur den kleinstmöglichen Funktionsumfang. Xamarin hat hier immer noch den besten Ansatz, sodass Sie nach Möglichkeit plattformspezifische APIs verwenden können. Aber selbst gute Abstraktionen für mobile Anwendungen helfen Ihnen möglicherweise nicht bei Desktop-Anwendungen mit hoher Produktivität.

Bei den anderen Punkten, die Sie ansprechen, handelt es sich meines Erachtens hauptsächlich um persönliche Meinungen oder Beobachtungen, die auf Ihre spezifische Arbeit zutreffen, und nicht um allgemein gültige Aussagen.

Ich hoffe, dass wir bessere plattformübergreifende Erfahrungen machen werden, aber ich glaube nicht, dass es einfach sein wird oder den Test der Zeit bestehen wird. Auch wenn sich WebAssembly und Electron-ähnliche Shells, PWAs und Co. in den nächsten 5 Jahren zur Go-to-Lösung entwickeln, machen wir vielleicht in 20 Jahren etwas ganz anderes (und dann würden wir uns darüber beschweren, wie einfach die Dinge 2018 waren 😂 ).

Microsoft hat unsere Erwartungen und Open-Source-UX-Frameworks erfüllt. Wir können jetzt Community-Projekte starten, um sie auf andere Plattformen zu portieren. Leider hat MSFT ausdrücklich erklärt, dass sie nicht planen, an irgendwelchen Ports zu arbeiten, also scheint es, dass dieser Job der Community überlassen wird.

@richlander @karelz @AdamYoblick @llongley @kmahone

Meine Frage ist, ob wir - die Community an Linux- und MacOS-Portierungen innerhalb bestehender Repos arbeiten könnte, dh in separaten Zweigen, oder sollten wir separate Repos erstellen, um solche Projekte zu unterstützen? Dies ist eine sehr wichtige Entscheidung, da die Verwendung vorhandener Repos es uns ermöglichen würde, Ports in die MSFT-CI-Infrastruktur zu integrieren, die andernfalls von der Community von Grund auf neu eingerichtet werden müssten.

Gibt es einen Grund, warum Xamarin.Forms/Avalonia/Platform.Uno nicht Ihren Anforderungen entspricht? Es scheint, dass ein neuer Versuch, plattformübergreifendes XAML bereitzustellen, der Community als Ganzes wenig Wert bringt.

Nicht 4Creators, aber meine 2¢/Impressionen:

• Xamarin.Forms scheint sich hauptsächlich auf mobile Szenarien zu konzentrieren.
• Gleiches gilt für Platform.Uno
• Avalonia ist noch nicht bereit für die Hauptsendezeit. Zu buggy für mich, um darauf vertrauen zu wollen. (Das letzte Mal, als ich es überprüft habe, ließ sich die Demo-App nicht einmal in die aktuelle stabile Version integrieren, was nicht gerade Vertrauen schafft.)

Ich sage nicht, dass eine plattformübergreifende Portierung von WPF oder Winforms hier die Lösung ist. (Eine API-kompatible plattformübergreifende Portierung von Winforms ist nicht einmal eine großartige Idee, IMO. Kein Kommentar zu WPF.) Ich denke jedoch, dass die vorhandenen Lösungen auch nicht für die Entwicklung von Desktop-Anwendungen geeignet sind.

Gute Argumente. Dennoch sollten wir uns darauf konzentrieren, bestehende Lösungen zu verbessern, anstatt eine neue zu bauen, die viel mehr kostet als die vorherige.

Übrigens, irgendwelche Schwachstellen bei NoesisGUI?

Die Community könnte an Linux- und MacOS-Portierungen arbeiten

@4creators Erstellen Sie Forks, die Sie besitzen und über die Sie die volle Kontrolle haben.

CI-Infrastruktur

Die .NET Core CI-Infrastruktur bewegt sich hin zur Verwendung eines regulären Azure DevOps anstelle der aktuellen benutzerdefinierten Jenkins-basierten Lösung. Azure DevOps bietet kostenlose Angebote für Open-Source-Projekte , die Sie nutzen können.

Apropos nur für dotnet/winforms:

Winforms verwendet bereits AzureDevOps, und jeder PR in den Master führt den PR-CI-Build automatisch aus.

Ich bin mir jedoch ziemlich sicher, dass jede Arbeit in einer Gabelung erledigt werden muss. Wir planen nicht, Schreibzugriff auf dotnet/winforms zu gewähren, nur damit Benutzer ihre eigenen Branches erstellen können. Mit all den öffentlichen Beiträgen würde das unser Repo ziemlich verschmutzen. :)

Übrigens, irgendwelche Schwachstellen bei NoesisGUI?

Irgendwie wurde NeosisGUI von meinen Notizen verschont, die ich zu verschiedenen UI-Frameworks halte, also musste ich es mir noch einmal ansehen.

Ich habe es nicht benutzt, obwohl ich es versuchen wollte. Mein Eindruck ist, dass es für die Unterstützung der Benutzeroberfläche im Spiel gedacht ist, daher ist es möglicherweise nicht für Tools geeignet. (Obwohl dies eine schlechte Annahme sein könnte, wenn man sich die Auflistung der Steuerelemente ansieht.) Für die Benutzeroberfläche im Spiel rechtfertigen unsere Anforderungen nicht die zukünftigen Kosten. Es unterstützt aus irgendeinem Grund auch nicht die Nintendo Switch. (Obwohl es anscheinend noch in Arbeit ist .)

@4creators Ich denke, diese Ausgabe ist falsch betitelt, weil zwei Ausgaben verwechselt wurden.

Erstens, .Net-UI-Frameworks erlauben, .Net Core anstelle anderer .Net-Laufzeiten zu verwenden . WPF kann jetzt auf .Net Core ausgeführt werden, und sie könnten Xamarin.iOS/Android/Mac/GTK auch auf .Net Core ausführen. Dies hat Leistungs- und Wartungsvorteile im Vergleich zur Verwendung von Mono oder .Net Framework.

Dadurch wird jedoch kein neues plattformübergreifendes UI-Framework erstellt . Und in den Threads, auf die Sie verweisen, und den meisten Beiträgen hier geht es um die Erstellung eines neuen plattformübergreifenden UI-Frameworks. Die Laufzeit ist hier nicht das Hauptproblem. Diese Threads sind jedoch äußerst verwirrend, da sie nicht die tatsächlichen Schwierigkeiten bei der Implementierung einer plattformübergreifenden Benutzeroberfläche ansprechen, die durch tatsächliche Implementierungen (Xamarin.Forms, die weitgehend native Steuerelemente verwenden, und Avalonia, das allgemeines Rendering verwendet) behoben wurden.

Es ist besser, an der Verbesserung der Xamarin.Forms-Desktopfunktionen zu arbeiten, indem Sie die relevanten Desktopsteuerelemente hinzufügen (nicht schwer), oder dazu beitragen, Avalonia stabil zu machen, wenn Sie dies vorziehen. Jede neue Plattform (selbst wenn sie auf einer vorhandenen Einzelplattform basiert) erfordert Jahre der Arbeit, um die Alphaqualität zu erreichen, und die einzige Rechtfertigung für die Wiederholung von Xamarin.Forms und Avalonia, anstatt zu ihnen beizutragen, besteht darin, dass sie beide dies tun falsch.

Dem letzten Teil stimme ich zu. Das Xamarin-Team hat jedoch ausdrücklich gesagt, dass das Ersetzen von Mono durch .NET Core nicht machbar ist, da sie für unterschiedliche Workloads optimiert sind und erhebliche, nicht triviale Integrationsarbeiten erforderlich sind.

Ich denke, diese Ausgabe ist falsch betitelt, weil zwei Punkte verwechselt wurden.

@charlesroddie IMO, nicht wirklich. Es geht nicht darum, ein UX-Framework auf der .NET Core-Plattform verfügbar zu haben, sondern vielmehr um die UX, die Teil des DotNet-Ökosystems ist, das gemeinsam mit anderen Teilen erstellt und gepflegt wird. Zukünftige MSFT-Pläne für das .NET-Ökosystem basieren auf .NET Core, wobei .NET Framework als veraltete Windows-Komponente veraltet ist und nicht für die Entwicklung neuer Anwendungen empfohlen wird. Es gibt derzeit keine Pläne, Xamarin.Forms auf .NET Core zu portieren, aus einigen Gründen, die oben von @Happypig375 angegeben wurden, und der andere Grund ist eine fehlende Entscheidung, wie mit der xplat-Unterstützung auf Mobilgeräten fortgefahren werden soll. Ich gehe jedoch davon aus, dass aufgrund des in .NET Core investierten Entwicklungsaufwands die zukünftige xplat-Plattform, die von MSFT verwendet wird, .NET Core-basiert sein wird.

Mono ist für viele Workloads selbst unter Linux nicht optimiert genug, und es werden keine wichtigen neuen Funktionen mehr auf dieser Laufzeit entwickelt. BCL wird derzeit von Mono und .NET Core gemeinsam genutzt. Dies deutet auf eine hohe Wahrscheinlichkeit einer zukünftigen Abwertung von Mono hin.

Basierend auf diesen Annahmen denke ich, dass es sich lohnt, eine einzelne UX-Plattform auf Basis von .NET Core als Teil ihres Ökosystems zu haben. Daher ist der Titel des Problems genau so, wie er sein sollte, da ich nicht nach einem UX-Framework frage, das auf xplat und dem CLI-Standard basiert, sondern nach einem UX-Framework, das Teil des .NET Core-Ökosystems ist, das vom DotNet-Team entworfen und unterstützt wird.

.Net Standard stellt sicher, dass verschiedene Laufzeiten der Benutzeroberfläche problemlos Teil desselben Ökosystems sein können. Obwohl .Net Core Vorteile gegenüber anderen Runtimes hat, die irgendwann an Wert verlieren können, ist es nicht notwendig, die Runtime mit dem Finden des richtigen Ansatzes für plattformübergreifende Benutzeroberflächen zu verknüpfen. Es verkompliziert die Frage nur.

Es würde zu weit führen zu sagen, dass eine UX-Plattform auf einer bestimmten Laufzeit „basiert“. @Happypig375 Es ist derzeit nicht in Xamarins Plänen, zu .Net Core zu wechseln (die Pläne sehen stattdessen vor, dass Mono .Net Core ähnlicher wird, indem Code geteilt wird). Aber es sollte nicht schwieriger sein, WPF auf .Net Core zu verschieben.

(Übrigens stimmt es nicht, dass Mono keine neuen Funktionen hat, da es aktualisiert wird, um .Net Standard 2.1 zu unterstützen, und die aktuelle Arbeit an Webassembly wird in Mono und nicht in .Net Core durchgeführt. Aber das ist eine Nebensache, da diese Arbeit portiert werden kann zu .Net Core.)

WinUI 3.0 Roadmap - wir brauchen Ihren Input!

Es scheint, dass dieser Entwicklungsvorschlag neue xplat-Möglichkeiten eröffnen könnte, sobald alle erforderlichen Komponenten quelloffen sind.

Sie sollten in Betracht ziehen, es MicrosoftUI 1.0 zu nennen, wenn das der Fall ist, @4creators. 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

Ich glaube, dieses Problem wird von diesem Repo angegangen.