Microsoft-ui-xaml: Diskussion: WinUI vs ElectronJS und plattformübergreifend (WinUI verbessern, um Gründe für die Verwendung von ElectronJS anstelle von WinUI zu beseitigen)

Das gleiche gilt für die neue Xbox Beta-App. Es verwendet 400 MB, die gerade als verherrlichter Store geöffnet sind. Der Microsoft Store verwendet im aktiven Zustand nur 117 MB.

Bis Microsoft ein plattformübergreifendes UI-Framework entwickelt, das ein einheitliches UI- und Control-Design auf allen Plattformen ermöglicht, werden ElectronJS und seinesgleichen weiterhin verwendet.

Beispiel für die erstaunliche Geschwindigkeit von ElectronJS/Teams:
Als Vergleich habe ich zunächst gemessen, wie lange es dauert, Microsoft Outlook zu öffnen und die neueste Nachricht im Posteingang anzuzeigen (ein Posteingang mit einer sehr großen Anzahl von Nachrichten). Es dauerte nur ein paar Sekunden - eigentlich war es so schnell, dass ich die Stoppuhr nicht schnell genug stoppen konnte, um eine genaue Messung zu erhalten.
Als nächstes habe ich gemessen, wie lange es dauert, Microsoft Teams zu öffnen und die neueste Nachricht im Chat mit einem Kollegen anzuzeigen: 27 Sekunden! Diese Zeit kann mehr oder weniger lang sein, je nachdem, wie viele Nachrichten und Bilder im Chat-Fenster vorhanden sind.

( UPDATE 9-NOV-2019: _Eine neue Version von Teams wurde veröffentlicht und verbessert die Zeit zum Anzeigen der neuesten Chat-Nachricht. Das oben genannte Beispiel von 27 Sekunden beschreibt jetzt die vorherige Version von Teams. Vielen Dank an die Microsoft-Mitarbeiter Mitglieder, die an dieser Verbesserung gearbeitet haben._)

Letzte Woche habe ich in Teams auf das Hilfesymbol geklickt, dann auf "Feedback geben" geklickt und eine Nachricht eingegeben. Es war erstaunlich langsam: Jedes Mal, wenn ich eine Taste auf der Tastatur drückte, dauerte es mehrere Sekunden, bis jedes Zeichen erschien! (Als ich "Feedback geben" heute erneut getestet habe, lag es jedoch weit weniger zurück als letzte Woche, daher ist es anscheinend schwierig, dieses spezielle Problem zu reproduzieren.)

Wenn Teams mit WinUI geschrieben würden, gäbe es diese Geschwindigkeitsprobleme und verschiedene andere ungewöhnliche Fehler nicht. WinUI-Apps verwenden beispielsweise die Datums-/Uhrzeitformatierung, die in den Windows-Einstellungen konfiguriert ist, während Teams immer die 12-Stunden-Datums-/Uhrzeitformatierung für die USA verwenden, wenn Teams auf Englisch eingestellt ist, und die Windows-Einstellungen ignoriert – so ist Windows nicht Apps sollen funktionieren. Dann habe ich heute getestet, die Sprache von Teams zu ändern, und es hieß _"Es gab einen Fehler, Teams erholt sich"_. Und dann konnten mehrere Bilder in Nachrichten im Chat-Fenster nicht geladen werden.

Wenn Teams mit WinUI geschrieben wurden, würden auch keine 5 Teams-Prozesse erstellt.

@mdtauk

Bis Microsoft ein plattformübergreifendes UI-Framework entwickelt, das ein einheitliches UI- und Control-Design auf allen Plattformen ermöglicht, werden ElectronJS und seinesgleichen weiterhin verwendet.

Obwohl ich im Allgemeinen zustimmen würde, muss diese Geschichte mehr sein, denn zum Beispiel ist Microsoft OneNote für Windows, Android und Mac verfügbar, verwendet jedoch kein ElectronJS (AFAIK) und leidet nicht unter einer schrecklichen Leistung wie Mannschaften.

@mdtauk

Bis Microsoft ein plattformübergreifendes UI-Framework entwickelt, das ein einheitliches UI- und Control-Design auf allen Plattformen ermöglicht, werden ElectronJS und seinesgleichen weiterhin verwendet.

Obwohl ich im Allgemeinen zustimmen würde, muss diese Geschichte mehr sein, denn zum Beispiel ist Microsoft OneNote für Windows, Android und Mac verfügbar, verwendet jedoch kein ElectronJS (AFAIK) und leidet nicht unter einer schrecklichen Leistung wie Mannschaften.

Microsoft verfügt über die Ressourcen, um Apps für jede Plattform zu erstellen und so viel Code wie möglich zu teilen – aber keine gemeinsame Benutzeroberfläche zu verwenden

Ich würde gerne Argumente gegen die Verwendung der Uno-Plattform hören, die auf mehrere Plattformen (Windows, iOS, Android, Web) abzielt und leistungsstarke App-Pakete mit der UWP-API jetzt und später mit WinUI produziert. Es verwendet alles von Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Ist das Kommen von Microsoft nicht direkt der Hauptgrund für einige, dies zu vermeiden?

Ich würde gerne Argumente gegen die Verwendung der Uno-Plattform hören, die auf mehrere Plattformen (Windows, iOS, Android, Web) abzielt und leistungsstarke App-Pakete mit der UWP-API jetzt und später mit WinUI produziert. Es verwendet alles von Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Ist das Kommen von Microsoft nicht direkt der Hauptgrund für einige, dies zu vermeiden?

Dies wäre vor einigen Jahren ein besseres Argument gewesen, aber viele Unternehmen, die in die Entwicklung einer App oder eines Systems investieren möchten, müssen wissen, dass die Plattform, für die sie entwickeln, die Unterstützung und Langlebigkeit eines großen Unternehmens mit riesigen Ressourcen wie Microsoft bietet.

Das Problem mit diesem Argument ist, dass Microsoft in den letzten zehn Jahren gezeigt hat, dass Plattformen und Benutzerbasen aufgegeben wurden und Windows in die Legacy-Phase verschoben wurde oder innerhalb von Microsoft an Priorität verliert.

Sie können also neue Entwickler nicht dafür verantwortlich machen, dass sie auf Webplattformen umsteigen, wenn sie vernetzte Dienste betreiben möchten - oder sich auf Plattformen konzentrieren, die aktiv entwickelt werden und in Zukunft starke Unterstützung zu haben scheinen.

Gleichzeitig gibt es einige große Unternehmen wie Adobe mit Legacy-Apps – daher wird es so gut wie unmöglich sein, Plattformen mit diesen zu verschieben. Es gibt auch Bastler und Unternehmen mit kundenspezifischer Software.

Microsoft hat mit der .NET- und Win32-Unterstützung gute Arbeit geleistet. Und WinUI ist vielleicht die Chance, Win32 und .NET zuzulassen - aber mit einer modernen Benutzeroberfläche.

Silverlight, WinRT, UWP - wurden alle aufgegeben. (Ich weiß, dass UWP technisch nicht funktioniert, aber WinUI wird höchstwahrscheinlich als Ersatz angesehen).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 – lassen Sie die Enthusiasten und diejenigen, die sie zu evangelisieren versuchten, im Stich.

Wie Microsoft WinUI positioniert und auch die Zukunft von Windows sicherstellt, wird _absolut essenziell_ sein.

WinUI für Desktop sieht vielversprechend aus, aber ich bin der Meinung, dass zumindest eine Teilmenge von XAML im Web ausgeführt werden können muss. WinUI im Web, wie ein neues Silverlight, aber auf .NET 5 und WebAssembly ausgeführt.

Silverlight, WinRT, UWP - wurden alle aufgegeben. (Ich weiß, dass UWP technisch nicht funktioniert, aber WinUI wird höchstwahrscheinlich als Ersatz angesehen).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 – lassen Sie die Enthusiasten und diejenigen, die sie zu evangelisieren versuchten, im Stich.

Zustimmung.
Ich kann einige meiner Silverlight-Apps nicht glauben (web0-Apps werden von einigen Benutzern immer noch täglich verwendet.
Microsoft zu folgen wurde immer schwieriger. Die Leute hinter der Uno Platform entwickeln und warten sie, um ihr Brot-und-Butter-App-Geschäft zu unterstützen. Es ist Open Source mit vielen Mitwirkenden. Ich habe das Gefühl, dass ich einen sehr guten Bus mit erstklassigen Fahrern trage, die gut wissen, wie man durch das Microsoft-Labyrinth oder das Chaos navigiert.

Meine 2 Cent: Die einzige Hoffnung von UWP und WinUI besteht darin, dass sie es schnell plattformübergreifend machen, inklusive Web, bevor nichts mehr davon übrig ist.
Uno Platform ist ein schneller, einfacher und wahrscheinlich auch sicherster Weg, dies zu erreichen.
Wie @zipswich erwähnte, war Uno die ganze Zeit über Microsoft; in den Coding-Guidelines, dem Tooling, der Sprachauswahl und dem Rendering und ist Fluent-Design ready.
Es ist beispielsweise 100-mal stärker von Microsoft abhängig als Xamarin. Geschweige denn React oder Electron und alle hässlichen HTML- und CSS- oder JS-Technologien, von denen MS so besessen ist, zu schmeicheln und zu betrügen.

Und seien Sie hartnäckig, C# ist nur eine Serversprache mit dem Fehlen eines UI-Frameworks von .NET Standard.
Je länger dies so bleibt, werden Dart oder andere Technologien zu Server-Sprachen und übernehmen vollständig.
Sie sehen, dass die Leute bereit sind, Nasty Languages ​​(JS) zu verwenden, als Opfer, um eine einsprachige Codebasis sowohl auf dem Client als auch auf dem Server verwenden zu können. C# kann genauso verblassen wie XAML, oder es kann zusammen mit XAML gewinnen, wenn eine Notfallrettung erfolgt.

Ich glaube nicht, dass Uno die Zukunft sein wird. Es ist Xamarin.Forms sehr ähnlich und ist ein abgespecktes Xaml-Framework mit vielen fehlenden Funktionen und vielen komplizierten zusätzlichen Dingen, die hinzugefügt werden, damit es irgendwie in alle Plattformen integriert werden kann, mit einigen Hacks und Problemumgehungen. Natürlich können Sie es verwenden, aber Sie sind sehr eingeschränkt in Bezug auf die Steuerelemente und die APIs, die Sie verwenden können. Das Hauptproblem besteht darin, dass versucht wird, die Xaml-Benutzeroberfläche mit den nativen Steuerelementen jeder Plattform zu realisieren. Dies ist immer problematisch und hinterlässt nur die kleine Teilmenge der Funktionalität, die zufällig auf allen Plattformen funktioniert.

Die Zukunft würde darin bestehen, die echte WinUI zu verwenden und einen echten Renderer für jede Plattform bereitzustellen, der in der nativen 3D-Engine der Plattform implementiert ist. Dies würde uns den kompletten Funktionsumfang, die ganze Güte von WinUI, mit nativer Leistung und plattformübergreifend erhalten.

Eigentlich hatte Microsoft so etwas bereits sehr gut laufen: UWP UI basierte größtenteils auf dem Silverlight-Code, und Microsoft hatte Silverlight-Plugins für alle wichtigen Plattformen, was bedeutet, dass sie bereits grundlegende Rendering-Engines für alle diese Plattformen haben. Sie sind nicht auf dem neuesten Stand, da UWP mittlerweile viele Ergänzungen im Vergleich zu Silverlight hat. Aber es ist eine Basis, auf der aufgebaut werden kann.

Microsoft hat sicher die Ressourcen, um dies zu erreichen. Das ist es, was die Leute wollen und das sollten sie tun.

C# kann genauso verblassen wie XAML >

Stimme dieser Aussage zu C# definitiv nicht zu. C# ist viel größer als XAML. Wenn Sie Blazor folgen, wissen Sie, dass dies nicht wahr sein kann. Ich sehe Blazor als Game Changer für mich, der hauptsächlich UWP / Xamarin verwendet, und für C#-Entwickler im Allgemeinen, die speziell auf Geschäftsbenutzer ausgerichtet sind.

Es wäre schön, WinUI x-Plattform zu haben, aber ich denke, der einfachste Weg zum Web / x-Plattform ist Blazor, besonders jetzt, da Blazor auch Teilklassen unterstützt, was bedeutet, dass ich den größten Teil meines vorhandenen Codes unverändert übernehmen und verwenden kann Blazor. Ein paar Probleme könnten Alternativen zu Sqlite , Shared Projects und ReactiveUI sein. Ich sollte in der Lage sein, meine vorhandene MVVM-Architektur zu verwenden und sie ziemlich einfach auf Blazor zu portieren.

Der wichtigste Stolperstein für mich ist die fehlende .net Core 3-Unterstützung in UWP. Ich denke, es ist wichtig für MS, Blazor + UWP in der Entwicklererfahrung aufeinander abzustimmen. Ich weiß, dass das UWP-Team daran arbeitet.

Außerdem würde ich gerne Blazor-Seiten in UWP-/WINUI-Apps sehen. Das hybride UI-Modell würde für mich in UWP-Apps hervorragend funktionieren, damit ich die besten verfügbaren UI-Assets verwenden kann. (html5 im Vergleich zu XAML) und replizieren auch nicht meinen UI-Aufwand zwischen UWP und Blazor, wo es sinnvoll ist.

Electron verwendet derzeit Javascript, HTML + CSS. Kein Grund, warum wir Electron nicht mit Blazor verwenden können => C# , HTML + CSS + gRPC

Sie sind jedoch sehr eingeschränkt in Bezug auf die Steuerelemente und die APIs, die Sie verwenden können.

@lucasf Hast du Uno ausprobiert? Wussten Sie, dass Uno die Verwendung jeder nativen API über Xamarin ermöglicht, falls keine geeignete UWP-API vorhanden ist. Ich verwende nur wenige native APIs in meinen Uno-basierten Apps, selbst für meine Echtzeit-Videostreaming-App, die Hardware-Codec verwendet und eine geringe Latenz erfordert.

Sie sind jedoch sehr eingeschränkt in Bezug auf die Steuerelemente und die APIs, die Sie verwenden können.

@lukasf Hast du Uno ausprobiert? Wussten Sie, dass Uno die Verwendung jeder nativen API über Xamarin ermöglicht, falls keine geeignete UWP-API vorhanden ist. Ich verwende nur wenige native APIs in meinen Uno-basierten Apps, selbst für meine Echtzeit-Videostreaming-App, die Hardware-Codec verwendet und eine geringe Latenz erfordert.

@zipswich Der Satz von Standard-Xaml-Steuerelementen in Uno ist ziemlich klein, nicht annähernd das, was UWP oder WinUI3 zu bieten haben. Um gute/komplexe UIs zu realisieren, müssen Sie normalerweise zusätzliche plattformspezifische native UI-Steuerelemente und Code einbetten. Am Ende finden Sie sich also mit einer Mischung aus mehreren UI-Plattformen (Uno Xaml, natives Android, natives iOS, möglicherweise natives Windows oder WebAssembly) wieder. Das nenne ich keine großartige Entwicklererfahrung.

Wenn wir native X-Platform-Renderer für WinUI hätten, hätten wir nur eine einzige Benutzeroberfläche mit dem vollständigen WinUI-Feature-Set, ohne jegliche plattformspezifische Dinge darin. Und die WinUI würde direkt auf der GPU mit voller Leistung rendern, genau wie Sie es erwarten würden. Es müssen keine zusätzlichen Android-Steuerelemente oder zusätzliche iOS-Steuerelemente hinzugefügt werden. So sollte die Entwicklung von x-platforms aussehen.

Was fehlt WinUI (und wie kann es verbessert werden), um die Microsoft-Programmmanager für Microsoft Teams davon zu überzeugen, von ElectronJS auf WinUI/UWP umzusteigen?

Tolle Frage. Eine große Anzahl von Benutzern wird sehr glücklich sein, wenn sie dies tun.

Ein großer Faktor ist das Fehlen von Leistungskennzahlen, die Frameworks vergleichen. Eine Seite, die äquivalente Apps in UWP und Electron vergleicht und Geschwindigkeit und Speichernutzung vergleicht, würde ausreichen. Dies könnte sich auf andere Frameworks erstrecken. Aus diesen Kosten für die Benutzer können Auswirkungen auf die Nutzung und der Nutzen der Codekonsolidierung gegen die finanziellen Kosten abgewogen werden.

Der derzeitige Mangel an dieser Forschung trägt dazu bei, dass ineffiziente Frameworks populär werden.

Ehrlich gesagt: Ich bezweifle, dass MS Pläne hat, "WinUI" ( Windows UI) plattformübergreifend zu machen. Darüber hinaus bedeutet die Tatsache, dass es jetzt Open Source ist, normalerweise, dass Microsoft es nicht mehr als kritische/strategische Technologie betrachtet. Sie versuchen stattdessen, die Ressourcen der Community zu nutzen, um die interne Mitarbeiterzahl zu senken und sie gleichzeitig am Leben zu erhalten. Verstehen Sie mich nicht falsch, ich bin froh, dass WinUI jetzt Open Source ist und schätze die Zeit, die die Microsoft-Entwickler in die Plattform investieren, um WinUI 3.0 zu bringen - es ist ein großartiger Schritt, die Windows-Präsentationsplattform sowohl für native als auch für zu konsolidieren verwaltete Apps. Ich glaube einfach nicht, dass Microsoft Windows als die Zukunft sieht und ich glaube nicht, dass sie daran interessiert sind, es plattformübergreifend zu nutzen (natürlich ist das ihr Fehler, wenn es wahr ist).

Ein echtes plattformübergreifendes Entwicklungsframework, das Entwickler nicht dazu zwingt, unterdurchschnittliche Technologie zu verwenden, ist das, was die Welt braucht. Anscheinend sind sich die meisten hier einig. Das bedeutet im Wesentlichen:

• Eine Steuerelementbibliothek und Markup (XAML), die genau wie plattformnative Designs rendern können (wir benötigen nur Steuerelementstile für iOS, Android usw.)
• Muss wie WPF in verwaltetem Code geschrieben werden. Nur die Basisschichten in C++, Controls sollten nie etwas anderes als C# sein.
• Das Rendern muss mit Metal/Vulcan/DirectX erfolgen (nicht zusätzlich zu bestehenden Steuerelementen wie Uno)
• Eingaben müssen auf X-Plattform-Art neu implementiert werden
• Barrierefreiheit ist ein großes Problem, das mit dem Ansatz von Uno leider viel einfacher zu lösen ist

Wenn wir das wollen, wird WinUI es meiner Meinung nach nicht tun. Allein die Tatsache und Art und Weise, wie es nativ implementiert ist (einige COM/.net-Schichten dazwischen), bedeutet, dass es sehr schwierig wäre, diese plattformübergreifende Anwendung zu nutzen. Stattdessen haben wir UNO und Avalonia. Avalonia ist das wahre Licht am Ende des Tunnels, aber sie haben keine Ressourcen. Was jetzt mehr oder weniger möglich ist, ist die Verwendung der Avalonia-Rendering-Technologie als Backend für WPF (den verwalteten Teil). Das würde uns in kurzer Zeit ein echtes plattformübergreifendes UI-Framework geben. Das Problem ist, dass WPF für Desktops entwickelt wurde und viel Arbeit in UWP gesteckt wurde, um WPF/Silverlight für telefongroße Geräte und moderne Touch- / interaktive Eingaben freundlich zu machen.

Ich denke ehrlich gesagt, dass wir an dieser Stelle besser dran wären, wenn wir alle nur Geld und Code-Beiträge nach Avalonia werfen würden. Wir haben Microsoft zu lange um eine plattformübergreifende Benutzeroberfläche gebeten, und sie sind damit zufrieden, selbst auf Webtechnologien umzusteigen. Microsoft konvertiert jetzt sogar UWP-Apps wie XBox in Electron- und Web-Technologien. Apps werden auch nicht im Microsoft Store verkauft.

Die Ironie ist, dass Microsoft in der Vergangenheit so erfolgreich war, weil sie Entwicklern die Tools zur Verfügung stellten, die sie zum Erstellen großartiger Apps benötigten. Dies zieht Benutzer an und Sie haben eine sehr konstruktive Feedbackschleife. Irgendwann wurde das vergessen. Jetzt greifen Entwickler auf unterdurchschnittliche Technologien zurück (HTML/CSS wurde ursprünglich nie für Apps entwickelt... es war für Dokument-Markup!) die Einbußen bei Funktionalität, Systemintegration und Leistung zu dieser Zeit bei weitem aufwiegen.

Die Ironie ist, dass Microsoft in der Vergangenheit so erfolgreich war, weil sie Entwicklern die Tools zur Verfügung stellten, die sie zum Erstellen großartiger Apps benötigten. Dies zieht Benutzer an und Sie haben eine sehr konstruktive Feedbackschleife. Irgendwann wurde das vergessen. Jetzt greifen Entwickler auf unterdurchschnittliche Technologien zurück (HTML/CSS wurde ursprünglich nie für Apps entwickelt ... es war für Dokument-Markup!)

Gut gesagt. Neben BASIC habe ich angefangen, Microsoft IDEs von Quick C zu verwenden, dann VC++... Microsoft hat sich beständig, konsistent und einigermaßen vorhersehbar weiterentwickelt, innoviert. Wir haben versucht, ihm zu folgen, und es scheint dem Trend derer zu folgen, die uns folgen sollen. Früher habe ich Praktikanten von erstklassigen Forschungsuniversitäten gesagt, dass sie Microsoft-Technologien für Unternehmensanwendungen verwenden sollten, an denen sie arbeiten sollten. Es gab keinen Widerstand, und sie nahmen Microsoft-Sachen gerne schnell auf. Ich habe mich gefragt, ob Microsoft sich angesehen hat, was Kinder heutzutage mögen, und ihnen dann folgen.

Apps werden auch nicht im Microsoft Store verkauft.

Stimmt leider. Ich beschuldige jedoch den schlechtesten App Store (für Benutzer und Herausgeber), nicht die Entwicklungstechnologien. Das tägliche Download-Verhältnis der UWP- und Android-Version einer App: 1:20 . Die Entwicklung kostet ungefähr den gleichen Aufwand. Dies ist nicht übertrieben. Ich habe mir gerade die Download-Daten von gestern angeschaut. Wenn ich für einen Bohnenzähler arbeiten würde, würde ich sofort gefeuert, weil ich so viel Aufwand für die UWP-Version aufgewendet habe, die so wenig Rendite generiert.

Stimmt leider. Ich beschuldige jedoch den schlechtesten App Store (für Benutzer und Herausgeber), nicht die Entwicklungstechnologien.

@zipswich , ja, Sie haben einen guten Punkt. Ich ging nur davon aus, dass Microsoft intern die Verkaufszahlen sieht und (richtigerweise) davon ausgeht, dass das Ökosystem im Sterben liegt. Dies überzeugt sie dann davon, dass die Arten von zugrunde liegenden Entwicklungstechnologien, über die wir sprechen, veraltet sind, sodass sie anfangen zu investieren und andere Richtungen einschlagen. Tatsächlich können die meisten Microsoft-App-Entwickler die klare Notwendigkeit für ein plattformübergreifendes Framework erkennen, das nicht geschrieben wurde, ohne die letzten 20 Jahre des technischen Fortschritts bei der Benutzeroberfläche zu vergessen (WPF war wirklich ein Wendepunkt, als es auftauchte).

Wir brauchen nicht nur plattformübergreifend: Wir brauchen etwas, das mit leistungsstarken/skalierbaren Sprachen und Markup gemacht wird und von Anfang an einen sinnvollen Umfang hat (für Apps gedacht, guter Kontrollkatalog). Ich glaube jedoch, dass wir uns dafür nicht mehr auf Microsoft verlassen können. Sie haben deutlich gemacht, dass sie höhere Gewinne erzielen, wenn sie ihre Zeit/Ressourcen in anderen Bereichen verwenden.

Ich würde sofort gefeuert, weil ich so viel Aufwand für die UWP-Version aufgewendet habe, die so wenig Rendite generiert.

Ich höre Sie, diese Aussage habe ich auch basierend auf meiner eigenen App im Microsoft Store gemacht.

@robloo Du hast da ein paar gute Punkte, aber ich folge dir nicht wirklich. Hier einige Gedanken:

• Microsoft hat auch viel Mühe und Ressourcen in andere Open-Source-Frameworks gesteckt, wie z. B. .NET Core, ASP.Net Core, EF Core. Offensichtlich sehen sie die Zukunft in Open Source, plattformübergreifender Entwicklung (zumindest für Serveranwendungen). Sie fügen auch Ressourcen in die AOT-Kompilierung ein, sodass .NET Core auch für iOS und Android kompiliert werden kann (wo JIT nicht zulässig ist). Ich kann Ihnen also nicht folgen, dass WinUI jetzt tot ist, nur weil sie es Open Source machen. Ich meine, es könnte wahr sein, aber wenn Ihr einziges Argument ist, "weil sie Open Source machen", dann ist dies nicht sehr überzeugend.

• Qt ist ein plattformübergreifendes UI-Framework, das in nativem C/C++ implementiert ist. Es verfügt über hardwarebeschleunigte OpenGL/Direct3D-Renderer, sieht also gleich aus und bietet auf allen Plattformen eine hervorragende Leistung. Es ist kein plattformspezifischer Code erforderlich, alle Steuerelemente laufen auf allen Plattformen, einschließlich iOS und Android. Warum sollte es also technisch nicht möglich sein, WinUI auf iOS und Android auszuführen, wenn Qt genau das kann? WinUI ist in WinRT implementiert, einem nativen C++, genau wie Qt. Intern verwendet es nur wenige COM-Technologien (IUnknown Interface plus das COM-Factory-System). Es sollte nicht allzu schwer sein, dies zu abstrahieren oder neu zu implementieren, was für andere Plattformen benötigt wird. Ich glaube nicht, dass COM-Code direkt im WinUI-Code verwendet wird.

• Silverlight verwendete die gleiche Technologie und war auf der x-Plattform verfügbar.

• Windows ist immer noch das Desktop-Betriebssystem Nummer 1 und wird nicht nur zu Hause, sondern auch (insbesondere) von Unternehmen stark genutzt. In Kombination mit Office-Lizenzen generiert es viele solide Einnahmen für Microsoft. Sie würden diese Einnahmen verlieren, wenn sie alle großen UI-Entwicklungsplattformen sterben lassen würden. WinForms und WPF sind bereits tot, daher ist WinUI die einzige aktive UI-Plattform unter Windows. Ich glaube nicht, dass sie das komplette Windows/Office/Enterprise-System loswerden wollen, also glaube ich nicht, dass sie WinUI loswerden wollen.

• WinUI Open Source zu machen ist großartig für Entwickler, nicht nur für Microsoft.

• Es könnte sein, dass UWP sterben wird. Viele Entwickler halten sich wegen all der dummen Einschränkungen davon fern. Der Windows Store ist nicht remote erfolgreich. Windows Phone ist tot, was der Hauptgrund war, die ganze UWP-Sache überhaupt zu starten.

• WinUI mit WinUI 3.0 auf Desktop-Apps zu bringen und es als Open Source zu machen, könnte tatsächlich der Schritt sein, es zu speichern und nicht zu töten!

Ich ging nur davon aus, dass Microsoft intern die Verkaufszahlen sieht und (richtigerweise) davon ausgeht, dass das Ökosystem im Sterben liegt. Dies überzeugt sie dann davon, dass die Arten von zugrunde liegenden Entwicklungstechnologien, über die wir sprechen, veraltet sind, sodass sie anfangen zu investieren und andere Richtungen einschlagen.

@robloo Das muss nicht sein. Ich habe die ganze Zeit gesagt, dass es der schlechteste App Store ist, der Windows Phone getötet hat, die beste mobile Plattform.

Sie können zwei Fliegen mit einer Klappe schlagen: den Store an einen kompetenten Dritten auslagern und den .Net Native-Albtraum beenden. Es wird ihre Kosten reduzieren und (glaube ich) verdoppeln, vervierfachen ... Windows-App-Downloads schnell. Mehr als 90% meiner UWP-App-Probleme hängen ausschließlich mit dem .Net Native-Albtraum zusammen.

@lukasf Ich glaube, du hast vieles von dem, was ich gesagt habe, falsch interpretiert.

Ich kann Ihnen nicht folgen, dass WinUI jetzt tot ist, nur weil sie es Open Source machen.

Ich würde nie sagen, dass WinUI tot ist. Ich habe gesagt, Microsoft sieht es wahrscheinlich nicht mehr als kritisches/strategisches Langzeitprodukt. Sie sehen höhere Gewinne in anderen Bereichen (Dienste und Cloud) und achten daher darauf, ihre Zeit dort zu verbringen, wo die Aktionäre höhere Gewinne erzielen. Dies bedeutet, dass ich denke, dass sie WinUI nicht wesentlich erweitern werden, um es plattformübergreifend zu machen und es einfach am Leben zu erhalten, was ich sicherstellte, anstatt "tot" zu sagen. (Ich bin nicht jemand auf der UWP/WinUI ist toter Zug). Ich bin auch sehr stark der Meinung, dass Microsoft mit WinUI 3.0 eine großartige Sache macht, was ich bereits sagte. Es ermöglicht die Konsolidierung aller Windows, Win32-nativ und verwaltet, mit einem UI-Framework.

Warum also sollte es technisch nicht möglich sein, WinUI auf iOS und Android auszuführen?

Technisch ist alles möglich. Ich sagte, es wäre jedoch extrem schwierig, da es ausschließlich für Windows entwickelt und implementiert wurde. Ich habe auch das Beispiel der Kommunikation mit verwaltetem Code als etwas angeführt, von dem ich denke, dass es sehr schwierig wäre, plattformübergreifend zu arbeiten. Es wäre gut für uns alle, wenn ich hier falsch liegen würde.

Silverlight verwendete die gleiche Technologie und war auf der x-Plattform verfügbar.

Und Silverlight ist tot, nicht weil es technisch nicht möglich war, sondern weil es kein guter Business Case mehr war, was wirklich mein kritischster Punkt ist. Beachten Sie, dass es auch an den gleichen HTML/CSS/JS-Technologien gestorben ist, die jetzt die Desktop- und Mobilentwicklung übernehmen.

Sie würden diese Einnahmen verlieren, wenn sie alle großen UI-Entwicklungsplattformen sterben lassen würden.

Dies könnte wahrscheinlich auf verschiedene Arten besprochen werden, gerät aber wahrscheinlich ziemlich schnell aus dem Rahmen des Themas (was ich weiß, dass ich es bereits tue). Unterm Strich wird Microsoft natürlich nicht alle Windows-UI-Plattformen sterben lassen. Sie müssen immer noch Apps für Windows schreiben ... Ich habe nie etwas anderes gesagt.

WinUI Open Source zu machen ist großartig für Entwickler, nicht nur für Microsoft.

Ich sagte: "Ich bin froh, dass WinUI jetzt Open Source ist und schätze die ganze Zeit, die die Microsoft-Entwickler in die Plattform investieren, um WinUI 3.0 zu bringen". aus Gründen, auf die ich nicht eingegangen bin. Als Beispiel ist selbst die Uno-Plattform, die jetzt Zugriff auf die Quelle hat, großartig, wie sie auf der UnoConf angegeben haben.

Es könnte sein, dass UWP sterben wird.

Warte, auf welcher Seite stehst du? Haha. Aber im Ernst, ich betrachte WinUI/UWP im Wesentlichen als dasselbe und UWP wird nur eine kleine Entwicklung zu WinUI ohne größere Probleme für Entwickler haben.

WinUI mit WinUI 3.0 auf Desktop-Apps zu bringen und es als Open Source zu machen, könnte tatsächlich der Schritt sein, es zu speichern und nicht zu töten!

Ich stimme dir zu und wollte nie etwas anderes sagen. Ich habe mir jedoch einige größere Trends angesehen und auch darüber gesprochen, sie plattformübergreifend zu nutzen.

@zipswich

Sie können zwei Fliegen mit einer Klappe schlagen: den Store an einen kompetenten Dritten auslagern und den .Net Native-Albtraum beenden. Es wird ihre Kosten reduzieren und (glaube ich) verdoppeln, vervierfachen.

Die gute Nachricht ist, dass Microsoft bereits beschlossen hat, .net native zu töten. Technisch gesehen hatte es eine Reihe lächerlicher Einschränkungen, die nicht den .net-Spezifikationen entsprachen, mit denen Sie anscheinend mehr als vertraut sind. Ich denke, es war etwas, das schnell / schmutzig gemacht wurde, um Start- und Leistungsprobleme auf Windows Phone zu beheben, und sie haben sich nie die Mühe gemacht, zurückzugehen und Dinge zu reparieren, seit Windows Phone gestorben ist.

Jetzt entwickelt Microsoft eine vollständige, hochleistungsfähige AOT-Kompilierung unter Verwendung von Mono-Technologien und LLVM. Dies sollte meiner Meinung nach im nächsten Jahr erscheinen und ist auch für clientseitiges Blazor mit Webassembly nützlich. Miquel de Icaza hat Anfang des Jahres auf der UnoConf eine gute Präsentation dazu gehalten: https://www.youtube.com/watch?v=tYk2us6W6Gg (er ist der erste Moderator).

@robloo Okay, vielleicht habe ich dich in einigen Punkten falsch verstanden.

Warum also sollte es technisch nicht möglich sein, WinUI auf iOS und Android auszuführen?

Technisch ist alles möglich. Ich sagte, es wäre jedoch extrem schwierig, da es ausschließlich für Windows entwickelt und implementiert wurde. Ich habe auch das Beispiel der Kommunikation mit verwaltetem Code als etwas angeführt, von dem ich denke, dass es sehr schwierig wäre, plattformübergreifend zu arbeiten. Es wäre gut für uns alle, wenn ich hier falsch liegen würde.

Silverlight verwendete die gleiche Technologie und war auf der x-Plattform verfügbar.

Und Silverlight ist tot, nicht weil es technisch nicht möglich war, sondern weil es kein guter Business Case mehr war, was wirklich mein kritischster Punkt ist. Beachten Sie, dass es auch an den gleichen HTML/CSS/JS-Technologien gestorben ist, die jetzt die Desktop- und Mobilentwicklung übernehmen.

Mein Punkt hier ist: Silverlight lief bereits plattformübergreifend. Es könnte mit verwaltetem Code verwendet werden. Die UWP-Xaml-UI-Schicht von Windows 8 war im Grunde Silverlight, nur mit einem neuen Namespace und einigen hinzugefügten Metadaten. Inzwischen hat es sich weiterentwickelt, aber am Anfang war es eindeutig nur Silverlight Xaml mit einem neuen Namensraum. Wenn sie Silverlight damals plattformübergreifend ausführen konnten, können sie WinUI auch plattformübergreifend ausführen. Und ich glaube nicht, dass dies "extrem schwierig" wird, aber ich würde eher sagen, dass es für ein riesiges Unternehmen wie Microsoft ziemlich einfach wäre. Sie hatten bereits einen plattformübergreifenden Rendering-Layer für Silverlight Xaml. Es sollte nicht zu schwer sein, es zu aktualisieren, damit es die neueste WinUI ausführen kann.

Es könnte sein, dass UWP sterben wird.

Warte, auf welcher Seite stehst du? Haha. Aber im Ernst, ich betrachte WinUI/UWP im Wesentlichen als dasselbe und UWP wird nur eine kleine Entwicklung zu WinUI ohne größere Probleme für Entwickler haben.

WinUI ist nur eine Xaml-UI-Schicht, während UWP ein vollständiges App-Framework und eine System-API-Schicht ist, die an den Windows Store gebunden ist und im Vergleich zu klassischen Desktop-Apps viele Einschränkungen aufweist. Das sind also zwei sehr unterschiedliche Dinge. Ich weiß wirklich nicht, ob Microsoft in UWP und dem Windows Store eine Zukunft sieht. Die schwerwiegenden UWP-Einschränkungen nicht zu beheben und nicht wirklich an den Windows Store-Problemen zu arbeiten, stimmt mich nicht sehr optimistisch. Aber sie brauchen definitiv eine Art UI-Framework, und das wird WinUI sein, egal ob von UWP oder von Desktop-Apps. Und wenn sie wirklich erfolgreich sein wollen, müssen sie es plattformübergreifend machen. Anderenfalls werden die Leute auf andere Frameworks umsteigen, und dann könnten sie irgendwann auch die Windows-Plattform vollständig verlassen. WinUI plattformübergreifend zu machen wäre ein Mittel, um Entwickler dazu zu bringen, sich an Windows zu halten.

Mein Punkt hier ist: Silverlight lief bereits plattformübergreifend. Es könnte mit verwaltetem Code verwendet werden. Die UWP-Xaml-UI-Schicht von Windows 8 war im Grunde Silverlight, nur mit einem neuen Namespace und einigen hinzugefügten Metadaten. Inzwischen hat es sich weiterentwickelt, aber am Anfang war es eindeutig nur Silverlight Xaml mit einem neuen Namensraum. Wenn sie Silverlight damals plattformübergreifend ausführen konnten, können sie WinUI auch plattformübergreifend ausführen. Und ich glaube nicht, dass dies "extrem schwierig" wird, aber ich würde eher sagen, dass es für ein riesiges Unternehmen wie Microsoft ziemlich einfach wäre. Sie hatten bereits einen plattformübergreifenden Rendering-Layer für Silverlight Xaml. Es sollte nicht zu schwer sein, es zu aktualisieren, damit es die neueste WinUI ausführen kann.

Ich wusste nicht, dass die Silverlight-Basis damals für UWP/Win8 verwendet wurde, wenn dies der Fall ist, stimmt es mich optimistischer, wie machbar dies ist. Danke für die Korrektur!

WinUI ist nur eine Xaml-UI-Schicht, während UWP ein vollständiges App-Framework und eine System-API-Schicht ist, die an den Windows Store gebunden ist und im Vergleich zu klassischen Desktop-Apps viele Einschränkungen aufweist. Das sind also zwei sehr unterschiedliche Dinge.

Ja, Sie haben Recht und ich hätte meine Formulierung sorgfältiger wählen sollen. UWP im App-Modell und -Packaging wird es sicherlich vorerst weiterhin geben. Die UI-Schicht wechselt jedoch zu WinUI, was ich zu kommunizieren versuchte. Ich denke, es wird in den kommenden Jahren weitere Änderungen geben, da .net native ersetzt wird, aber die mit UWP eingeführten Verpackungen/App-Modelle/APIs werden in irgendeiner Form weiterhin existieren. Ich stimme definitiv zu, dass Microsoft hier möglicherweise keine Zukunft sieht. Zum Glück, solange XAML und C# noch vorhanden sind, ist die Migration zu einem neuen Anwendungsmodell oder die Paketierung/Verteilung normalerweise relativ schnell. Wenn Avalonia nur fertig wäre...

Und wenn sie wirklich erfolgreich sein wollen, müssen sie es plattformübergreifend machen. Anderenfalls werden die Leute auf andere Frameworks umsteigen, und dann könnten sie irgendwann auch die Windows-Plattform vollständig verlassen. WinUI plattformübergreifend zu machen wäre ein Mittel, um Entwickler dazu zu bringen, sich an Windows zu halten.

Ich stimme dir auch zu 100% zu und habe gleich mehrere Stellen angegeben. Ich bin jedoch zu dem Schluss gekommen, dass dies aus mehreren Gründen nicht passieren wird.

Ich kann den Kommentaren der Kommentatoren nicht stark genug widersprechen:

WinUI 3.0 muss plattformübergreifend sein!

1) Wir brauchen jetzt ein UI-Framework, nicht in weiteren N Jahren, wenn das theoretische plattformübergreifende Projekt stabil ist.
2) Wir brauchen ein UI-Framework, das so nah wie möglich am Betriebssystem ist. Bei Cross-Plattform gibt es immer einen Kompromiss. Entweder kleinster gemeinsamer Nenner für die Funktionalität oder inkonsistentes Rendering von Steuerelementen aufgrund von benutzerdefiniertem Rendering.

Die Lösung besteht meiner Meinung nach darin, ein anderes Framework zu haben, das entweder auf WinUI 3.0 aufbaut (wenn Sie Fluent beibehalten möchten und wenig Arbeit beim Rendering, Hit-Tests usw. haben) oder von Grund auf mit WinUI Composition wenn Sie maximale Leistung erzielen möchten und es Ihnen nichts ausmacht, das gesamte Rendering und die Treffertests selbst durchzuführen (auf die potenziellen Kosten der Nichtkonsistenz).

Ich erinnere mich, dass ich vor einigen Tagen diese Zeilen gesehen habe:
"Das Betriebssystem ist für uns nicht mehr die wichtigste Schicht... Was für uns am wichtigsten ist, ist das App-Modell und das Erlebnis."
Es ist also offensichtlich, dass WinUI die beste GUI-Erfahrung sein sollte, und ich denke, dass es wie das Beste von WPF, UWP und Windows 10 sein wird.

Aber es ist offensichtlich, dass das Web und sein altes Javascript+HTML überall verwendet werden und ihre Web-Frameworks und -Stacks massiv genutzt werden, nicht weil sie besser sind, sondern weil sie im Telefon-Webbrowser und Desktop-Webbrowser leicht verfügbar sind. Sie können eine HTML-Datei in Notepad erstellen, ein Script-Tag mit einer Warnung einfügen ('Hello World'); und Sie haben eine App.

Ich sehe also, dass es möglich und sogar notwendig ist, es mithilfe von WebAssembly durch .NET + XAML zu ersetzen. .NET muss genauso allgegenwärtig sein wie JavaScript heute.

Silverlight war ein Licht der Hoffnung... und jetzt mit WebAssembly sehe ich, dass es möglich ist, zu Silverlight zurückzukehren.

Damit würde ich mich freuen:
WinUI ist die vollständige betriebssystemgestützte GUI und zumindest eine Teilmenge von XAML, die auf dem WebBrowser ausgeführt werden kann.

Daher halte ich das UNO-Team für sehr wichtig und hoffe, dass es sich Microsoft in naher Zukunft anschließen wird, um seine Kräfte bei dieser wunderbaren Anstrengung, der WinUI, zu bündeln.

@MarkIngramUK Yesssss

Machen Sie WinUI zur besten UI-Wahl für alle, die eine native Windows-Entwicklung in Betracht ziehen. Beenden:

• Eingabevalidierung und ein natives Datagrid-Steuerelement
• Die anderen ~170 Feature-Vorschläge hier
• Die anderen ~300 offenen Tickets
• .NET Native > .NET Core-Migration (für .NET Core 3+5, .NET Standard 2.1+ und C# 8...)
• Neuer AOT-Compiler
• Holen Sie sich kohärentere, fließende Designrichtlinien, die ausgespült und veröffentlicht werden
• Verfeinern Sie das Stil-/Themensystem
• Heben Sie ablenkende Kompositionsfunktionen (Neigung, starker Acrylverbrauch, Enthüllung) ab und konzentrieren Sie sich mehr auf das Tiefen- und Schattensystem und die Animationen (die Klarheit bringen und Benutzer anleiten)

Dies sind die Dinge, die WinUI in Zukunft für Leute attraktiver machen werden, die es im Vergleich zu Electron in Betracht ziehen.

Das i-Tüpfelchen wäre dann:

• Tool(s), um Ihr CSS <-> XAML-Styling synchron zu halten
• Richtlinien zum Trennen der App-Logik von Ansichten für eine maximale Wiederverwendung von .NET-Code auf anderen Plattformen
• Ein Tool zum Generieren einer einmaligen groben Übersetzung von HTML > XAML-Steuerelementen, um Entwicklern den Einstieg in ihre nativen WinUI-Apps zu ermöglichen (anstatt davon auszugehen, dass die meisten Entwickler mit XAML-Apps beginnen und den Wunsch haben, in Richtung HTML zu gehen)

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlight war plattformübergreifend, mit vollem Funktionsumfang und auf allen Plattformen genau gleich gerendert. Qt ist plattformübergreifend, voll funktionsfähig und rendert auf allen Plattformen genau gleich. Inkonsistentes Rendering und Steuerelemente des kleinsten gemeinsamen Nenners erhalten Sie nur, wenn Sie versuchen, Ihre Steuerelemente zu realisieren, indem Sie sie intern in native Steuerelemente einer anderen Plattform übersetzen (was Xamarin und Uno versuchen). Wenn Sie die Abstraktion nicht auf der Steuerungsebene, sondern auf der untersten Ebene (der GPU-Rendering-Ebene) durchführen, können Sie auf allen Plattformen mit dem vollständigen Steuerungssatz 100 % dieselbe Ausgabe erhalten. Das Kontrollset ist bereits vorhanden, es ist WinUI 3.0, und es ist auch jetzt noch großartig. Das einzige, was fehlt, sind Rendering-Layer-Implementierungen für die anderen Plattformen (und diese könnten teilweise aus alten Silverlight-Quellen stammen).

Ich würde wirklich gerne plattformübergreifende App-Entwicklung betreiben. Aber weder Xamarin noch Uno sehen für mich ansprechend aus und ich mag JS/HTML und alles was darauf basiert nicht wirklich. Leider ist die Entwicklung ausschließlich für den Windows Store eine schlechte Wahl, wenn Sie tatsächlich Geld damit verdienen möchten. Zumindest habe ich damit eher schlechte Erfahrungen gemacht, und nachdem Microsoft das Windows Phone-Ökosystem getötet hatte, habe ich es mehr oder weniger beendet (trotz kleiner "just for fun"-Projekte). Ich würde sofort wieder mit der Arbeit an neuen Apps beginnen, wenn WinUI plattformübergreifend wäre.

Alle aktuellen plattformübergreifenden Frameworks haben mehr oder weniger starke Einschränkungen und/oder eine schlechte Entwicklungserfahrung. Wenn Microsoft WinUI plattformübergreifend machen könnte, könnte es wirklich eine bahnbrechende Technologie sein. Xamarin ist trotz all seiner Ecken und Kanten und Einschränkungen bereits ziemlich erfolgreich. Stellen Sie sich vor, wie erfolgreich WinUI sein könnte, wenn es auf allen Plattformen mit vollem Funktionsumfang und der erstklassigen Visual Studio-Entwicklungserfahrung ausgeführt würde.

@lukasf , das ist mein Punkt:

Silverlight war plattformübergreifend, mit vollem Funktionsumfang und auf allen Plattformen genau gleich gerendert.

Ich möchte nicht das gleiche Rendering auf allen Plattformen. Ich möchte, dass jede Anwendung mit anderen Anwendungen auf der Zielplattform konsistent aussieht. Aus diesem Grund müssen die nativen Steuerelemente umbrochen werden - aber das führt dann zum kleinsten gemeinsamen Nenner.

@MarkIngramUK Ich sehe es so: Einfache Apps halten sich an die Standard-UI-Steuerelemente einer Plattform. Großartige Apps haben ihr eigenes Look+Feel. Sie benötigen keine Standardplattformsteuerungen. Schauen Sie sich Spotify, Netflix oder andere großartige und erfolgreiche Apps an, die für mehrere Plattformen verfügbar sind. Sie können die Plattform, die sie verwenden, nicht erkennen, indem Sie sich nur ihre Steuerelemente ansehen.

Ich möchte, dass meine plattformübergreifenden Apps auf allen Plattformen genau gleich aussehen und sich gleich anfühlen.

@MarkIngramUK Schön , dass Sie die Realität jenseits der Theorie berühren. Hier ist die Realität für mich: Ich habe eine Reihe von Apps, die sich aus SL/WP > WinRT > UWP entwickelt haben und gestern auf mehrere Plattformen abzielen mussten. Ich schaute mir Phonegap/Cordova an und verbrachte viel Zeit damit, Xamarin sehr ernsthaft zu erkunden, und gab schließlich auf. Ich habe mich aus vielen Gründen in Uno verliebt, sobald ich angefangen habe, es zu benutzen. Im Moment kenne ich keine andere vielversprechende praktische X-Plattform-Technologie, die C#- und Xaml-freundlich ist und die ich jetzt verwenden kann. Wenn sich WinUI 1, 2 oder 3 Jahre später zu einer X-Plattform-API entwickelt, werden die erstklassigen Uno-Leute Uno von UWP zu WinUI migrieren, und alle meine Uno-basierten Apps können entsprechend und schnell migriert werden. Ich habe jetzt nichts zu befürchten.
Ich bin keineswegs gegen spannende theoretische Diskussionen hier. Höre gerne alle möglichen Ideen.

Kann WinUI / MS das Blazor-Projekt nicht nutzen, um WinUI als "Blazor Native" App zu rendern?

Ich weiß, dass Steve Sanderson Blutter präsentiert hat, wo Googles Flutter mit Blazor gerendert werden kann (und das ist eine XML-basierte Benutzeroberfläche). Es scheint, dass das Blazor-Team einige nette Technologien auf der UI-Rendering-Seite hat, um verschiedene UI-Frameworks zu nutzen. Wenn Blazor mit Flutter umgehen kann, sollte es ein Äquivalent vom Typ WinUI / Sillverlight verarbeiten können.

Das Potenzial ist ein weniger fragmentiertes MS-Ökosystem und viel leistungsfähiger, angefangen beim Web bis hin zur nativen Apps-X-Plattform mit einem einheitlichen .net 5.

@lukasf :

@MarkIngramUK Ich sehe es so: Einfache Apps halten sich an die Standard-UI-Steuerelemente einer Plattform. Großartige Apps haben ihr eigenes Look+Feel. Sie benötigen keine Standardplattformsteuerungen. Schauen Sie sich Spotify, Netflix oder andere großartige und erfolgreiche Apps an, die für mehrere Plattformen verfügbar sind. Sie können die Plattform, die sie verwenden, nicht erkennen, indem Sie sich nur ihre Steuerelemente ansehen.

Ich möchte, dass meine plattformübergreifenden Apps auf allen Plattformen genau gleich aussehen und sich gleich anfühlen.

Wir kombinieren beide Ansätze für unsere Apps (https://affinity.serif.com). Unsere Kunden können ziemlich lautstark sein, wenn wir keine gängigen Plattformstandards übernehmen, z. B. die Reihenfolge der Schaltflächen in Dialogfeldern (Windows ist normalerweise OK, dann Abbrechen, während macOS Abbrechen und dann OK ist), Schaltflächen mit abgerundeten Ecken, Hover-Zustände, Kontrollkästchen vs. Schalter, Layout von Steuerelementen usw. Also ja, oberflächlich sehen unsere Apps auf Windows- und macOS-Plattformen gleich aus, aber wir haben subtile Unterschiede (Rendering und UI-Interaktion). Wir nutzen auch die Vorteile unserer Host-Plattform voll aus, indem wir ihre nativen APIs verwenden, und unterliegen daher nie den Problemen mit dem kleinsten gemeinsamen Nenner.

Ich denke immer noch, dass die obige Diskussion irreführend ist, WinUI ist das UI-Framework der niedrigsten Ebene, das Microsoft bereitstellt. Wenn Sie eine plattformübergreifende Bibliothek wünschen, bauen Sie darauf auf. Es ist das Äquivalent zu sagen: "Win32 sollte plattformübergreifend sein!". Nein, Win32 sollte das beste Framework für die Windows-Plattform sein. Es ist das gleiche Argument hier, WinUI sollte das beste Framework für die Windows 10-Plattform sein.

@MarkIngramUK schrieb:

WinUI ist das UI-Framework der niedrigsten Ebene, das Microsoft bereitstellt. Wenn Sie eine plattformübergreifende Bibliothek wünschen, bauen Sie darauf auf.

Das erscheint mir als praktische Lösung, die je nach Details wirklich gelingen könnte (wenn auch nicht unbedingt die einzige Lösung). Zwei Schichten:

1. Microsoft WinUI: Nicht plattformübergreifend.
2. Microsoft CrossXYZ-UI: Plattformübergreifend. Seine interne Implementierung für Windows würde mit WinUI geschrieben.

Eine solche 2-Schichten-Lösung würde dazu beitragen, das Problem zu mildern, das ich in meiner ursprünglichen Nachricht erwähnt habe:

Potenziell neue Versionen von WinUI können sich aufgrund des erhöhten Arbeitsaufwands/der Schwierigkeit, die Unterstützung für mehrere verschiedene Betriebssysteme aufrechtzuerhalten, erheblich verzögern. Zum Beispiel: "Wir hätten diese neue Version von WinUI schon vor Monaten veröffentlichen können, abgesehen von dem Problem, dass wir das Debuggen nur für Windows und noch nicht für Android, MacOS oder Apple iOS abgeschlossen haben."

Nach meinen Erfahrungen mit plattformübergreifender Entwicklung in der Vergangenheit würde ich anmerken, dass diese 2-Schichten-Lösung erfolgreicher wäre, wenn verschiedene Änderungen/Ergänzungen in WinUI implementiert werden, um das separate plattformübergreifende "CrossXYZ" zu unterstützen und zu unterstützen -UI"-Ebene. Andernfalls, wenn WinUI nichts tut, um die plattformübergreifende Ebene zu unterstützen, bedeutet dies meiner Erfahrung nach normalerweise, dass die plattformübergreifende Ebene oft gezwungen ist, durch verzerrte Reifen zu springen, die die Programmierung und Zuverlässigkeit erschweren und verzögern.

Gemäß der Layering-Theorie muss WinUI keine "CrossXYZ-UI" -Schicht kennen oder sich darum kümmern, die WinUI verwendet, aber diese Theorie funktioniert in der Praxis in der realen Welt schlecht, daher sage ich, dass WinUI berücksichtigen müsste und die "CrossXYZ-UI"-Ebene unterstützen, aber ich meine nicht die schreckliche Idee, Abhängigkeiten von "CrossXYZ-UI" in WinUI zu erstellen, und ich meine nicht spezielle private Hooks in WinUI, die nur von "CrossXYZ-UI" verwendet werden ". Die 2 Schichten sollten dennoch sauber getrennt gehalten werden. Ich sage nur, dass, wenn API-Entwurfsentscheidungen für WinUI getroffen werden, diese Entscheidungen unter Berücksichtigung ihrer Auswirkungen auf die separate "CrossXYZ-UI"-Schicht und unter Berücksichtigung dessen getroffen werden müssen, wie WinUI das Leben der " CrossXYZ-UI"-Layer, nicht nur mit Rücksicht auf Apps, die direkt WinUI verwenden.

Ich weiß nicht, ob Xamarin bereits versucht, auf die oben beschriebene 2-Schicht-Weise zu arbeiten, aber wenn dies der Fall ist, stelle ich mir vor, dass es derzeit den Teil der Idee ausschließt, bei dem WinUI die separate plattformübergreifende Schicht unterstützt/unterstützt. Es ist schwierig, Xamarin zu vertrauen, wenn Microsoft Xamarin nicht genug vertraut hat, um es für Microsoft Teams und verschiedene andere Microsoft-Apps zu verwenden.

In der Vergangenheit habe ich plattformübergreifende Software veröffentlicht, die erfolgreich und mit guter Leistung funktionierte, aber ich habe die plattformübergreifende Arbeit aus nicht-technischen Gründen abgebrochen. Die Kunden, die die Linux-Version der Software verwenden, bestanden beispielsweise darauf, dass der Preis der Software 0 US-Dollar betragen sollte. Somit überstiegen die Kosten für die Herstellung und Wartung der Linux-Version bei weitem die Einnahmen von $0 der "Kunden", die Linux verwenden, also war sie offensichtlich nicht tragbar.

Nur weil Sie als App-Entwickler theoretisch eine plattformübergreifende App _können_, bedeutet dies nicht immer, dass Sie _sollten_. Interessanterweise stelle ich heutzutage in plattformübergreifenden Diskussionen fest, dass die Leute Android erwähnen, aber nicht mehr Linux. Einer der Hauptgründe für diese Verschiebung ist wahrscheinlich das oben erwähnte 0-Dollar-Problem.

Re Uno-Plattform:

Selbst wenn Uno über ein solides, zuverlässiges technisches Design und Implementierung verfügt, besteht das Risiko und die Sorge darin, dass Uno innerhalb weniger Jahre aufgrund eines ähnlichen 0-Dollar-Problems oder unzureichender Einnahmen verschwinden könnte, was schließlich zu Burn-out und Projektabbruch oder Stagnation führt. Oder einfach der wichtigste Entwickler von Uno eines Tages plötzlich ein neues Hobby/Interesse/Besessenheit bekommt und das Interesse an Uno verliert oder einen neuen Job/Arbeitgeber und keine Zeit mehr hat, an Uno zu arbeiten. Wie @mdtauk sagte:

Viele Unternehmen, die in die Entwicklung einer App oder eines Systems investieren möchten, müssen wissen, dass die Plattform, für die sie entwickeln, die Unterstützung und Langlebigkeit eines großen Unternehmens mit umfangreichen Ressourcen wie Microsoft bietet.

Ich würde auch dem anderen Kommentar von @mdtauk zustimmen:

Das Problem mit diesem Argument ist, dass Microsoft in den letzten zehn Jahren gezeigt hat, dass es Plattformen aufgegeben hat,

Ja, Microsoft hat durch die Einstellung von Plattformen einen gewissen Grad an Ruf/Vertrauenswürdigkeit/Verlässlichkeit verloren. Ich denke, Microsoft muss vorsichtig sein, um einen weiteren Verlust an Reputation und Vertrauenswürdigkeit durch weitere Stornierungen zu vermeiden. Eine neue Version einer bestehenden Plattform ist besser als eine neue Plattform.

Selbst wenn eine große neue Version einer bestehenden Plattform bahnbrechende Änderungen einführen muss, ist sie immer noch besser (oder weniger schlecht) als eine neue Plattform mit dem damit einhergehenden Verlust an Reputation/Vertrauenswürdigkeit/Zuverlässigkeit. Für App-Entwickler sind die Kosten für den Wechsel zu einer neuen Plattform sehr hoch und manchmal völlig unerschwinglich. Wenn Microsoft eine Plattform kündigt, ist dies daher eine sehr schlechte Nachricht und schadet der Beziehung/Partnerschaft zwischen dem App-Entwickler und Microsoft.

Wenn Sie diesen zweischichtigen Ansatz so ansprechend finden, können Sie jetzt weitermachen und Xamarin oder Uno verwenden. Auf solche Frameworks muss man nicht warten, sie sind bereits da und funktionieren sehr gut. Aber Sie werden alle Vorteile und Verbesserungen von WinUI verlieren, sobald Sie Android oder iOS als Ziel haben. Kein NavigationView mehr, keine AppBars, kein SemanticZoom, etc etc. Alles was in diesem Repo gemacht wird, alle Verbesserungen sind nicht plattformübergreifend verfügbar, da plattformübergreifend dann der kleinste gemeinsame Nenner ist. Sie können sie nur verwenden, wenn Sie speziell auf die Windows-Plattform abzielen. Sie müssen also alle coolen WinUI-Sachen erneut manuell neu implementieren, indem Sie native Android- oder iOS-Steuerelemente verwenden.

Wenn das für Sie gut klingt, verwenden Sie einfach Xamarin oder Uno. Es besteht keine Notwendigkeit für einen dritten Rahmen wie diesen. Aber für mich klingt das alles andere als gut. Ich möchte ein Framework mit einem großartigen Kontrollsatz, mit dem alle Plattformen direkt angesprochen werden können, mit voller Funktionalität auf jeder Plattform. Ich möchte die Navigation und die Dinge meiner App nicht auf jeder Plattform separat neu implementieren, da ich komplizierte und doppelte UI-Definitionen habe. Für mich klingt das nach einer schrecklichen Idee. Wenn WinUI plattformübergreifend mit dem Renderer-Ansatz wäre, könnte ich alle seine Funktionen und jede Verbesserung hier auf jeder Plattform direkt nutzen. Und wenn ich möchte, dass meine Steuerelemente auf diesem Ziel eher wie iOS aussehen, könnte ich einfach ein iOS ResourceDictionary anwenden. Problem gelöst, ohne sich mit nativen Steuerelementen und doppelten UI-Implementierungen herumschlagen zu müssen.

Das Argument, dass Veröffentlichungen verzögert würden, weil ein "Renderer für andere Plattformen nicht aktualisiert wurde" ist ein unrealistisches Argument. Eine Rendering-Ebene funktioniert mit Zeichenbefehlen auf niedriger Ebene wie "Rechteck zeichnen, Linie zeichnen, Text zeichnen". Wenn Sie WinUI ein neues Steuerelement hinzufügen, schreiben Sie Ihre Steuerelementlogik und stellen eine Steuerelementvorlage bereit, die Grid, Borders, TextBoxes und ähnliches verwendet. Keine neue Steuerung erfordert Aktualisierungen der Renderer, die Renderer sind sehr niedrig und mit sehr geringer Änderungsrate. Nur in seltenen Fällen müssen die Renderer berührt werden, zB beim Hinzufügen neuer Pinsel oder Effekte. Qt verwendet den Renderer-Ansatz und ist eines der beliebtesten plattformübergreifenden UI-Frameworks. Der Ansatz scheint für sie sehr gut zu funktionieren.

@lukasf

Ich möchte ein Framework mit einem großartigen Kontrollsatz, mit dem alle Plattformen direkt angesprochen werden können, mit voller Funktionalität auf jeder Plattform.

Jeder Ingenieur und jeder Dollar, der ausgegeben wird, um WinUI plattformübergreifend zu machen, ist ein Ingenieur und jeder Dollar, der verwendet werden könnte, um WinUI unter Windows zu verbessern.

Das Argument, dass Veröffentlichungen verzögert würden, weil ein "Renderer für andere Plattformen nicht aktualisiert wurde" ist ein unrealistisches Argument.

Es ist nicht nur eine einfache Aufgabe, eine perfekte 1:1-Rendering-Engine zu erstellen, die auf iOS, Android, MacOS, Linux und Windows 7/8 funktioniert. Es gibt eine enorme Anzahl von Windows 10-APIs, auf die sich Apps und das Framework verlassen. Sie würden im Wesentlichen ein völlig neues App-Framework erstellen.

Sehen Sie sich auch diesen aktuellen Reddit-Thread an: Was sollte ich für die Benutzeroberfläche in C# verwenden

Buchstäblich null Erwähnungen von WinUI und eine einzige halbe Empfehlung zur Verwendung von UWP. Entwickler müssen von der Verwendung von WinUI unter Windows begeistert sein, lange bevor sie versuchen, es plattformübergreifend zu machen, wenn man bedenkt, dass all die riesigen Investitionen erforderlich sind.

@lukasf ,

Sie können sofort fortfahren und Xamarin oder Uno verwenden

Ich habe in meinem vorherigen Beitrag darauf angespielt, aber wir schreiben separate Frontends für jede Plattform, die wir ansprechen. Windows (WPF), macOS (Kakao), iOS (UIKit).

Wenn ich möchte, dass meine Steuerelemente auf diesem Ziel eher wie iOS aussehen, könnte ich einfach ein iOS ResourceDictionary anwenden. Problem gelöst

Bis der Benutzer sein Betriebssystem aktualisiert und alle Apps mit Ausnahme Ihrer das Aussehen ändern.

Ein Rendering-Layer funktioniert mit Zeichenbefehlen auf niedriger Ebene wie ...

Sie brauchen mehr als nur plattformübergreifendes Rendern. Fensterverwaltung, Eingabe, Textverarbeitung, Rendering, Systemintegration (zB Taskleiste / Aero Peek etc). Es gibt keine Möglichkeit, dass der Versuch, den Fokus von WinUI von Windows-only auf plattformübergreifend zu ändern, keine extreme Verzögerung verursachen würde.

In Bezug auf das Rendering basiert WinUI auf Windows.UI.Composition , so dass Sie diese untergeordnete Bibliothek vollständig durch etwas ersetzen müssten, das plattformübergreifend war und hoffentlich keine Leistungseinbußen durch Ihre Abstraktion erleiden würde, und dann portieren es auf andere Plattformen. Oder schreiben Sie WinUI komplett neu, um nicht von Windows.UI.Composition abhängig zu sein. Wieder kein kleiner Job.

Nur um es noch einmal zu wiederholen - ich bin nicht gegen plattformübergreifende Bibliotheken. Sie dienen einem Zweck, ich glaube nur nicht, dass WinUI einer werden sollte.

@lukasf

denn plattformübergreifend bedeutet dann der kleinste gemeinsame Nenner. …... Ich möchte ein Framework mit einem großartigen Kontrollsatz, mit dem alle Plattformen direkt angesprochen werden können, mit voller Funktionalität auf jeder Plattform.

Sie wollen es mit voller Funktionalität auf jeder Plattform – ich auch – klingt wunderbar; ein Traum – aber nur weil du und ich es wollen, heißt das nicht, dass es möglich und praktisch sein muss. Der Wunsch und das Ergebnis können sehr unterschiedlich sein. Der Wunsch könnte volle Funktionalität sein, während das Ergebnis meist das gleiche Problem ist, wie Sie es erwähnt haben - kleinster gemeinsamer Nenner. Ihre Idee hat ihre Berechtigung, ist aber nicht immun gegen das von Ihnen erwähnte Problem mit dem kleinsten gemeinsamen Nenner.

Wenn WinUI plattformübergreifend mit dem Renderer-Ansatz wäre, könnte ich alle seine Funktionen und jede Verbesserung hier auf jeder Plattform direkt nutzen.

Wirklich ALLE Funktionen und JEDE Verbesserung auf JEDER Plattform? Sind Sie sicher, dass ein so beeindruckendes Ziel allein dadurch erreicht werden kann, dass WinUI auf einem plattformübergreifenden Renderer basiert? So einfach ist die Lösung? Ich denke, Sie lassen die Idee viel einfacher erscheinen, als sie in Wirklichkeit ist, denn tatsächlich ist viel mehr als der Renderer erforderlich, wie zum Beispiel:

• Fensterverwaltung plus Flyouts, Popups, Kontextmenüs, modale Dialoge.
• Anzeigeverwaltung und Auflösungen und Reaktion auf Änderungen.
• Eingabegeräte (Tastatur, Maus, Touchscreen mit Gesten, Stift).
• Animation.
• Schriftarten und Stile, Informationen und Maße abrufen, nicht nur rendern. Auch Unicode-Textverarbeitung.
• Ziehen und ablegen.
• Ausschneiden/Kopieren/Einfügen der Zwischenablage, die mit verschiedenen Formaten funktioniert, nicht nur mit Text.
• Scrollen mit guter Leistung, im Gegensatz zu der schrecklichen Scrollleistung von Chat-Fenstern in MS Teams.
• Lesen/Laden von Ressourcen (verschiedener Art), die im App-Paket gespeichert sind, wie Bildressourcen und andere.
• Audio- und Videowiedergabe.
• Automatisierung für Bildschirmlesegeräte usw. für Barrierefreiheit.
• Thema/Aussehen im Einklang mit dem, was derzeit im Betriebssystem konfiguriert ist.
• Abrufen verschiedener Betriebssystemeinstellungen, die sich auf die GUI auswirken, z. B. internationale Formatierung, Maus- und Tastatureinstellungen usw.
• Probleme bei der Unterstützung von Mobilgeräten plus Tablets plus Desktops.
• Und verschiedene andere Dinge sowie Hunderte von Details, die bei der Schätzung der Projektgröße und des Veröffentlichungsdatums leicht vergessen werden.

Ich denke immer noch, Ihre Idee hat ihre Berechtigung, aber sie ist viel schwieriger und viel weniger klar, als Sie es erscheinen ließen. Es könnte auch die Entwicklung und den Fortschritt von WinUI sehr verlangsamen.

Kann WinUI / MS das Blazor-Projekt nicht nutzen, um WinUI als "Blazor Native" App zu rendern?

@pinox , ja, das könnten wir definitiv, aber dann wäre Blazor Native nicht plattformübergreifend, es sei denn, sie zielten auf Uno ab (was meine persönliche Präferenz wäre).

Cross-Plat ist definitiv etwas, über das wir nachgedacht haben, und wir haben einige ziemlich gründliche Untersuchungen verschiedener plattformübergreifender Framework-Architekturen durchgeführt. Wir sind zu den gleichen Schlussfolgerungen gekommen, die alle in diesem Thread haben, nämlich dass beide Lösungen Vor- und Nachteile haben und unsere Kunden ziemlich gespalten sind 😃

@lukasf Ich denke, der "kleinste gemeinsame Nenner", der derzeit in Uno existiert, ist ein Problem mit der Ressourcenbeschränkung und nicht auf die Schichtung zurückzuführen. Ich würde gerne das Gegenteil beweisen, aber ich denke, dieses Problem könnte gelöst und in Zukunft nicht noch verschlimmert werden.

Es gibt eine Teilmenge von XAML, um das Rendern von nativ aussehenden UI-Steuerelementen und -Fenstern anzubieten – oder Sie könnten den Renderer auf macOS, iOS, Android, Linux besitzen – und die gleichen "fließenden" Steuerelemente und Vorlagen auf allen Plattformen rendern.

Abgesehen davon, dass eine Variante der CoreWindow / App Window-Implementierung mit dem nativen Betriebssystem funktioniert, kann alles innerhalb des Fensters gerendert werden.

Unter Windows ist es DirectX, aber Apple hat Metal und Linux hat OpenGL. Entwickler müssten eine Art von IF-Anweisungen ausführen, um native Datei-IO, Benachrichtigungen usw. zu verarbeiten - aber Xamarin würde dabei helfen

@stevenbrix -- Sie haben auf die Idee von @Pinox _"WinUI als native Blazor-App rendern"_ geantwortet,_ aber was halten Sie von Pinox ' _anderer_ Idee? Interessanterweise schrieb @Pinox auch:

Electron verwendet derzeit Javascript, HTML + CSS. Kein Grund, warum wir Electron nicht mit Blazor => C# , HTML + CSS + gRPC verwenden können.

@Pinox -- Ich würde zustimmen, dass "Electron C#" viel sinnvoller zu sein scheint als "Electron JS", aber wenn es C# und Blazor verwendet, wie Sie es vorgeschlagen haben, dann würde die MS Teams-App wahrscheinlich Electron nicht benötigen mehr, weil Blazor Electron komplett ersetzen würde? Ich könnte mich irren – ich weiß nicht genug darüber, welche Funktionen Electron unterstützt. Wenn ElectronJS derzeit jedoch über eine nützliche Funktion verfügt, die Blazor fehlt, könnte diese fehlende Funktion möglicherweise in der nächsten Version von Blazor unterstützt werden.

Ich nehme an, Sie haben einen wichtigen Punkt angesprochen, indem Sie Blazor erwähnt haben. Eine anständige Lösung für die MS Teams-App könnte sein, von ElectronJS zu Blazor + WebAssembly zu wechseln. Das ist wirklich interessant.

Wenn die MS Teams-App von ElectronJS zu Blazor wechselt, verwendet sie möglicherweise einen Teil von WinUI oder auch nicht. Entweder eine Verbindung oder eine Nichtverbindung zwischen Blazor und WinUI könnte weiter untersucht werden, wie Sie es bereits getan haben. Interessant!

Silverlight, WinRT, UWP - wurden alle aufgegeben. (Ich weiß, dass UWP technisch nicht funktioniert, aber WinUI wird höchstwahrscheinlich als Ersatz angesehen).

Mein Verständnis ist, dass UWP die Laufzeit ist, während WinUI die GUI / Widget-Schicht / etc. ist. D. h. Win UI wird auf Win32 oder .NET ohne die UWP-API ausgeführt.

Was mich wahnsinnig macht, ist, dass UWP eigentlich eine ziemlich kompetente API ist. Es ist nicht so leistungsstark wie Win32, aber im Vergleich zu Android (zum Beispiel) ist es so viel vernünftiger. Ich denke, Entwickler haben den Punkt übersehen, dass es jetzt eine einheitliche Laufzeit-API gibt, die ein konsistentes Objektmodell, eine konsistente API hat, nicht stumpf ist usw 00s bevor .NET in Erscheinung trat? Die Verwendung der nativen Plattform-APIs war schrecklich.

Zurück zum vorliegenden Problem, ich würde WinUI unbedingt plattformübergreifend sehen. Es gibt Posts darüber, dass es an COM usw. gebunden ist ... Apples Core Foundation Plugin (CFPlugin) Framework ist IIRC, basiert auf COM, also wäre ein Lift and Shift vielleicht so einfach wie das Schreiben eines Renderers für Apple-Plattformen. Logischer wäre es, die Plattformunterschiede zu verbergen und die WinUI-Objekte auf hoher Ebene beizubehalten.

Ich würde gerne eine zusammenhängende, plattformübergreifende Anstrengung von Microsoft sehen, die hauptsächlich auf Windows abzielte, aber ein vollständig kompatibles Objektmodell und einen XAML-Dialekt für Mobilgeräte, Linux und macOS gekauft hat. In .NET Core gibt es bereits ein fantastisches plattformübergreifendes Ökosystem (ohne GUI). Wenn Sie ein kompetentes XAML-Framework anbringen, wäre dies ein Kinderspiel für die gesamte clientseitige Entwicklung, insbesondere wenn die Visuals nativ aussehen könnten. Zum Beispiel CommandBar -> NSToolbar-Darstellung auf einem Mac, Navigationsansicht -> NSOutlineView auf einem Mac usw.

Mein Wert von 2 Cent, aber ich sehe einen großen Fokus darauf.

Ich hoffe auch (obwohl ich nicht den Atem anhalte), dass Microsoft mit einem Windows-basierten Telefon wieder auf den Markt kommt. Eine überzeugende plattformübergreifende Umgebung würde dieses Ziel massiv unterstützen.

Ich werde diese Diskussion mit Interesse verfolgen.

Silverlight, WinRT, UWP - wurden alle aufgegeben. (Ich weiß, dass UWP technisch nicht funktioniert, aber WinUI wird höchstwahrscheinlich als Ersatz angesehen).

Mein Verständnis ist, dass UWP die Laufzeit ist, während WinUI die GUI / Widget-Schicht / etc. ist. D. h. Win UI wird auf Win32 oder .NET ohne die UWP-API ausgeführt.

Technisch gesehen denke ich, dass WinRT (Windows RunTime) die Laufzeit ist, und die UWP (Universal Windows Platform) baut auf dieser Laufzeit auf. Und UWP unterstützt die Verwendung von XAML als ein UI-Framework.

WinUI wird der XAML-Teil von UWP sein, aber erweitert, um die Verwendung mit Win32-Code zu ermöglichen, mit Interop über XAML Islands mit den WPF- und WinForms-Frameworks.

Was mich wahnsinnig macht, ist, dass UWP eigentlich eine ziemlich kompetente API ist. Es ist nicht so leistungsstark wie Win32, aber im Vergleich zu Android (zum Beispiel) ist es so viel vernünftiger. Ich denke, Entwickler haben den Punkt übersehen, dass es jetzt eine einheitliche Laufzeit-API gibt, die ein konsistentes Objektmodell, eine konsistente API hat, nicht stumpf ist usw 00s bevor .NET in Erscheinung trat? Die Verwendung der nativen Plattform-APIs war schrecklich.

UWP basiert auf einem modernen Ansatz für Akkulaufzeit, Sicherheit, Identität und Speichervalidierung – all das, was Entwickler von Plattformen wie macOS, iOS und Android erwarten. Aufgrund dieser inhärenten Eigenschaften kann es über viele Formfaktoren und Gerätetypen hinweg funktionieren.

Zurück zum vorliegenden Problem, ich würde WinUI unbedingt plattformübergreifend sehen. Es gibt Posts darüber, dass es an COM usw. gebunden ist ... Apples Core Foundation Plugin (CFPlugin) Framework ist IIRC, basiert auf COM, also wäre ein Lift and Shift vielleicht so einfach wie das Schreiben eines Renderers für Apple-Plattformen. Logischer wäre es, die Plattformunterschiede zu verbergen und die WinUI-Objekte auf hoher Ebene beizubehalten.

Wenn Sie die .NET Core-Unterstützung berücksichtigen, die bereits plattformübergreifend unterstützt wird, fehlt die UI-Ebene. WinUI konzentriert sich zunächst vollständig auf Windows, aber hoffentlich kann Microsoft es mit der Zeit so umgestalten, dass Plattformen ihr eigenes Rendering ersetzen können, wodurch identische Benutzeroberflächen auf mehreren Plattformen ausgeführt werden können.

Ich würde gerne eine zusammenhängende, plattformübergreifende Anstrengung von Microsoft sehen, die hauptsächlich auf Windows abzielte, aber ein vollständig kompatibles Objektmodell und einen XAML-Dialekt für Mobilgeräte, Linux und macOS gekauft hat. In .NET Core gibt es bereits ein fantastisches plattformübergreifendes Ökosystem (ohne GUI). Wenn Sie ein kompetentes XAML-Framework anbringen, wäre dies ein Kinderspiel für die gesamte clientseitige Entwicklung, insbesondere wenn die Visuals nativ aussehen könnten. Zum Beispiel CommandBar -> NSToolbar-Darstellung auf einem Mac, Navigationsansicht -> NSOutlineView auf einem Mac usw.

Sobald Sie es auf diese Weise betrachten und Windows in plattformnative Steuerelemente und Konzepte übersetzen, landen Sie bei Xamarin Forms. Sie streben einen Ansatz mit dem kleinsten gemeinsamen Nenner an, anstatt zuzulassen, dass eine identische Benutzeroberfläche überall ausgeführt wird.

Mein Wert von 2 Cent, aber ich sehe einen großen Fokus darauf.

Ich hoffe auch (obwohl ich nicht den Atem anhalte), dass Microsoft mit einem Windows-basierten Telefon wieder auf den Markt kommt. Eine überzeugende plattformübergreifende Umgebung würde dieses Ziel massiv unterstützen.

Ich werde diese Diskussion mit Interesse verfolgen.

Ich denke, ein Teil dieser Geschichte, der noch detailliert werden muss, besteht darin, dass UWP-Apps auf Android kompiliert und ausgeführt werden können – was das Problem der Apps lösen würde, die auf dem Surface Duo ausgeführt werden.

Da war das Astoria-Projekt... Die Android on Windows Bridge, die zu Windows kommen könnte, um Android-Apps in den Microsoft Store zu bringen. Sobald Microsoft eine eigene Android-Codebasis hat, ist die Vorstellung leichter.

Ich sehe, Sie haben auf die Idee von @Pinox "WinUI als native Blazor-App rendern" geantwortet, aber was halten Sie von der anderen Idee von Pinox? Interessanterweise schrieb @Pinox auch:

Electron verwendet derzeit Javascript, HTML + CSS. Kein Grund, warum wir Electron nicht mit Blazor => C# , HTML + CSS + gRPC verwenden können.

Ich würde zustimmen, dass "Electron C#" viel sinnvoller zu sein scheint als "Electron JS", aber wenn es C# und Blazor verwendet, wie Sie es vorgeschlagen haben, dann würde die MS Teams-App wahrscheinlich Electron nicht mehr brauchen, weil Blazor dies tun würde Elektron komplett ersetzen? Ich könnte mich irren – ich weiß nicht genug darüber, welche Funktionen Electron unterstützt. Wenn ElectronJS derzeit jedoch über eine nützliche Funktion verfügt, die Blazor fehlt, könnte diese fehlende Funktion möglicherweise in der nächsten Version von Blazor unterstützt werden.

@verelpode wie ich es verstehe, muss Electron immer im Bild sein. Wenn Teams hypothetisch zu Blazor wechseln würden, würden sie immer noch eine eigenständige Client-App wie heute wollen, und Electron ist für sie am sinnvollsten. Theoretisch kann mich jemand korrigieren, wenn ich falsch liege, aber der Wechsel zu Blazor + WebAssembly würde die App-Leistung bei der Ausführung in Electron viel besser machen. Obwohl ich wetten würde, dass ihre Leistungsprobleme mehr als alles andere auf Architekturprobleme zurückzuführen sind, ist VS Code eine Electron-App und ich bin von der Leistung dort sehr beeindruckt.

Beachten Sie, dass WebAssembly auch außerhalb des WebBrowsers ausgeführt werden kann...
Ich sehe Blazor als einen Weg von denen, die von ASP.Net kommen, einem Experiment, das .NET in den WebBrowser bringt, aber der vollständigste Pfad wäre XAML auf .NET Core, Xamarin, UWP/WinUI und UNO; Das vollständige XAML auf WinUI /Windows 10 und ein Teil seines XAML können auch im Web ausgeführt werden.

@verelpode @stevenbrix Mein Verständnis ist, dass Blazor in Electron auf dem Draht läuft. Also direkt vom .net-Kern zu Electron unter Verwendung von gRPC. Daher kommuniziert der gRPC-Kanal mit Elektron und nicht mehr mit dem JS-Renderer, den ich annehme. Bitte korrigieren Sie mich, wenn ich falsch liege. Es ist kein WASM beteiligt.

Es wäre wirklich interessant, die Geschwindigkeitsverbesserungen zu sehen, die gRPC direkt mit Electron verwenden. Meiner Meinung nach kann es massiv sein, wenn es optimiert wird.

Im Youtube-Clip von Steve Sanderson erwähnt er die Verwendung von WASM (53:13 min im Video)
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Ich kann mich nicht erinnern, wo ich den gRPC-Teil gelesen habe. Wie auch immer, deshalb habe ich die Community untersucht, ob so etwas wie ein Silverlight-Äquivalent von WinUI mit gRPC mit Electron möglich ist? Kein WASM , sozusagen am Kabel.

@verelpode @stevenbrix Mein Verständnis ist, dass Blazor in Electron auf dem Draht läuft. Also direkt vom .net-Kern zu Electron unter Verwendung von gRPC. Daher kommuniziert der gRPC-Kanal mit Elektron und nicht mehr mit dem JS-Renderer, den ich annehme. Bitte korrigieren Sie mich, wenn ich falsch liege. Es ist kein WASM beteiligt.

Es wäre wirklich interessant, die Geschwindigkeitsverbesserungen zu sehen, die gRPC direkt mit Electron verwenden. In meinen Augen kann es massiv sein.

Im Youtube-Clip von Steve Sanderson erwähnt er die Verwendung von WASM ( 53:13 min ) im Video.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Danke @Pinox! Sieht so aus, als hätte ich etwas zu beobachten! Was Sie beschreiben, klingt für mich nach serverseitigem Blazor, ich dachte / sprach über Client-Seite, die im Browser ausgeführt wird und das DOM direkt manipuliert. Ich sage nichts mehr, bis ich das Video gesehen habe, weil ich mit solchen Dingen meinen Fuß in den Mund stecken könnte 😄

@stevenbrix Sie könnten Recht haben, aber die Electron-App läuft offline, daher gehe ich davon aus, dass dies kein serverseitiges Rendering ist.

Ich vermute, wenn der JS-Renderer gRPC verwendet, um mit Electron zu sprechen, können Sie die Blazor-Razor-Engine verwenden, um dasselbe zu tun.

gRPC ist eine neue Funktion in .net Core 3.0. Blazor unterstützt .net Core 3.
Daher eröffnet gRPC in .net core 3 die Möglichkeit, bestehende JS-Technologien durch c# zu ersetzen, indem der "common link" (gRPC) verwendet wird. Cleverer Move MS ;))

aber die Electron-App läuft offline, daher gehe ich davon aus, dass dies kein serverseitiges Rendering ist.

@Pinox - ja das hat mich ein bisschen verwirrt. Ich vermute, dass es https://github.com/ElectronNET/Electron.NET verwendet, aber das ist rein spekulativ

Wenn die MS Teams-App von ElectronJS zu Blazor gewechselt hat, verwendet sie möglicherweise einen Teil von WinUI oder auch nicht. Entweder eine Verbindung oder eine Nichtverbindung zwischen Blazor und WinUI könnte weiter untersucht werden, wie Sie es bereits getan haben. Interessant! >

@verelpode Was dieses Bild sehr spannend macht, ist die "Reichweite" von Blazor. Als App-Typ kann ich sagen, dass meine bisher begrenzte Erfahrung mit Blazor => wow, das fühlt sich extrem performant an, fast wie eine App. Wenn man sich das Bild ansieht, wird die Roadmap mit ziemlicher Sicherheit WinUI als native Plattform enthalten. (obwohl derzeit nicht festgeschrieben)

Wenn sie Flattern auf der Blazor Native-Seite zum Laufen bringen können, was hindert das Blazor-Team daran, die React Native-Plattform anzuschließen, um all diese nativen Plattformen zu erreichen. Blazor kann für C#-Entwickler sehr leicht zum Klebstoff für alles werden.

Für mich ist das kurzfristige Ziel, mit einer HTML-Benutzeroberfläche in den Bus einzusteigen, um meine vorhandene WinUI zu ergänzen.
Zwischen WinUI / Xamarin und Blazor gibt es fast nichts, was ich nicht tun kann. Eine Codebasis, 3 UI-Frameworks. Es wird extrem spannend zu sehen, wohin dies führt, denn die Optionen scheinen endlos zu sein.

Für mich ist das Ultimative immer super performanter .net Core (C#) => Blazor ??? => native UIs - es wird der ultimative Entwicklungsaufwand sein.

Ich muss sagen, das ist eine sehr inspirierende Diskussion! Viele unterschiedliche Ansichten und Argumente, viele Fakten, die ich nicht einmal kannte ("Blazor + Native UI?? Wow").

Wie @stevenbrix bereits erwähnt hat, scheint es in der Community eine Spaltung zwischen denen zu geben, die genau dieselbe Benutzeroberfläche auf verschiedenen Frameworks ausführen möchten (Renderer-Ansatz) und denen, die auf jeder Plattform mit den nativen Steuerelementen rendern möchten. Beide Ansätze haben ihre Vor- und Nachteile. Ich stimme @stevenbrix zu, dass mit genügend Arbeitskräften das Problem des "kleinsten gemeinsamen Nenners" gelöst werden könnte (z. oder mit teilweise benutzerdefiniertem Rendering). Dann könnten wir fast den vollständigen WinUI-Steuerungssatz zur Verfügung haben, aber immer noch natives Rendering erhalten. Leider scheinen die Ressourcen von Uno angesichts der großen Anzahl offener Probleme auf ihrem Github derzeit ziemlich begrenzt zu sein.

Hier ist offensichtlich, dass in der Community ein hoher Bedarf an einem überzeugenden, leistungsstarken und plattformübergreifenden Framework besteht. Und keines der derzeit verfügbaren Frameworks kann eine der beiden Seiten der (gespaltenen) Community wirklich zufriedenstellen. Es wird sehr interessant sein zu sehen, ob Microsoft Pläne hat, die Situation zu verbessern.

Ich würde sagen, mit Surface Duo und Neo am Horizont muss sich Microsoft eine richtige Geschichte einfallen lassen, wie man plattformübergreifende Apps entwickelt, die sowohl auf dem Surface Duo als auch auf dem Surface Neo laufen. Vielleicht sollte Microsoft Uno kaufen und es angemessen finanzieren, damit sie all diese offenen Probleme beheben und mehr Kontrollunterstützung hinzufügen können. Oder entwickeln Sie einen Android-Rendering-Layer für WinUI. Mit Geräten, die für den Urlaub 2020 geplant sind, muss es ziemlich bald losgehen.

@lukasf

mit genügend Manpower könnte das Problem des "kleinsten gemeinsamen Nenners" überwunden werden

Genug Manpower ... Ich stimme allem in Ihrer Nachricht zu, möchte aber auch den erheblichen Nachteil hervorheben, den @kmgallahan erwähnt hat:

Jeder Ingenieur und jeder Dollar, der ausgegeben wird, um WinUI plattformübergreifend zu machen, ist ein Ingenieur und jeder Dollar, der verwendet werden könnte, um WinUI unter Windows zu verbessern.

Ich bin gespalten, weil einerseits plattformübergreifend großartig wäre (wenn es wirklich gut funktioniert), aber andererseits würde ich nicht plattformübergreifend sein wollen, wenn es zu großen Verzögerungen bei der Behebung verschiedener Probleme in WinUI führt unter Windows, oder wenn es den Fortschritt von WinUI zu sehr verzögert und Verbesserungen und neue Funktionen verhindert.

Was ist, wenn das plattformübergreifende Thema dazu führt, dass wir alle gezwungen sind, zwischen einem der folgenden Ergebnisse zu wählen?

1. Eine ausgezeichnete Version von WinUI, die nur unter Windows läuft; oder
2. Mittlere Qualität, unzuverlässige und/oder langsame WinUI, die auf jeder Plattform läuft und die unter einem quälend langsamen Entwicklungstempo leidet, wobei viele ausstehende Probleme 5 bis 10 Jahre lang nicht behoben werden.

Das ist ein großes Problem, das verhindert werden muss. In der Begeisterung für Cross-Plattform ist es sehr einfach, aus Versehen aufzuhören, auf die Vorbeugung dieses großen Problems zu achten.

Was ist, wenn das plattformübergreifende Thema dazu führt, dass wir alle gezwungen sind, zwischen einem der folgenden Ergebnisse zu wählen?

1. Eine ausgezeichnete Version von WinUI, die nur unter Windows läuft; oder

2. Mittlere Qualität, unzuverlässige und/oder langsame WinUI, die auf jeder Plattform läuft und die unter einem quälend langsamen Entwicklungstempo leidet, wobei viele ausstehende Probleme 5 bis 10 Jahre lang nicht behoben werden.

@verelpode Zuerst übertreibst du hier sehr. Zweitens: Microsoft verfügt über enorme Ressourcen. Es sollte überhaupt kein Problem sein, sowohl native WinUI-Verbesserungen als auch eine plattformübergreifende Lösung zu finanzieren, wenn Microsoft wirklich daran interessiert ist, ein plattformübergreifendes Framework bereitzustellen. Tatsächlich tun sie das gerade: Sie entwickeln und verbessern WinUI und gleichzeitig entwickeln und verbessern sie Xamarin. Sie haben viele Projekte gleichzeitig am Laufen. Wenn Microsoft also wirklich daran interessiert ist, sowohl ein großartiges Windows-UI-Framework (was sie sicher sind) als auch ein plattformübergreifendes Framework bereitzustellen (was mit Surface Neo und Duo am Horizont viel Sinn machen würde), dann haben wir es nicht wählen. Beides ist kompromisslos realisierbar. (Und im Allgemeinen ist es nicht so, dass wir uns dies aussuchen können. Microsoft wird ihre Entscheidungen treffen und wir werden sehen, was das Ergebnis ist.)

Die Finanzierung eines plattformübergreifenden Frameworks bedeutet also keineswegs, dass die Entwicklung und Stabilität von WinUI darunter leiden müssten. Wenn die Uno-Strategie gewählt wurde, ist Uno völlig unabhängig von WinUI, da es oben sitzt. WinUI kann weiterentwickelt werden, und Uno versucht, neue WinUI-Steuerelemente und -Konzepte aufzunehmen (wahrscheinlich langsamer). Auch wenn ein Renderer-Ansatz gewählt wurde, bedeutet dies nicht, dass WinUI unter Windows verzögert wird. Es könnte sein, dass eine neue WinUI-Version veröffentlicht wird, es aber noch keinen Android-Renderer gibt. Dann würde die plattformübergreifende Entwicklung die ältere WinUI-Version verwenden, bis der Android-Renderer auf WinUI vLatest aktualisiert wird. Windows-Entwickler könnten WinUI vLatest von Anfang an nutzen. Wenn die Ressourcen vorhanden sind, können beide im gleichen Tempo entwickelt werden.

@lukasf

Microsoft verfügt über enorme Ressourcen.

Stimmt, stimmt, aber es gibt noch eine andere Seite, die auch wahr ist: Viele Projektmanager haben auf die harte Tour gelernt, dass es nicht unbedingt zum Erfolg führt, mehr Geld, Personal und Ressourcen in ein Projekt zu investieren.

Microsoft verfügt über enorme Ressourcen.

Stimmt, stimmt, aber es gibt noch eine andere Seite, die auch wahr ist: Viele Projektmanager haben auf die harte Tour gelernt, dass es nicht unbedingt zum Erfolg führt, mehr Geld, Personal und Ressourcen in ein Projekt zu investieren.

Dann können die Projektmanager und die Organisationsstruktur das Problem sein ;)

Vielleicht sollte Microsoft Uno kaufen und es angemessen finanzieren, damit sie all diese offenen Probleme beheben und mehr Kontrollunterstützung hinzufügen können.

Ich weiß, dass nventive Microsoft in den letzten Monaten umworben hat (eine Microsoft-Übernahme ist wahrscheinlich ihre Ausstiegsstrategie). An der Uno Conference gab es auch eine große Beteiligung von Microsoft. Sogar Xamarin verwendet jetzt Uno, um das Web zu unterstützen.

Ich weiß, wir können endlos über die Optionen (1) native Renderings oder (2) eine andere UI-Implementierung/Ebene diskutieren, aber wenn man sich ansieht, was jetzt verfügbar ist und was wir für Surface Duo brauchen, ist Uno eigentlich die einzige Lösung, die Sinn macht. Wie @lukasf sagte, sollte Microsoft seine Ressourcen dahinter stecken und sehen, wie weit sie in einem Jahr kommen können. Wenn es erfolgreich ist (Funktion vollständig, stabil), denke ich, dass Entwickler sich nicht wirklich darum kümmern werden, wie es hinter den Kulissen implementiert wird. Wenn sich herausstellt, dass der richtige Ansatz WinUI nativ für jede Plattform gerendert ist, kann dies in einigen Jahren diskutiert werden. Im Moment ist es besser, mit einer zu 25 % vollständigen Uno-Plattform zu beginnen, als gar nichts.

@stevenbrix hier :

@lukasf Ich denke, der "kleinste gemeinsame Nenner", der derzeit in Uno existiert, ist ein Problem mit der Ressourcenbeschränkung und nicht auf die Schichtung zurückzuführen. Ich würde gerne das Gegenteil beweisen, aber ich denke, dieses Problem könnte gelöst und in Zukunft nicht noch verschlimmert werden.

Ihr seid falsch.
Uno folgt nicht dem Mantra des "kleinsten gemeinsamen Nenners" von Xamarin, sondern versucht vielmehr sicherzustellen, dass alle XAML-Steuerelemente (und sogar das Windows Community Toolkit!) auf allen Plattformen funktionieren.

Uno folgt nicht dem Mantra des "kleinsten gemeinsamen Nenners" von Xamarin, sondern versucht vielmehr sicherzustellen, dass alle XAML-Steuerelemente (und sogar das Windows Community Toolkit!) auf allen Plattformen funktionieren.

@weitzhandler du hast vollkommen recht! Ich glaube, dass ihre Architektur eines Tages eine vollständige Parität mit dem WinUI-Steuerelementsatz aufweisen wird, was mit Xamarin.Forms möglicherweise nicht möglich ist. Wenn ich das richtig verstehe, wurde dieses Kontrollset noch nicht gebaut, worauf @lukasf und ich mich bezogen haben. Ich könnte mich jedoch irren, ich habe nicht genug herumgespielt, um es zu wissen, ich vertraue nur dem, was ich von allen anderen gehört habe :)

Der Ansatz von @weitzhandler Uno, die echten UWP/WinUI-APIs neu zu implementieren, ist viel besser als die Erfindung eines neuen XAML-Dialekts durch Xamarin. Wenn Sie jedoch die Uno Xaml Controls Gallery ausführen, werden Sie einige Bereiche leer finden. Ihr Steuerelementsatz ist sicher besser als Xamarin.Forms, aber es ist noch nicht annähernd eine vollständige UWP/WinUI. Ich denke, Uno braucht mehr Arbeit an der API-Oberfläche und auch mehr daran, die verfügbaren Steuerelemente wirklich stabil und voll funktionsfähig zu machen.

Ich könnte Uno als eine praktikable Option sehen. Aber es braucht einige echte Fortschritte, und hier könnte Microsoft ins Spiel kommen.

An einem anderen Punkt stimme ich dem, was @lukasf hier gesagt hat, voll und ganz zu:

Großartige Apps haben ihr eigenes Look+Feel. Sie benötigen keine Standardplattformsteuerungen. Schau dir Spotify, Netflix an

Ich denke auch, dass die Lösung idealerweise darin besteht, WinUI + Fluent-Design auf allen Plattformen gleich rendern zu lassen und vielleicht native Look-and-Feel-Themen für diejenigen bereitzustellen, die das Standarddesign benötigen, das auf den spezifischen Plattformen angewendet werden soll.
Ich denke, Web sollte dasselbe wie Desktop sein, daher sind sowieso nur Droid und iOS Kandidaten dafür.

Plattformübergreifende Steuerelemente sind tatsächlich unabhängig von plattformübergreifenden Frameworks.

Hypothese: .Net-Kontrollen werden in Zukunft nicht auf bestimmte Plattformen beschränkt sein.

Es gibt vorhandene plattformübergreifende .Net-UI-Frameworks (Xamarin.Forms, Avalonia). Es wird auch FutureXplatDotNetUI geben, von dem alle träumen und die niemand so genau definieren kann.

Wenn Sie ein Steuerelement erstellen, können Sie dafür sorgen, dass es plattformspezifische Funktionen verwendet. ZB ein Videoplayer mit nativen Playern auf jeder Plattform. Oder Sie könnten dies plattformunabhängig tun, zB mit SkiaSharp.

In jedem Fall ist Ihr Steuerelement in jedem .Net-UI-Projekt installierbar.

Ergänzung: FutureXplatDotNetUI benötigt nur einen minimalen Satz von Steuerelementen

Es muss eine View-Klasse und eine Layout-Infrastruktur definieren, aber bestimmte Ansichten oder Gruppen von Ansichten können hinzugefügt werden, indem Standard-.Net-UI-Pakete von nuget installiert werden.

(Dieser Beitrag ist ein Kommentar zur plattformübergreifenden .Net-Benutzeroberfläche und hat daher keinen Bezug zu WinUI.)

Ich habe das Gefühl, dass die aktuelle Priorität des WinUI-Teams nicht "neue native Windows-Anwendungen" ist. Stattdessen konzentrieren sie sich mehr auf die Modernisierung vorhandener Apps und machen WinUI zur zugrunde liegenden Unterstützung eines übergeordneten UI-Frameworks ...

@reli-msft
Ich habe das Gefühl, dass das WinUI-Team es bereits aufgegeben hat, von den Leuten zu erwarten, dass sie neue native Windows-Anwendungen schreiben, und WinUI ist für die Aktualisierung vorhandener Anwendungen konzipiert

Von einer Person zu kommen, die bei Microsoft arbeitet, ist irgendwie seltsam.

Ich habe das Gefühl, dass das WinUI-Team es bereits aufgegeben hat, von den Leuten zu erwarten, dass sie neue native Windows-Anwendungen schreiben, und WinUI ist für die Aktualisierung vorhandener Anwendungen konzipiert

Von einer Person zu kommen, die bei Microsoft arbeitet, ist irgendwie seltsam.

@weitzhandler
Ich sollte das Wort, das ich verwendet habe, genauer verwenden ... Es ist nicht "aufgeben", sondern "sich weniger kümmern". Wie auch immer, das ist nur ein Gefühl von jemandem außerhalb des WinUI-Teams.
Aber die Modernisierung vorhandener Apps könnte _vorerst_ wichtiger sein, und das könnte der Grund dafür sein, dass WinUI beschlossen hat, Win32 zu unterstützen.

Sie haben darüber gesprochen, was das WinUI-Team denkt.

Als allgemeine MS macht das leider tatsächlich Sinn.
Ich wünschte, Microsoft hätte WinUI die Liebe gegeben, die React oder Electron oder jede andere HTML-CSS- und JS-Technologie bekommt (lesen Sie meinen Kommentar oben ).

@charlesroddie

Sie benötigen immer ein Framework, um Ihre Kontrollen zu entwickeln. Sie benötigen Basisklassen zum Vererben und Schnittstellen zum Implementieren. Sie benötigen Klassen, um auf Steuerelementbäume, Vorlagen usw. zuzugreifen. Sie können also Steuerelemente nicht wirklich von Frameworks trennen. Kein Steuerelement kann in mehreren Frameworks funktionieren, es sei denn, diese Frameworks verwenden genau dieselben Konzepte, Klassen und Namespaces.

Sie könnten etwas Code zwischen (C#-basierten) WinUI-Steuerelementen und WPF freigeben, aber aufgrund unterschiedlicher Namespaces und unterschiedlicher APIs wäre dies immer noch schwierig. Aber es ist schlicht unmöglich, XAML-Steuerelemente mit Android- oder iOS-Frameworks zu teilen.

Darüber hinaus bin ich mir wirklich nicht sicher, ob .NET die richtige Technologie ist, um einen UI-Stack aufzubauen. Microsoft hat es mit WPF versucht und dann endgültig aufgegeben und auf C++ umgestellt. In Zeiten, in denen Animationen immer wichtiger werden, machen GC-Pausen während des Layouts und Renderns einfach nicht den besten Eindruck für den Endbenutzer. Vielleicht ist dies nicht mehr der Fall, wenn ein Compositor verfügbar ist, der völlig unabhängig vom UI-Thread für flüssige Animationen sorgt. Dann könnte der Steuerelementstapel C# sein und nur der Rendering- und Animationsteil der untersten Ebene wäre nativer Code. Aber damals war die Performance der Hauptgrund, warum C# in den folgenden XAML-UI-Frameworks (Silverlight und UWP/WinUI) komplett aufgegeben wurde.

@lukasf Kein Steuerelement kann in mehreren Frameworks funktionieren

Das ist nicht wahr. Ich habe zwei Möglichkeiten angegeben, wie Steuerelemente in mehreren Frameworks funktionieren können. Der erste Ansatz besteht darin, plattformspezifischen Code zu schreiben. Dann müssen Sie die Frameworks kennen, die Sie unterstützen, um Ihren plattformspezifischen Code mit jedem Framework zu verbinden. Sie können dies jetzt tun, aber das Gerüst kann in Zukunft einfacher gemacht werden. Der zweite Ansatz (plattformunabhängiges Rendering) ist sehr einfach und wird gerade durchgeführt. ZB kann CSharpMath.SkiaSharp auf allen .Net-UI-Plattformen verwendet werden.

@charlesroddie Okay, vielleicht habe ich deinen Beitrag falsch verstanden. Aber dann ist die Steuerung nicht wirklich unabhängig vom Framework. Es kann nur in solchen Apps installiert werden, deren Framework explizit vom Control unterstützt wird. Und das Rendern ist nur ein kleiner Teil eines Steuerelements. Kontrolllogik, Datenbindung und Eingabebehandlung müssen für jedes einzelne unterstützte Framework in jedem solchen Steuerelement implementiert werden, selbst wenn Sie einen plattformunabhängigen Renderer verwenden. Das klingt für mich nicht sehr effektiv, es sei denn, die unterstützten Frameworks sind sehr ähnlich. Wie bereits erwähnt, ist es möglich, Code zwischen WPF, Silverlight und UWP zu teilen. Aber darüber hinaus wird es wirklich schwierig, und ich bezweifle, dass ich jemals eine solche Kontrolle sehen werde.

Ein plattformübergreifendes Framework ermöglicht es Ihnen normalerweise, die gesamte Steuerlogik, Daten- und Eingabebehandlung (und manchmal sogar das Rendering) nur einmal für eine API zu schreiben und diese dann automatisch jedem Framework zuzuordnen. Sobald das Framework vorhanden ist, ist die Implementierung der Kontrolle viel effizienter.

Es kann nur in solchen Apps installiert werden, deren Framework explizit vom Control unterstützt wird.

Das stimmt, aber die Unterstützung weiterer Plattformen ist/kann einfach gemacht werden.

Kontrolllogik, Datenbindung und Eingabebehandlung müssen für jedes einzelne unterstützte Framework implementiert werden.

Die Datenbindung muss nicht durch ein UI- Framework implementiert werden. Dies ist ein Missverständnis, das durch die vorherrschenden populären, aber minderwertigen .Net-Ansätze gefördert wird. Steuerelemente müssen nur Konstruktoren und Eigenschaften angeben. Sie müssen keine bestimmte Methode zum Binden von Daten angeben, da Verbraucher, sobald gettable/settable-Eigenschaften angegeben sind, jedes beliebige Ansatz-Framework verwenden können, um Daten zu verschieben, die sie möchten. (Und fast jeder Ansatz/jedes Framework ist besser als die WPF/UWP/Xamarin-Datenbindung.)

Die Steuerungslogik ist natürlich plattformunabhängig in .Net implementiert, so dass die beiden von mir angegebenen Ansätze perfekt darauf abgestimmt sind.

Die Eingabeverarbeitung profitiert zwar von einem "plattformübergreifenden Framework", aber dies kann ein sehr kleines Kontroll-Framework sein, auf das sowohl in plattformspezifischen als auch plattformübergreifenden Projekten verwiesen werden kann, mit einer sehr kleinen API, die nur Maus/Touch definiert und Tastatureingabe. Das Projekt SkiaSharp.Extended Controls bewegt sich in diese Richtung.

Wenn die Datenbindung in WPF oder WinUI funktionieren soll, müssen Sie DependencyProperties deklarieren. Ich bezweifle stark, dass jemand ein XAML-Steuerelement verwenden würde, das nicht mit Datenbindung funktioniert. Die Datenbindung ist das Herzstück dieser Frameworks und erfordert, dass DependencyProperties funktioniert, ob Sie sie mögen oder nicht. Wenn Sie sie nicht hinzufügen, können Sie Ihr Steuerelement in keinem der aktuellen Windows-Plattform-Frameworks verwenden.

Unter "Steuerungslogik" verstehe ich eher die Interaktion mit anderen Controls, wie das Definieren oder Erstellen von Sub-Controls für Ihr Top-Level-Control, Daten- und Statushandling zwischen diesen Controls, Layout, Synchronisation mit Sub-Controls. Dies ist alles rahmenspezifische Arbeit. Dies macht zusammen mit Datenbindungscode (sofern vom Zielframework erforderlich) und Eingabebehandlung wahrscheinlich >90% des Kontrollcodes aus. Der gemeinsame Teil zwischen verschiedenen Framework-Implementierungen für ein solches Steuerelement ist wahrscheinlich so klein, dass es für mich einfach keinen Sinn macht, so zu arbeiten.

Ich sage nicht, dass es nicht geht. Aber es wird sehr kompliziert, da Frameworks so sehr unterschiedlich sind. Ich meine, es ist jetzt möglich, ein solches Steuerelement zu schreiben, aber ich habe noch nie eines gesehen. Und ich persönlich glaube nicht, dass dies ein auch nur annähernd populärer Ansatz werden wird.

Sie können Ihr Steuerelement in keinem der aktuellen Windows-Plattform-Frameworks verwenden

Das ist nicht wahr. Ein Steuerelement, das DependencyProperties nicht implementiert, kann in WPF/WinUI verwendet werden. Dies ist einer der Fehler der traditionellen .Net-Datenbindung: Sie ermutigt dazu, falsche DependencyProperties zu Steuerelementen hinzuzufügen, die bereits einstellbare Eigenschaften definieren. Riesige Code-Duplizierung. (Übrigens wäre ein Cross Platform Control kein "XAML Control" und man sollte sich nicht auf den Missbrauch von "XAML" in der Marketingsprache von WinUI einlassen. Xaml ist eine optionale Auszeichnungssprache die mit mehreren verwendet werden kann .Net-UI-Frameworks.)

Untersteuerelemente für Ihre übergeordnete Steuerung

Ja, ein Steuerelement muss untergeordnete Steuerelemente angeben. Damit Steuerelemente auf höherer Ebene plattformübergreifend verfügbar sind, müssen dies auch auf niedrigeren Ebenen sein. Wenn die untergeordneten Steuerelemente plattformübergreifend verfügbar sind, ist die Integration einfach. Sie stellen sich vor, Steuerelemente auf höherer Ebene vor denen auf niedrigerer Ebene zu schreiben, was kein effizienter Ansatz ist.

Die gute Nachricht ist, dass Microsoft bereits beschlossen hat, .net native zu töten.

@roloo Ich werde eine Party veranstalten, um das zu feiern, wenn dies passiert.

Selbst wenn Uno über ein solides, zuverlässiges technisches Design und Implementierung verfügt, besteht das Risiko und die Sorge darin, dass Uno innerhalb weniger Jahre aufgrund eines ähnlichen 0-Dollar-Problems oder unzureichender Einnahmen verschwinden könnte, was schließlich zu Burn-out und Projektabbruch oder Stagnation führt. Oder einfach der wichtigste Entwickler von Uno eines Tages plötzlich ein neues Hobby/Interesse/Besessenheit bekommt und das Interesse an Uno verliert oder einen neuen Job/Arbeitgeber und keine Zeit mehr hat, an Uno zu arbeiten.

@verelpode
Ich teile die gleiche Sorge wahrscheinlich mehr als die meisten anderen. Ich verwende viel weniger Open-Source-Pakete, die nicht von großen Unternehmen (zB Oracle, Google, Microsoft) unterstützt werden als der Durchschnitt. Ich glaube, dass beide der folgenden Bedingungen erfüllt sein müssen, damit dies geschieht:

1. Nventive schließt sein Geschäft. Nventive verlässt sich bei seinem Brot-und-Butter-Geschäft auf Uno.
2. Die Hauptleute hinter Uno verlieren ihr Interesse an diesem wunderbaren Projekt.

Was #1 angeht, habe ich gehört, dass Nventive aus seinem aktuellen Gebäude herauswächst und in eine größere Einrichtung umzieht, so dass die erweiterte Uno Conf 2020 (2-Tage bis 3-Tage) einen Teil in einem anderen Gebäude abhalten wird. Ich bin kein Ökonom und kann daher nicht vorhersagen, ob eine schwere Rezession viele Unternehmen aus dem Geschäft treiben wird. Zumindest sehe ich derzeit keinen wirtschaftlichen Zusammenbruch in naher Zukunft (die Arbeitslosenquote in unserer Region liegt seit einiger Zeit unter 2%).

Was #2 angeht, sehe ich selten die Art von Leidenschaft, die die primären Uno-Leute für ihr Projekt haben. Es ist fast wie eine edle Sache, kein bloßes Softwareprodukt für sie. Nun, nur ein Dummkopf ändert seine Meinung nicht, daher würde ich nicht sagen, dass die Wahrscheinlichkeit, dass sie das Interesse verlieren, null ist, aber wahrscheinlich nicht weit von null entfernt. Um ehrlich zu sein, ist dies der Hauptgrund für mich, Uno zu genießen und im Moment an Uno festzuhalten. Wie jede andere Plattform hat Uno viele Probleme (übrigens, das Fehlen einiger netter Funktionen ist für mich kein Problem.), aber sie beheben kritische Probleme schnell. Ich glaube, sie haben jeden Tag ein halbes Dutzend oder mehr Veröffentlichungen. Eine meiner Apps konnte aufgrund eines bekannten Fehlers einer Plattform nicht veröffentlicht werden, und es hat buchstäblich mehr als ein halbes Jahr gedauert, bis eine große Firma (😉) sie behoben hat (ich habe das Ticket archiviert).

Basierend auf meiner umfangreichen Erfahrung mit Sliverlight, Windows Phone 7/7.1/8/8.1 SDKs, Windows 8/8.1/10 (WinRT, UWP…) (Mein primäres Telefon war ein Windows Phone, die beste mobile Plattform in der Geschichte der Menschheit, bis letzte Minute, bevor ich dieses Jahr auf Android umgestiegen bin), habe ich mehr Vertrauen in die Langlebigkeit der Uno-Plattform als ähnliche Dinge von Microsoft. Ja, Uno basiert auf allen Microsoft-Technologien, aber sie kümmern sich um die Migration, wenn Microsoft etwas unter der Haube ändert.

Ich habe mich gefragt, ob Miguel Uno befürwortet und die Keynote auf der Uno Conf hält, weil er Uno wie sein Baby Mono in der Anfangszeit und Nventive wie seinen Ximian sieht.

Ich bereite mich auf das schlimmste Szenario vor – den Tod von Uno. Da alle Uno-Projekte meine beiden Lieblingstechnologien – C# und Xaml – verwenden, kann ich sie problemlos auf jede neue Plattform migrieren, die darauf basiert. Zumindest kann ich sagen, dass C#-Code wirklich gut altert. Ein Großteil des Codes in meiner zentralen Dienstprogrammbibliothek, der von allen Projekten verwendet wird, ist weit über ein Jahrzehnt alt. Sie funktionieren immer noch perfekt, und ich vermute, sie werden es in den kommenden Jahrzehnten tun.

@stevenbrix @weitzhandler @Pinox

Eine interessante Diskussion, bei der auch Blazor Native erwähnt wurde.

Es gab eine neue NDC-Konferenz von Steve mit Blazor, die interessant sein könnte. Das obige Video mit Blazor + Native verwendete Flutter als Renderer. Aber in einem neuen NDC Conf-Video verwendet Steve jetzt Xamarin.Forms , um die mobile Benutzeroberfläche mit XAML-ähnlichem Markup zu rendern. Ich könnte mir vorstellen, dass Blazor Native die praktischste x-Plattform-Lösung ist, die derzeit mit WinUI funktioniert, da sie React Native in der gleichen Weise unterstützt, wie ich es mir vorstellen konnte, Blazor Native auf diese Weise zu unterstützen. So kann .Net jetzt gezielt ansprechen (Web, Mobile, Win Desktop).

AKTUALISIEREN:
Vor kurzem wurde eine neue Version von MS Teams veröffentlicht, die die Zeit zum Anzeigen der neuesten Chat-Nachricht verbessert. In einer früheren Nachricht habe ich erwähnt, dass es ca. 27 Sekunden gedauert hat, aber zum Glück zeigt die neue Version die neueste Chat-Nachricht schneller an.

Vielen Dank an die Microsoft-Mitarbeiter, die an dieser Verbesserung gearbeitet haben. :Lächeln:

Meine Perspektive:

Microsoft: Kann ein minimales Webview2 (ähnlich wie Carlo) entwickeln, das fast alle Funktionen deaktivieren und auf nur die Ereignisbindung an die HTML-Benutzeroberfläche reduzieren kann... Native Backend-Bibliothek).
Ich wusste, wie komplex die HTML/CSS-Seite ist, aber ich würde gerne dieses UI-Wissen und eine Eins-zu-Eins-Bindung an C#-Code hinter usw. Ereigniscode nutzen.

Microsoft: Kann einen RAM von 8/32 GB von denen ausschalten, die 4 x 8 GB / 4 x 32 GB hatten ... Das spart viel Energie.

Um dies zu tun, entfernen wir Dutzende von Apps, die mit Electron entwickelt wurden ... die von den Zielen von Microsoft und Bill Gates abhängen.

Obwohl das beste Ziel ist, dass jeder mit der Entwicklung von Apps beginnt und von einem CSS3-Standard-GUI-Framework profitiert ... möglich wie QT / GTK ... aber schade, dass GTK kein Copyleft ist und wie QML mit .net-Äquivalenz möglich ist.

AKTUALISIEREN:
Stornieren Sie, was ich in meiner vorherigen Nachricht über die Behebung des Problems gesagt habe ☹️ Es ist nicht behoben. Das ist bizarr: Für ein paar Wochen schien es, als ob das Problem weg wäre, aber dann ist das Problem vor kurzem wieder aufgetreten! MS Teams bereitet mir erneut Schwierigkeiten und Verzögerungen, wenn ich einfach versuche, die neueste Chat-Nachricht anzuzeigen.

Die Fehlerhaftigkeit von MS Teams überrascht nicht, wenn man bedenkt, dass es in JavaScript geschrieben ist. _Natürlich_ ist eine in JavaScript geschriebene App fehlerhaft – warum sollte jemand etwas anderes erwarten? MS Teams verwendet ElectronJS, das JavaScript verwendet, obwohl bekannt ist, dass JavaScript nie als echte Programmiersprache gedacht war, sondern nur ein beiläufiges Skript-Add-On für Webbrowser.

JavaScript enthält nicht einmal eine Typüberprüfung zur Kompilierzeit - so schlimm ist es. Daher ist es erforderlich, dass TypeScript versucht, dieses _große_ Problem in JavaScript zu beheben. Eigentlich ist es ein sehr schlimmes Problem, wenn man sich JavaScript als Programmiersprache vorstellt – JavaScript ist eine schreckliche Programmiersprache – aber wie gesagt, es sollte eine einfache Skriptsprache sein, keine Programmiersprache, also kannst du verzeihen Sie JavaScript, dass es nicht das Wesentliche einer Programmiersprache enthält, da das Programmieren von Apps nicht der Zweck von JavaScript war.

Was nicht wirklich verzeihlich ist, ist die unverständliche Entscheidung, eine beiläufige Skriptsprache wie eine Programmiersprache zu verwenden. Ich war wirklich überrascht zu sehen, dass Microsoft eine nicht professionelle Sprache für eine so wichtige App wie Teams gewählt hat. Ich hätte nicht gedacht, dass jemand den Namen "JavaScript" sagen und gleichzeitig vergessen kann, dass "JavaScript" "Script" im Namen hat, weil es in der Tat eine Skriptsprache und keine Programmiersprache ist. Irgendwie wurde die Existenz des Wortes "Script" in "JavaScript" gerade komplett ausgeblendet.

Die Mitglieder des WinUI-Teams haben hart an vielen Verbesserungen von WinUI gearbeitet. Die Entscheidung von Microsoft, anstelle von WinUI eine einfache Skriptsprache zu verwenden, macht keinen Sinn.

Es gibt viele sehr gut geschriebene, leistungsstarke JavaScript-Webanwendungen. Sicher können Sie mit anderen Technologien eine noch bessere Leistung erzielen. Aber der Grund, warum Teams für Sie langsam ist, ist sicherlich nicht die Tatsache, dass es auf JavaScript basiert. Dies wird durch eine schlechte Implementierung auf der Server- oder Clientseite verursacht (wahrscheinlich Asynchron-/Threading-Probleme). Es wäre sicherlich möglich, Teams in JavaScript mit einer viel besseren Leistung zu schreiben.

Versteh mich nicht falsch, ich bin überhaupt kein JavaScript-Fan. Tatsächlich finde ich es eine schreckliche Sprache. Ich sage nur, dass die Probleme, die Sie sehen, nicht darauf zurückzuführen sind, dass Teams JavaScript-Technologie verwendet. Es ist sogar möglich, die Unreal-Engine in JavaScript mit guter (nicht erstklassiger) Leistung auszuführen.

WinUI ist nur ein Windows-Desktop-Framework. Die Entwicklung der x-platform Teams-Anwendung darauf basierend war also nicht möglich und auch heute noch nicht möglich. Aber vielleicht helfen die Probleme mit Teams Microsoft, über eine plattformübergreifende WinUI nachzudenken. Mit einer echten X-Plattform-WinUI und .NET Core wäre es viel einfacher, reaktionsschnelle Apps zu entwickeln, die gut skalierbar sind.

WinUI ist nur ein Windows-Desktop-Framework. Die Entwicklung der x-platform Teams-Anwendung darauf basierend war also nicht möglich und auch heute noch nicht möglich. Aber vielleicht helfen die Probleme mit Teams Microsoft, über eine plattformübergreifende WinUI nachzudenken. Mit einer echten X-Plattform-WinUI und .NET Core wäre es viel einfacher, reaktionsschnelle Apps zu entwickeln, die gut skalierbar sind.

Mit Uno ist WinUI plattformübergreifend. Schauen Sie sich den UNO-Rechner im Google Play Store an. Es ist eine portierte Version des Windows 10-Rechners.

Jemand hat nach einem Vergleich zwischen UWP und Electron gefragt, hier sind ein paar:

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

Die neue XBOX-App ist lächerlich, kann leicht 1,5 GB RAM für nichts verbrauchen

Wäre nett, wenn jemand ein Video machen könnte, um zu zeigen, wie langsamer er im Vergleich zu UWP ist

Ich dachte, die meisten Teilnehmer dieser Diskussion über WinUI & X-Plattform haben diese Geschichte gelesen, aber für den Fall, dass einige sie verpasst haben, hier ist WinUI unter Windows 7 – Ja, mit Uno Platform ist dies möglich . Sobald eine App auf Uno basiert, zielt sie auf Windows, Web, iOS und Android ab.

@lukasf

Es wäre sicherlich möglich, Teams in JavaScript mit einer viel besseren Leistung zu schreiben.

Ja, es ist _möglich_, und es ist auch _möglich_, MS Teams in PowerShell mit akzeptabler Leistung zu schreiben (ich mag PowerShell), und es ist auch _möglich_, dass SpaceX nach Russland umzieht und es immer noch schafft, Satelliten zu starten, aber es wäre immer noch ein inkompetentes Management Entscheidung, SpaceX nach Russland zu verlagern oder die MS Teams-App in einer Skriptsprache wie PowerShell oder JavaScript zu schreiben. Wenn SpaceX nach Russland umziehen würde, dann könnte SpaceX noch funktionieren, es ist möglich, aber ehrlich gesagt müssten wir sagen, dass Elon Musk kein wirklich effektiver Manager wäre und nicht wirklich wüsste, was er tut.

Ich bin nicht 100% davon überzeugt, dass Electron die Schuld trägt. Visual Studio Code soll auch auf dem Electron basieren, aber seine Leistung ist ziemlich solide. Electron-Apps sind im Grunde Web-Apps, und es gibt Tausende von Gründen für eine schlecht ausgeführte Web-App.

Es gibt nicht viel, was WinUI tun kann, um "Teams zu gewinnen". Es ist nicht die Technik, es ist das Produkt. Teams ist wie ein Startup-Unternehmen, das sich auf einen schnellen Wachstumspfad eingestellt hat. Es muss auf mehreren Plattformen mit Funktionsparität ausgeführt werden, und dies muss so schnell wie möglich erreicht werden. Dies ist der einzige Grund, sich für eine webbasierte Technologie zu entscheiden. Auf Mobilgeräten können sie React Native verwenden, da dies die einzige Möglichkeit ist, mit JavaScript auf Hardware zuzugreifen, aber auf dem Desktop müssen sie die Funktionsparität und die Code-Wartbarkeit mit der Web-App, dem Mac und der Linux-Version aufrechterhalten. Sie müssen ein Framework verwenden, das auf Win32 abzielt, da sie nicht warten können, bis das UWP-App-Modell die benötigten Funktionen hinzufügt. Die Möglichkeit, den Desktop freizugeben, mit der Option, auszuwählen, welcher Desktop oder welche bestimmte App freigegeben werden soll, ist eine der wichtigsten Funktionen. So entstehen Startup-ähnliche Produkte. Slack benutzte jquery, um das Wachstum zu hacken, als sie anfingen und endete mit wirklich schlechtem Code, aber sobald sie etwas Zeit zum Refactoring hatten, schrieben sie schnell alles mit React um, und Slack ist jetzt viel schneller als zuvor. WinUI und Electron gehören nicht in dieselbe Kategorie und werden aus diesem Grund Electron nicht für die Apps ersetzen, die es wirklich brauchen, egal welche Funktion es hinzufügt.