Ich denke, dass Xamarin mit .NET 5 verschmelzen wird;
Es wäre großartig, wenn sie das UWP-XAML als Standard übernehmen und von dort aus daran arbeiten, dass Microsoft und UNO es zum Besten für Desktop, Mobile, Webbrowser (Azure) und IoT machen.
Sie könnten es nennen
UWP vNext (WinUI-basiert)/ Silverlight 6 (UNO)

Ich denke, dass die Blazor-Bemühungen ein erster Schritt waren, .NET offiziell in den WebBrowser zu bringen, wobei das aktuelle Standard-Rendering verwendet wurde, dh. das HTML-DOM
Aber ich glaube, dass sie bald sogar eine andere Rendering-Engine anbieten können, eine leichte Ergänzung für WinUI, etwas, das Silverlight, UNO-Plattform und Xamarin umkreist ... wie Flutter / WPF

Es wäre großartig, wenn sie das UWP XAML als Standard übernehmen und von dort aus weiterarbeiten würden

Alles, was Sie wollen, geschieht bereits mit Uno. MS wäre gut beraten, diese Leute aufzukaufen und sie dann einzustellen, um die endgültige Entwicklung von Uno voranzutreiben.

Dies ist wahrscheinlich der falsche Ort, um ein solches Feature anzufordern. So gerne ich allem in dieser Anfrage zustimmen würde, glaube ich, dass das WinUI-Team und viele erfahrene Entwickler in der Windows-Community WinUI als sehr eng definiert betrachten.

In einer idealen Welt wäre WinUI genau wie Material Design. Es wird Möglichkeiten geben, es auf jeder Plattform mit allen Arten von Bibliotheken zu haben, die es implementieren. Allerdings ist WinUI keine Designsprache und somit auch kein Fluent Design. Microsoft, das nicht im Modellbereich ist, hat sein UI-Angebot um einiges hinter der Konkurrenz zurückgelassen.

WinUI ist eine UI-Bibliothek für Windows-Anwendungen, und das ist so klar wie es nur geht. Die Entwurfssprache ist nicht von der Implementierung getrennt, und die Implementierung ist plattformexklusiv, da Funktionen wie die Komposition stark von der Plattformabhängigkeit abhängen. Das ist aus Sicht eines mobilen/plattformübergreifenden Entwicklers schlecht, aber der Aufwand hier ist wirklich für Windows-Apps.

Dies ist auch der Grund, warum die Uno-Plattform wahrscheinlich nie wirklich überall WinUI sein kann, es sei denn, sie portieren DX 11 auf jede Plattform.

Ich würde vorschlagen, dass Sie sich Comet (plattformübergreifendes Entwicklungsframework basierend auf .Net) ansehen. Es befindet sich noch in einem frühen Stadium, aber das Konzept ist Flutter nicht unähnlich. Es verwendet auch Skia (als Option), um die Benutzeroberfläche mit einem zusammensetzbaren/deklarativen UI-Muster zu zeichnen, sodass Entwickler UI-Bibliotheken wie Material Design implementieren können und es auf jeder Plattform völlig gleich aussehen lassen.

Nein, es sollte nicht plattformübergreifend sein. Es heißt aus gutem Grund Windows UI. Lassen Sie uns einfach ein UI-System besorgen, das auf allen Windows-Plattformen (Plattformen und Sprachen) funktioniert, um mit hey? Das ist noch nicht einmal erreicht. Wir sind immer noch gespalten zwischen .net Framework, .net Core, uwp und dann der C++-Story, die zumindest uwp hat, aber kein Spieleentwickler verwendet, weil UWP/WinRT immer noch einige Probleme hat – Verteilung, erzwungene Taskleisten- und Titelleisten-Popups wenn im Vollbild (yikes).

Über Cross-Plattform nachzudenken, wäre eine kolossale Ressourcenverschwendung. Machen Sie es bitte zuerst unter Windows richtig. Und bringen Sie .net 5 aus der Tür und reparieren Sie UWP und die Windowing-Story und setzen Sie DirectX auf C#. Und den GC reparieren. Im engen Szenario gibt es noch so viel zu tun, nur unter Windows.

Und zum OP.

• UWP ist universell. Zu sagen, es sei nicht universell, ist eine falsche Behauptung (sie wollten Gott sei Dank nie auf Android abzielen). Das ursprüngliche Versprechen wurde eingelöst. Alle Windows-Geräte führen UWP aus. Windows Mobile war ein separates Betriebssystem, sie mussten es loswerden. Alle neuen Windows-Plattformen werden Windows (10 oder 10X) sein. Irgendwann basierend auf CoreOS, nehme ich an. Und sie werden alle Windows-Anwendungen ausführen. Nur weil wir gerade kein Windows Phone haben, ist Nebensache. Wir haben alle anderen Gerätetypen. Und wir werden bald Neo und Duo haben.

• Sandbox-Einschränkungen – Das sind gute Dinge. Der systemweite Zugriff im Win32-Stil sollte generell ausgemerzt werden. Wenn Sie eine bestimmte Anforderung haben, sollten Sie Ihre Anforderung vorbringen, damit wir besprechen können, wie sie in einem UWP-Container ausgeführt werden könnte/sollte und ob Sie dies so tun dürfen, wie Sie es vorschlagen. Und finden Sie heraus, ob UWP diese Funktion benötigt. Weil mir einige fortgeschrittene Anwendungen einfallen, die kein Problem in UWP schreiben könnten. Ich kann Programm haben! Sie müssen Einzelheiten besprechen.

• .net native wird ersetzt und die Distributionsgeschichte wird sich mit .net 5 ändern. Ich denke, es ist fair zu sagen, dass Microsoft daran arbeitet. Sicherlich kennen sie die Probleme. Sie sollten jedoch spezifische Probleme einreichen, um die wirklich zugrunde liegenden Probleme hier anzugehen.

• "Koppeln Sie WinUI nicht an DirectX" - WTF? Es sollte unbedingt mit DirectX gekoppelt werden, also dem nativen Windows-Grafikstack. Bitte denken Sie nicht einmal an etwas anderes. Ich möchte auf keinen Fall auf OpenGL-Rendering-Oberflächen unter der Haube stoßen. Das würde die Kompatibilität beeinträchtigen und allerlei Chaos verursachen.

@Gavin-Williams

Wunderbar, machen wir ein leicht evolutionäres Upgrade über WPF.

UWP ist universell

„Alle Windows-Geräte führen UWP aus“ bedeutet nichts ohne Mobile. HoloLens ist eine Nische, Surface Hub ist eine Nische, Windows 10 IoT Core ist ein Witz.

Es sollte unbedingt mit DirectX gekoppelt werden

Als Entwickler bekomme ich Gänsehaut bei Hard Coupling. Gibt es einen wichtigen Grund, warum der Grafikstack nicht ausgetauscht werden kann?

Es heißt "Modularität". Damit hatte Microsoft schon immer zu kämpfen.

Sandbox-Einschränkungen sind gute Dinge

Ja, das sind sie, solange sie den Bereich der Anwendungen, die erstellt werden können, nicht stark einschränken. Haben Sie versucht, die Größe einer Partition von UWP aus zu ändern?

Ich denke, es ist erwähnenswert und daran zu erinnern, dass Google Flutter entwickelt und es nicht GoogleUI oder AndroidUI nennt. Es funktioniert überall – sogar im Web und auf dem Desktop. Ich erkläre dies, da es eine Tendenz zu geben scheint, „es einfach unter Windows zum Laufen zu bringen“, aber wenn es ein anderes Konkurrenzangebot gibt, das billiger, schneller und benutzerfreundlicher ist UND unter Windows + allem anderen funktioniert ... was werden die Entwickler ( und entsprechenden Markt) wählen? Ich kann Ihnen als Kleinunternehmer sagen, dass ich weiß, wohin ich meine Investition stecke, wenn ich die beiden Möglichkeiten habe.

Das Portieren von DirectX auf andere Plattformen scheint eine gewaltige Arbeit zu sein, vielleicht besteht die Lösung darin, OpenGL oder Vulkan anstelle von DirectX zu verwenden

@Gavin-Williams, ich weiß nicht, ob Sie mit UWP vertraut sind, aber beim Erstellen/Verteilen zielen Sie auf eine bestimmte Version (oder einen bestimmten Versionsbereich) von Windows ab. Diese Idee ist absolut gekoppelt und einer der Gründe, warum UWP nicht so zum Mainstream wurde wie WPF.
@nerocui Der ganze Zweck einer UI-Sprache besteht darin, das UI-Design von der Rohzeichnung auf einem Bildschirm zu entkoppeln. Aus diesem Grund sehen Sie, dass HTML in ARM/x64/x64 gerendert werden kann.

XAML bietet eine hervorragende Abstraktion der UI-Grundelemente/-Komposition/-Animation, die Anforderung ist aufgrund der Entwicklungskosten und der Plattformreichweite absolut sinnvoll.

Ich stimme @SuperJMN respektvoll nicht zu. Sicherlich hat UWP noch keine Feature-Parität mit WPF erreicht. Trotz seiner Einschränkungen als Framework zum Erstellen von Tools auf Kernel-Ebene haben Sie für praktisch jede andere Softwareentwicklungsaufgabe mit den richtigen Funktionen, die im App-Manifest angegeben sind, eine viel bessere Benutzererfahrung aus mehreren Perspektiven (Sicherheit, einfache Bereitstellung, Installation/Deinstallation). Erfahrung usw.). Die Sicherheits-Sandbox von UWP ist ein wichtiges (wesentliches) Feature. In vielerlei Hinsicht ist UWP WPF jetzt weit voraus.

Der UWP .Net-Compiler eliminiert die Notwendigkeit der Code-Verschleierung und die Instabilität, die dies zu WPF führen kann. Die Leistung kann sich im Laufe der Zeit ohne Codeänderungen verbessern, wenn der Compiler verbessert wird. UWP selbst hat ein viel besseres Design in Bezug auf die Nutzung von DirectX und anderen Ressourcen auf Systemebene. Es hat auch einen großen Vorteil gegenüber WPF bei der Integration mit anderen Sprachen, insbesondere C++. Die Integration hochleistungsfähiger C++-Komponenten in C# ist unter UWP trivial. Auch der Zugriff auf DirectX-Oberflächen wurde deutlich verbessert.

Die verbleibenden Löcher in UWP können einfach gestopft werden. Ich würde argumentieren, dass das größere Problem darin bestand, dass Microsoft das Qualitätsniveau erreicht hat, das mit WPF verbunden war. WPF hat gerade funktioniert. Microsoft hat auch nicht die entscheidende Bedeutung von LOB-Anforderungen wie einem Data Grid, INotifyDataErrorInfo, Kontrollen, die Validierungsstatus aufweisen, und einer robusten, sofort einsatzbereiten Datenbank erkannt. Die meisten davon wurden angesprochen, aber es hat zu lange gedauert. Nicht rechteckige Bereiche fehlen noch.

Der andere kritische Fehler liegt bei bestimmten WPF-Entwicklern, die sich entschieden haben, sich von UWP fernzuhalten. Adoption ist wesentlich, um Dynamik aufzubauen. Die Adoptionssaga ist jedoch verständlich, wenn man bedenkt, wie oft Microsoft mit seinen Initiativen geschwafelt hat. Es ist offensichtlich, dass Microsoft wieder einmal schwafelt. Die Wiederbelebung von WPF, indem es sich in UWP-UI-Dienste einklinken kann, scheint oberflächlich betrachtet cool zu sein, aber es lenkt davon ab, UWP solide zu machen.

Ich stimme der Behauptung von @SuperJMN vollkommen zu, dass Entwickler die Hoffnung verloren haben, dass Microsoft das Richtige tun wird. Das Richtige hängt davon ab, welche Art von Software Sie erstellen. Wenn es sich um hochleistungsfähige LOB-Anwendungen handelt, die schnell erstellt werden müssen und eine breite Palette von Funktionen aufweisen und gleichzeitig sicher und einfach zu installieren sind, ist UWP meistens da, außer in Bezug auf die Qualität. Diese Qualitätslücke ist es, die UWP mehr als alles andere tötet.

HTML+JS ist die plattformübergreifende Lösung des Tages. Wir müssen es nicht neu erfinden. Eine leistungsstarke XAML-Rendering-Engine auf IOS und Android zu haben, ist sinnvoller, wenn die Absicht besteht, XAML portabler zu machen.

Ich stimme sehr zu, dass WinUI darauf abzielen sollte, in Zukunft plattformübergreifend zu sein. Hier sind einige weitere Gedanken.

Unmittelbare Prioritäten

Ich stimme einigen Kommentaren zu, dass die unmittelbare Priorität darin bestehen sollte, sicherzustellen, dass WinUI 3 unter Windows mit .Net 5-Integration funktioniert und dass Fehler behoben werden. Wenn es aber noch nicht zu spät ist, sollte bei architektonischen Entscheidungen das Ziel berücksichtigt werden, zukünftig plattformübergreifend zu sein.

Warum WinUI plattformübergreifend sein sollte

Es gibt die offensichtlichen und wichtigsten Gründe: Entwickler möchten die größtmögliche Zielgruppe ansprechen, ohne Code usw. umzuschreiben, und C# (oder C++, nehme ich an)/XAML ist eine schöne Kombination. Ohne eine plattformübergreifende Geschichte werden sie zu anderen Technologien wie Flutter wechseln.

Ein weiterer Grund ist sicherzustellen, dass WinUI weiterhin von Microsoft unterstützt wird. Microsoft wird WinUI wahrscheinlich nur dann weiter unterstützen, wenn seine eigenen Apps es verwenden. Sie konzentrieren sich zunehmend darauf, ihre eigenen Apps plattformübergreifend zu machen. Es ist wahr, dass einige plattformübergreifende Frameworks wie React Native und Xamarin WinUI darunter verwenden, aber was passiert, wenn andere Frameworks wie Flutter oder browserbasiertes Rendering gewinnen? Dann wird WinUI überflüssig und geht wie WPF in den Wartungsmodus.

Wie sollte Cross-Plattform implementiert werden

Obwohl Uno ein großartiges Projekt ist, ist es meiner Meinung nach sinnvoller, die Render- (und Eingabe-) Ebene plattformübergreifend zu gestalten und darauf aufzubauen, was Flutter und AvaloniaUI tun, anstatt native Steuerelemente zu umschließen. Der Ansatz, die Render- und Eingabeebenen plattformübergreifend zu gestalten, hat mehrere Vorteile. Es scheint mir, dass die API-Oberfläche der Render- und Eingabeebenen kleiner ist als die der Steuerelemente (aber ich nehme an, es hängt davon ab, ob Sie Steuerelemente auf einigen Basiselementen usw. erstellen). Zweitens, wenn Sie sich darauf verlassen, native Steuerelemente zu umschließen, sind Sie der Gnade der Plattform ausgeliefert. Wenn sie ihre API ändern, müssen Sie Ihre ändern oder eine Problemumgehung implementieren. Wenn Sie dies bei Verwerfungen nicht schnell genug tun, wird Ihr Framework kaputt gehen. Wenn Sie einem Steuerelement ein neues Feature hinzufügen möchten, müssen Sie es möglicherweise für jede Plattform implementieren. Sie können nicht wirklich eine "Vision" davon haben, wie sich Ihr Framework entwickeln soll, da Sie an die Plattform-Frameworks gebunden sind. Außerdem müssen Entwickler ständig auf jeder Plattform testen, da das Aussehen und Verhalten der Steuerelemente unterschiedlich sind. Außerdem wäre es schwierig/unmöglich, leistungsfähigere Funktionen wie die Kompositionsebene zu implementieren. Das plattformübergreifende Erstellen der Renderebene löst all diese Probleme, und wenn Sie auf jeder Plattform ein anderes Aussehen wünschen, können Sie einen anderen Stil hinzufügen. (Ich gebe zu, dass einige Verhaltensweisen auf verschiedenen Plattformen unterschiedlich bleiben würden, z. B. das Scrollen auf einem Mac!).

Da WinUI derzeit die Steuerelemente und Render- und Eingabeebenen von der Plattform entkoppelt, scheint es in einer einzigartigen Position zu sein, dies zu tun.

Eine Möglichkeit, die Renderebene zu abstrahieren, wäre die Verwendung von Skia. Ich möchte jedoch nicht, dass die Leistung leidet, wenn diese Abstraktion erzwungen wird. Ich habe einen alternativen Vorschlag zum Abstrahieren der Renderebene, nämlich den C++-Vorschlag für 2D-Grafiken - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . Sie haben offensichtlich viel Arbeit in die API-Oberfläche gesteckt und sie scheint ziemlich umfassend zu sein. Sie argumentieren, dass das „Problem“ der 2D-Grafik im Wesentlichen vor vielen Jahren gelöst wurde, und ich muss ihnen zustimmen, dass ihre API-Oberfläche ziemlich vollständig zu sein scheint. Es gibt viele Leute gegen diesen Vorschlag, aber selbst wenn er nicht angenommen wird, denke ich, dass die API-Oberfläche verwendet werden könnte. Wenn Sie ein Direct2D-Back-End für diese API-Oberfläche schreiben, erspart es dem MSVC-Team, es schreiben zu müssen, wenn der Vorschlag akzeptiert wird. Vielleicht könnte das WinUI-Team dies als Rechtfertigung dafür verwenden, daran zu arbeiten oder einige zusätzliche Teammitglieder hinzuzufügen. Vielleicht wären auch die Autoren des Papiers bereit zu helfen. Sie könnten das Back-End für die anderen Plattformen mit Skia oder so schreiben und wenn der Vorschlag schließlich akzeptiert wird, dann zu den nativen Implementierungen wechseln, wenn sie erstellt werden.

Abschließend möchte ich weiter in die Zukunft blicken und WASI erwähnen - https://wasi.dev/ . Dies scheint sich vorerst auf die Systemprogrammierung zu konzentrieren, aber es könnte das Potenzial haben, sich in ein vollwertiges plattformübergreifendes App-Framework zu verwandeln (es hat plattformübergreifende und integrierte Sicherheit), wobei der obige C++-Vorschlag vielleicht ein natürlicher Kandidat dafür ist die Rendering-Layer-API. (Dies ist jedoch wahrscheinlich sehr weit weg).

Wenn man sich die Beweise ansieht, haben Leute wie @SuperJMN angesichts des Inhalts ihrer Repositories viel Glaubwürdigkeit. Ich kann sehen, dass @SuperJMN UWP wahrscheinlich aufgegeben hat, als es noch ausgereift war (verständlich). Microsoft täte gut daran, die Repositories der Leute, die hier kommentieren, zu überprüfen. Einige Stimmen sind nicht besonders glaubwürdig, basierend auf dem Werk, das sie der Welt präsentieren.

@Noemata Ich war früher ein großer XAML+MVVM-Fan. Ich habe damit in Silverlight, WPF, WindowsPhone, Metro (WinRT) gearbeitet. Ich bin ausgebrannt, als es um UWP und Xamarin ging ...

Es ist schwer zu erkennen, was diese Iteration von all den anderen Malen unterscheidet, bei denen ich mir einen neuen XAML-Stack angesehen habe.

Microsoft hat einige fantastische UWP-Beispiel-Apps herausgebracht. Sie zeigen wirklich schön, was möglich ist.

Hier ist eine unvollständige Liste:

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

Es gibt noch viele weitere schöne Beispiele. Keines davon ist so aufgebaut, dass es leicht umfunktioniert oder strukturiert werden kann, sodass die Samples mit anderen Werken zusammenhängen.

Ich erinnere mich nicht annähernd so viel Aufwand mit entsprechenden WPF-Beispielen. Das ist meistens gut.

Das Problem? Es hat zu lange gedauert, bis wir mit UWP und XAML dort angekommen sind, wo wir jetzt sind. Und jetzt ist die Botschaft noch einmal verworren. Hätte Microsoft bei der ersten Veröffentlichung von UWP lediglich anständige Projektvorlagen mit Visual Studio bereitgestellt, würden wir UWP weniger negativ gegenüberstehen. Für die besten VS-Vorlagen müssen Sie hierher gehen:

https://github.com/microsoft/windowsTemplateStudio

Nicht sofort einsatzbereit, obwohl es sich um einen sehr flexiblen und vollständigen Satz von Bausteinen für UWP-Apps handelt. Wie findest du das alles? Keine Ahnung. Sich auf Schatzsuche zu begeben, um seine Arbeit zu erledigen, schafft kein Selbstvertrauen. Das Office-Team, das sich weigerte, WinRT zu übernehmen, half nicht. Sie treiben viel von dem, was in das Betriebssystem einfließt, unabhängig von ihrer theoretischen Armlängenreichweite. Fügen Sie Qualitätsprobleme, Fehler, den Ausfall von Windows Phone und inkonsistente Investitionen sowie Messaging hinzu und hier sind wir.

Microsoft hat einige fantastische UWP-Beispiel-Apps herausgebracht. Sie zeigen wirklich schön, was möglich ist.

@Noemata Ich stimme zu, sie sind wirklich coole Samples. Aber die Entwicklung einer komplexen App mit UWP ist verrückt. Es ist sicherlich möglich, aber es ist viel schwieriger. Ja, ich vermisse die "es funktioniert einfach"-Zeiten des WPF.

Eines der ersten Dinge, die MS als Beispiel geben sollte, ist eine einfache UWP-App, die Sie außerhalb des MS Store veröffentlichen können (und ja, es ist nicht so einfach, wie Sie denken).

Eine andere Sache, die mir nicht gefällt, ist, dass UWP mit Blick auf „mobile first“ gedacht wurde und die richtige Desktop-Erfahrung aufgegeben wurde.

Korrigieren Sie mich, wenn ich falsch liege, aber die meisten Entwickler verwenden UWP, um Desktop-Apps zu entwickeln, und die Benutzeroberfläche passt nicht dazu. Als erstes fällt mir die Bildlaufleiste ein, die von Anfang an für das Touchpad optimiert ist. Aber für Benutzer der Desktops ist das Bildlauferlebnis sehr schlecht (Nebenbemerkung: Ich denke, das WinUI-Team arbeitet daran, dies zu beheben). Ich habe ziemlich viel gegoogelt, um eine Lösung zu finden, die die Bildlaufleiste wieder "normal" macht - es ist einfach verrückt, dass ich nicht einfach eine API-Funktion aufrufen kann, um das zu tun.

Ebenso haben die Optionsfelder/Kombinationsfelder eine Mindestgröße, die auch für Mobilgeräte optimiert ist. Das einfache Setzen der Breite eines Optionsfeldes wird ignoriert, Sie müssen tatsächlich "MinWidth=0" setzen, damit es berücksichtigt wird.

Und die Farbe der Textschaltfläche ist weiß, dann schwarz im Fokus – was hat es damit auf sich? Und die Textschaltfläche hat ein "x", mit dem Sie sie löschen können - das ist das Touchpad - warum habe ich es dort, wenn es kein Touchpad gibt?

Im Standardtextfeld ist die Rechtschreibung aktiviert – warum sollte ich das wollen?

Es gibt andere Probleme, aber ich habe sie umgangen. Aber das größte Problem ist, dass Dinge, die 10 Minuten dauern sollten, normalerweise 2 Stunden oder länger dauern. Ich habe einfach die Fähigkeit zum Schätzen verloren - wenn ich sage, dass etwas einen halben Tag dauern wird, dauert es 2-3 Tage.

Grüße alle,
Da dies ein allgemeines Diskussionsthema ist und ich nicht weiß, wo ich sonst meine UWP-Wünsche / Feature-Anfragen platzieren soll ... nutze ich die Gelegenheit in diesem Thread:

• Bessere Unterstützung für die Integration von uwp-Apps in das Kontextmenü des Windows Explorers
  
  
  
  • Bitte unterstützen Sie uns hier https://aka.ms/AA6rmrk
  
  
• UWP-Markuperweiterung fehlt IServiceProvider und das Element selbst, für das die Markuperweiterung verwendet wird
• UWP -Stilauslöser fehlt
• Problem mit impliziten UWP-Datenvorlagen. Siehe zum Beispiel hier
• kein automatischer Druck ohne Benutzerinteraktion möglich (funktioniert nur für POS) siehe hier

Alle oben genannten Funktionen oder Probleme wurden auf Uservoice behoben, das jetzt aufgegeben wird. Weiß jemand, was mit diesen Problemen passiert ist? Sollten wir sie auf Feedbackhub neu erstellen?

Ich liebe den Ausdruck „Die vergessenen Entwickler“. Ich kenne viele von ihnen, die talentiert, erfahren und leidenschaftlich für Technologien sind. Sie sind erfahrene .Net-Entwickler. Ich habe keinen Zweifel, dass sie im Allgemeinen bessere Apps erstellen können als viele Kinder, die von der App-Entwicklung für iOS und Android profitieren.
Wenn WinUI ihnen einen angenehmen und robusten Weg bieten kann, ihre umfangreiche Erfahrung in C# + .Net + Xaml zu nutzen, um Apps für Windows, Android, iOS und Web zu erstellen, werden viele auf den Wagen aufspringen und die Welt wird von ihrer hohen Qualität profitieren. hochwertige Apps.
WinUI + Uno Platform könnte der ultimative Aufruf sein.

In der UWP-Markuperweiterung fehlt IServiceProvider und das Element selbst, für das die Markuperweiterung verwendet wird

Haben Sie hier abgedeckt @mfe- !

Haben Sie hier abgedeckt @mfe- !

@Mike-EE Wow, das ist großartig! Ich erinnere mich, dass ich darauf gestoßen bin, als ich CalcBinding auf UWP portieren wollte. Was ich am Ende getan habe, ist eine Problemumgehung, bei der ich schreibgeschützte Felder im Ansichtsmodell hinzufüge.

"Einmal schreiben, überall ausführen".

Davon ist Microsoft vor einiger Zeit abgerückt.

Gute Arbeit, wir sind berühmt! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Die vergessenen Entwickler schweigen oder werden einfach ignoriert

Ich liebe den Ausdruck „Die vergessenen Entwickler“.

Lasst uns unter diesem Namen organisieren! 💪

Ich wünsche mir nur ein plattformübergreifendes UI-Framework, das von Microsoft entwickelt und unterstützt wird. Es gibt einfach nichts für das .NET-Ökosystem da draußen, außer _Uno Platform_ und _Xamarin.Forms_ (wenn sie noch daran arbeiten, den Desktop anzusprechen).

Und selbst wenn ich mich entscheide, eine reine Windows-Geschäftsanwendung von Grund auf neu zu schreiben, glaube ich nicht, dass Microsoft sich vollständig auf UWP festgelegt hat. Korrigieren Sie mich, wenn ich falsch liege, aber haben sie die Office UWP-Apps nicht zugunsten der Office Online-PWAs aufgegeben? Wenn MS sein eigenes First-Party-Framework fallen lässt, warum sollte ich dann auf UWP vertrauen? _hust Silberlicht_

Zum Glück wurde WPF noch nicht aufgegeben. Aber das verstärkt nur meine Zweifel.

Gute Arbeit, wir sind berühmt! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Stechpalme 🤭

Super! Lassen Sie uns auf andere große Zeitschriften, Websites usw. ausdehnen 😛

Wer eine plattformübergreifende Lösung für die Entwicklung von Apps sucht, ist bei Unity genau richtig:

https://unity.com/

Wie alle diese Lösungen erhalten Sie am Ende ein Framework, das ein Mini-Betriebssystem umfasst. Java war das geschickt als Programmiersprache getarnte Betriebssystem.

Ein moderner Browser ist jetzt ein Mini-Betriebssystem. Ich denke, davon haben wir genug. WinUI/UWP soll die native Benutzeroberfläche für Windows 10 und höher sein. Es kann sinnvoll sein, eine XAML-Engine zu haben, die an mehreren Stellen ausgeführt wird. Ich bin nicht überzeugt, dass das gegen den Gegenwind von Dingen wie Unity fliegen würde. Ich würde lieber eine ausgefeilte, qualitativ hochwertige UWP sehen, bevor Microsoft loslegt und beginnt, Silverlight neu zu erfinden, damit wir XAML auf anderen Plattformen hosten können. Wir alle wissen, wie gut das funktioniert hat. Wenn Sie sich Unity nicht angesehen haben, verpassen Sie etwas. Seien Sie jedoch darauf vorbereitet, viel zu programmieren und noch mehr zu debuggen.

Nächste Woche werde ich eine Reihe von VS-Vorlagen für UWP veröffentlichen, mit denen Sie Apps in Sekundenschnelle erstellen können. Dies wurde für "interne" Projekte verwendet. Es wird beweisen, dass UWP ein sofort einsatzbereites RAD-Framework sein kann, wenn nur VS die richtigen Bausteine ​​eingebaut hätte.

Nächste Woche werde ich eine Reihe von VS-Vorlagen für UWP veröffentlichen, mit denen Sie Apps in Sekundenschnelle erstellen können. Dies wurde für "interne" Projekte verwendet. Es wird beweisen, dass UWP ein sofort einsatzbereites RAD-Framework sein kann, wenn nur VS die richtigen Bausteine ​​eingebaut hätte.

@Noemata Das klingt cool! Ich bin ziemlich neugierig!

Wenn Sie alle ein .Net-basiertes, plattformübergreifendes UI-Framework wünschen, das sich an jede Designsprache anpassen kann. Suchen Sie nicht weiter, Comet ist es.

https://github.com/Clancey/Comet

Wenn Sie etwas Freizeit haben, leisten Sie einen Beitrag, da es noch in den Anfängen steckt.
Comet zielt im Grunde auf alle existierenden Plattformen ab, und es gibt Ihnen die Wahl, die native Steuerung auf jeder Plattform anzustreben oder Skia zu verwenden, um alles zu zeichnen, damit sie alle konsistent sind (genau wie Flutter es macht).

Es verwendet deklarative UI- und MVU-Muster. Es wurde von James Clancey, Principal Program Manager Architect bei Microsoft, entwickelt. Obwohl es noch nicht offiziell unterstützt wird, aber mit genügend Community-Traktion kann es sein.

In Comet ist die Benutzeroberfläche nur eine Bibliothek, sodass Sie (oder vielleicht Microsoft) eine WinUI-Bibliothek entwickeln können, genau wie Comet eine Materialdesign-Bibliothek hat.

Wenn Sie alle ein .Net-basiertes, plattformübergreifendes UI-Framework wünschen, das sich an jede Designsprache anpassen kann. Suchen Sie nicht weiter, Comet ist es.

@nerocui das klingt cool, aber zumindest so gesehen gibt es keinen XAML-Designer. Das Erstellen komplexer UIs ist in seinem derzeitigen Stadium wahrscheinlich verrückt. Aber es sieht vielversprechend aus.

Wenn Sie alle ein .Net-basiertes, plattformübergreifendes UI-Framework wünschen, das sich an jede Designsprache anpassen kann. Suchen Sie nicht weiter, Comet ist es.

@nerocui das klingt cool, aber zumindest so gesehen gibt es keinen XAML-Designer. Das Erstellen komplexer UIs ist in seinem derzeitigen Stadium wahrscheinlich verrückt. Aber es sieht vielversprechend aus.

Und es geht nicht um Drag-and-Drop, sondern um eine Echtzeit-Vorschau der Benutzeroberfläche im Designer, wenn eine Änderung im Code vorgenommen wird.

Nächste Woche werde ich eine Reihe von VS-Vorlagen für UWP veröffentlichen, mit denen Sie Apps in Sekundenschnelle erstellen können. Dies wurde für "interne" Projekte verwendet. Es wird beweisen, dass UWP ein sofort einsatzbereites RAD-Framework sein kann, wenn nur VS die richtigen Bausteine ​​eingebaut hätte.

Wird NoesisGUI verwendet? Wenn dies der Fall ist, fehlen VIELE Funktionen, die für LOB-Apps erforderlich wären. Nun, WinUI, das auf Unity abzielt, wäre großartig.

Ich habe ein Repo erstellt, um den aktuellen Stand von XAML zu dokumentieren, und hoffentlich werden die Leute helfen und mit Erkenntnissen und tatsächlichen Codeausschnitten beitragen, die auflisten, wie Aufgaben in den verschiedenen Varianten von XAML ausgeführt werden können.

https://github.com/gatewayprogrammingschool/XAML-Standardisierung

Einfaches Problem, gehen Sie über die Sandbox von heute hinaus und nehmen Sie an, was für Cross-Plattform erforderlich ist. Ich tue es bereits für jeden anderen Aspekt von Windows / OS, warum nicht die Benutzeroberfläche.

Nehmen Sie die Sandkasten-Querplattform.

Von: anthonyadame [email protected]
Gesendet: Samstag, 29. Februar 2020 20:00:13 Uhr
An: microsoft/microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Kommentieren Sie [email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] Diskussion: WinUI sollte plattformübergreifend sein (#2024)

Einfaches Problem, gehen Sie über die Sandbox von heute hinaus und nehmen Sie an, was für Cross-Plattform erforderlich ist. Ich tue es bereits für jeden anderen Aspekt von Windows / OS, warum nicht die Benutzeroberfläche.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 oder abmelden https://github.com/ Benachrichtigungen/unsubscribe-auth/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

Die Integration hochleistungsfähiger C++-Komponenten in C# ist unter UWP trivial. Auch der Zugriff auf DirectX-Oberflächen wurde deutlich verbessert.

@Noemata Abgesehen davon, dass ich nicht C++ schreiben muss, verpfuscht WinDev weiterhin alle Versuche, die .NET-Sprachen in Bezug auf C++-APIs, Managed Direct X, XNA und die richtige AOT-Kompilierung von .NET auf Augenhöhe machen würden Code, COM-Features, ....

WinUI 3.0 plattformübergreifend zu machen, wird dieses Argument für die Portierung bestehender .NET/Forms-Anwendungen auf WinUI sein.

Für den Anfang reicht es aus, macOS zu unterstützen, und es ist kein Problem, wenn es nicht die gleiche Leistung wie unter Windows oder nicht alle Funktionen wie Animationen hat.

Windows ist die Referenzplattform; Natürlich muss es für die beste Leistung mit DirectX gekoppelt werden.

Meiner Meinung nach macht es keinen Sinn, große C#-Anwendungen in HTML+JS umzuschreiben, nur um macOS zu unterstützen. Und auch für neue Desktop-Anwendungen ist C# die bessere Wahl.

Für Desktop-Anwendungen sind C# und XAML viel zuverlässiger als HTML+JS.

Die plattformübergreifende Gestaltung von WinUI 3.0 sichert die Zukunft von .NET, C# und XAML.

Hallo alle

Ich bin ein WPF-Vertragsentwickler und arbeite in London. Seit 2006 baue ich komplexe Hochleistungs-Benutzeroberflächen mit WPF für eine Reihe von Finanzinstituten. Hier ist meine Meinung dazu:

1) Ich beobachte den Arbeitsmarkt in Großbritannien genau. 100 % der seit 2006 ausgeschriebenen WPF-Stellen (von denen es 1000 gab) beziehen sich auf die Entwicklung leistungsstarker Desktop-Apps für den Finanzhandel für den Finanzsektor. Es ist noch keine Stelle für einen UWP-Entwickler für irgendeine Branche ausgeschrieben.

2) Diese Desktop-Trading-Apps können UWP oder das kommende WinUI nicht verwenden – es ist aus vielen komplexen Gründen im Vergleich zu WPF einfach nicht gut genug. Auch Fluent Design ist nichts, woran diese Benutzer interessiert sind - es muss nur wie ein Excel-Raster aussehen - keine Animationen, kein Styling - nur Daten und erstaunliche Leistung.

3) Diese Kunden haben überhaupt kein Interesse an plattformübergreifenden Lösungen. Niemand verwendet einen Mac, und Mobilgeräte sind nicht etwas, woran sie interessiert sind.

4) Diese WPF-Entwicklerteams haben große Investitionen (Zeit und Geld) in WPF-Steuerungsbibliotheken von Drittanbietern getätigt oder komplexe, leistungsstarke benutzerdefinierte Steuerungssuiten für sie von Leuten wie mir entwickeln lassen. Sie werden sich nicht von WPF entfernen, es sei denn, es gibt einen sehr signifikanten Vorteil (den es auf absehbare Zeit nicht geben wird).

5) Für diese Finanzinstitute wird jede Anwendung, die nicht explizit für Desktop / WPF geschrieben werden muss, mit Webtechnologien und Javascript geschrieben. Sie interessieren sich nicht für etwas Exotischeres als das - kein Flattern, kein Blazor usw.

Das ist also die Situation in Großbritannien. Hunderte von WPF-Entwicklern haben nicht vor, in absehbarer Zeit in etwas Neues einzusteigen. Null UWP-Entwickler (mit Ausnahme vielleicht einer Handvoll Ein-Mann-Bands, die Apps für den Store entwickeln – was angesichts des Zustands des Stores zweifelhaft ist)

Außerdem verstehe ich die ganze Hysterie über Cross-Plattform nicht. Cross-Plattform, die sowohl Mobilgeräte als auch Desktops umfasst, ist ein Kinderspiel. Wird nie interessant. Microsoft versuchte dies mit UWP-Apps, die auf Desktop und Telefon liefen – es war eine Katastrophe – und beschränkte Apps auf die einfachsten UIs, die nichts Komplexes oder Interessantes leisten konnten. Desktop- und Mobilgeräte sind für unterschiedliche Aufgaben und Anwendungsfälle konzipiert und benötigen unterschiedliche Apps – das wissen wir alle.

Für mich möchte ich, dass mein Microsoft viel mehr direkt in WPF investiert, ohne die Abwärtskompatibilität zu opfern. Ich möchte, dass WPF die Steuerungsentwicklung in nicht verwaltetem C++ unterstützt, damit wir näher am Metall arbeiten können. Ich möchte eine bessere Bindungstechnologie, bessere Datenvorlagen, eine bessere Steuerungsvorlagenfunktionalität einschließlich teilweiser Vererbung sehen. Ich möchte bessere Debugging-Tools und visuelle Baumanalysatoren sehen. Ich möchte, dass das XAML-Debugging weiter ausgearbeitet wird. Ich möchte eine bessere Multithreading-Unterstützung in der Benutzeroberfläche. Ich möchte viele, viele Dinge, und meine Kollegen von WPF-Auftragnehmern in Großbritannien auch.
Die aktuelle Microsoft-Roadmap gibt mir nichts von dem, was ich will, und all das, was mir egal ist.

Wenn Microsoft diese Vision nicht unterstützt (was sie derzeit eindeutig nicht tun), dann wird Plan B darin bestehen, dass die Community WPF durch Open-Source-Beiträge in die Plattform formt, die es sein muss – vorausgesetzt, Microsoft akzeptiert eine leichtere Handhabe, wenn es darum geht, Neues zuzulassen Code und Ideen, um Teil des WPF-Frameworks zu werden.

@deanchalk Ich denke, das meiste davon hätte besser im WPF-Repo platziert werden können, um ihnen zu zeigen, dass Interesse an WPF besteht. Wenn Sie es hier posten, bedeutet dies meistens, dass Sie nicht daran interessiert sind, was im WinUI-Repo / in dieser Ausgabe besprochen wird. Während das ein gültiger Input ist, wird er wahrscheinlich nicht zu etwas Konstruktivem führen, das über leere Diskussionen hinausgeht.

@weltkante @deanchalk Es gibt ein Problem im Repo, das nach "Legacy Control Support" in WinUI fragt: https://github.com/microsoft/microsoft-ui-xaml/issues/1833
Zumindest Punkt 4) passt zu diesem Thema und sollte wahrscheinlich dort erneut gepostet werden, um für eine Investition von Microsoft zu plädieren.

@deanchalk , ich bin immer noch ein großer WPF-Fan. Es ist ein wunderbares Werkzeug, das glücklicherweise von Microsoft etwas Liebe bekommt. Die Art und Weise, wie Microsoft sich entschieden hat, WPF überhaupt fallen zu lassen, war äußerst unglücklich. Dass UWP das glänzende neue Spielzeug ist, hätte weitere Investitionen in WPF nicht ausschließen sollen.

UWP war in vielerlei Hinsicht der richtige Weg nach vorne. Leider ignorierten die ersten Iterationen einige der kritischsten Anforderungen für Leute, die WPF verwendeten und möglicherweise eine Migration in Erwägung gezogen hatten. Nicht zuletzt der ziemlich erschreckende Zustand der XAML-Fragmentierung innerhalb der Mauern einer einzelnen Organisation. WPF != Silverlight != UWP != Xamarin. Beeindruckend!

Ich habe weniger Verständnis für WPF-Entwickler, die sich entschieden haben, sich im Jahr 2020 in WPF zu verankern. Die Dinge haben sich erheblich weiterentwickelt. XAML-Inseln mit der Möglichkeit, die WinRT-API zu verwenden, bieten Ihnen einen relativ einfachen Weg, um mit der Migration zu UWP zu beginnen. Und UWP fehlt nicht mehr, wenn Sie sich für eine Großhandelsumwandlung entschieden haben.

Das größere Problem bleibt der Mangel an Klarheit von Microsoft darüber, was wirklich als nächstes kommt. Alle, die auf XAML Nirvana gehofft haben, gaben das Silverlight-Fiasko auf, das sich mit UWP erneut wiederholt.

WinUI ist so offensichtlich ein umbenanntes UWP, dass es schmerzhaft ist, dies mitzuerleben. Und es ist ebenso offensichtlich, dass Microsoft hofft, dass wir alle vergessen, was UWP ist/war.

Dennoch stimmt die linke Hand von Microsoft nicht immer mit dem überein, was die rechte Hand tut. WindowsX hat Win32 und alles, was dazugehört (WPF/Winforms/etc.) zu einer schwachen Perspektive für Anwendungen gemacht, die in seiner Sandbox mit geringerer Leistung "möglicherweise" ausgeführt werden. UWP ist und bleibt die native Benutzeroberfläche für Windows 10, WindowsX und darüber hinaus. Die WinRT-API ist eine große Verbesserung gegenüber Win32. Ich denke, Sie müssen sich entscheiden, ob Sie in die 2020er Jahre wechseln oder in den 2010er Jahren durchhalten möchten.

WinUI ist so offensichtlich ein umbenanntes UWP, dass es schmerzhaft ist, dies mitzuerleben. Und es ist ebenso offensichtlich, dass Microsoft hofft, dass wir alle vergessen, was UWP ist/war.

@Noemata WinUI ist ein neues Produkt, das auf UWP-APIs (XAML, Composition, Input,...) basiert. Der Name ist sinnvoll, da Sie ihn zum Erstellen von Benutzeroberflächen für Windows-Apps verwenden können, unabhängig vom zugrunde liegenden App-Modell.

Ich bin verwirrt. Sie selbst erwähnen 10X im letzten Absatz. Das UWP-App-Modell selbst bekommt mit Windows 10X einen Push. Ob 10X erfolgreich sein wird, wird nur die Zeit zeigen können. Aber MS war in seiner Botschaft klar: UWP ist die native Plattform von 10X (neben dem Web), wie Sie betont haben.

@Noemata bis 2020 holt die 2010 verfügbaren Funktionen ein, viele von uns sind gezwungen, 2010 zu bleiben.

Viele von uns haben den Umschreibungszug, der damit begann, Silverlight, XNA fallen zu lassen, satt und zu sehen, wie MS die für .NET Core und WinUI erforderlichen Umschreibungen per Hand winkt und dabei Funktionen fallen lässt, gewinnt nicht die Herzen vieler von uns Kunden mit voll funktionsfähigen Anwendungen, die nicht einsehen, warum sie Umschreibungen bezahlen sollten, um weniger Funktionen zurückzubekommen.

Dank der Cleverness, Android- und Windows 10 X-Tablets zu haben, freuen wir uns derzeit auf Xamarin und PWAs, nicht auf WinUI.

@pjmlp vielleicht. Mich würde interessieren, welches Feature du vermisst? Ich habe einige ziemlich große WPF-Apps auf UWP portiert. Die größten Kopfschmerzen bereitete die Sicherheits-Sandbox und das Lernen, damit zu arbeiten, anstatt dagegen anzukämpfen. Früher fehlten Teile wie das Data Grid, DB-Konnektivität, eine anständige API für Hochgeschwindigkeitskommunikation und so weiter. Jetzt fehlt nur noch sehr wenig. Es gibt eine Menge, die ich in WPF nicht annähernd so einfach machen könnte. Um fair zu sein, derzeit gibt es nichts, was ich in WPF nicht tun könnte, indem ich den Zugriff auf die WinRT-API nutzte, außer dass ich eine geringere Leistung hätte, weil UWP optimaler in Maschinencode kompiliert und einen besseren DirectX-Rendering-Stack verwendet. Außerdem müssen Sie Ihren WPF-Code verschleiern (ihn zerbrechlicher machen), wenn Sie Ihr geistiges Eigentum schützen oder Eindringlingen vorbeugen möchten.

Telefone/Tablets sind großartige Geräte für Anwendungen mit Punktlösungen. Ich möchte keine Symphonie auf einem Telefon spielen oder einen Wolkenkratzer entwerfen, und ich möchte lieber einen Teil der Punktlösungen meiner Desktop-App auf Mobilgeräte ausrichten, als zu versuchen, Mobilgeräte auf meinem Desktop zum Laufen zu bringen.

@Felix-Dev Ich verstehe, was WinUI ist. Ich frage mich, warum noch ein weiterer Fork erforderlich war, nur weil WPF-, Winforms- und MFC/Win32-Entwickler sich nicht darauf einließen. Die bessere Strategie wäre gewesen, Migration entweder attraktiver oder weniger schmerzhaft oder beides zu machen.

Microsoft hat mit UWP vieles richtig gemacht. Es gibt eine Fülle von Beispiel-Apps, die alle möglichen Anwendungsfälle abdecken. Sie kamen zu spät, ebenso wie die fehlenden Merkmale. Ist es wirklich zu spät?

@Noemata WinUI wäre wahrscheinlich so oder so passiert (mit oder ohne WinUI-Desktop), da das Entkoppeln des UWP-UI-Stacks vom Betriebssystem ein absolut notwendiger Schritt ist. Es wäre am besten gewesen, wenn WinUI bereits existiert hätte, als Windows 10 zum ersten Mal veröffentlicht wurde, aber es gibt Gründe, warum das nicht der Fall war.

Ist es zu spät ... wir hatten viele solcher Diskussionen im Discord-Kanal der UWP-Community und auch unzählige leidenschaftliche Diskussionen hier. Einige von uns denken, dass das Schiff bereits gesegelt ist, während andere immer noch glauben, dass die UWP-Plattform/WinUI wachsen und reifen kann, um eine wichtige Entwicklungsplattform zu werden. Viele Leute mit vielen Ideen, wie der beste Ansatz für MS aussehen könnte (dh xplatform gehen oder nicht?). Tatsache ist, dass das Team derzeit hart an WinUI 3 arbeitet und seine Veröffentlichung den Beginn der eigentlichen Herausforderung signalisieren wird: WinUI voranzutreiben – mit der Hilfe der Community – damit es das Framework der Wahl für Entwickler wird, die auf Windows abzielen .

@Noemata , vor allem Kompatibilität mit bestehenden Komponentenbibliotheken von Drittanbietern wie Telerik, Component One, ...

Dann müssen wir, wie erwähnt, zunächst nichts umschreiben, wir haben es satt, umzuschreiben.

Was DirectX betrifft, werden nicht nur die 3D-Modellierungsklassen von WPF nicht unterstützt, wir sollen C++ schreiben, weil Microsoft sich nicht die Mühe macht, Runtime-Projektionen für DirectX zu erstellen, und der irgendwie angenehme C++/CX-Dialekt wurde durch den wortreichen ersetzt weniger leistungsfähig, aber besser kompatibel, C++/WinRT.

Darüber hinaus müssen wir nicht nur perfekt funktionierenden WPF-Code wegwerfen, wir müssen dasselbe mit WCF-, EF6-Code tun.

Ich glaube immer noch, dass UWP eine viel bessere API ist als Win32, irgendwie das, was Longhorn hätte sein sollen, aber die Art und Weise, wie dies ausgespielt wird, hat einfach zu viele Brücken abgebrannt, da Microsoft das Umschreibungsbudget vieler Organisationen verbrannt hat.

@pjmlp , das sind alles gute Punkte mit eher sanften Gegenargumenten, also werde ich es nicht einmal versuchen. Keine Unterstützung für die WPF 3D API war für mich persönlich ein schwerer Schlag. Einen neuen Ansatz lernen zu müssen, machte keinen Spaß und war angesichts der WPF-Bindungsoptionen für 3D viel weniger leistungsfähig. C#-Alternativen für 3D unter UWP sind vorhanden, nur viel weniger nützlich, wenn Sie die Vorteile der Bindung an ein 3D-Modell kennengelernt haben.

C++/CX war ein weiterer Schmerzpunkt, der zu lange dauerte, um von C++/WinRT gelöst zu werden, das nächste Woche irgendwann stabil sein könnte (es verschiebt sich noch).

WCF ist tot (sorry, neue Optionen sind viel, viel besser). EF6 hätte eine viel bessere Migrationsgeschichte haben sollen. Sie haben absolut Recht mit dem Fiasko des neu geschriebenen Budgets @pjmlp , eindeutig ist dies etwas, das Microsoft früher bekommen hat und das angesichts der verrückten / inkonsistenten Abwanderung von Technologie nicht mehr berücksichtigt wird.

@Felix-Dev, auch Sie machen völlig gültige Punkte. Die UI-Entkopplung sollte von Anfang an da gewesen sein. Die Leute, die nach einer xplatform-Benutzeroberfläche auf Basis von XAML fragen, sollten ihre Anfrage umformulieren und nach einer XAML-Rendering-Engine auf ihrer bevorzugten Plattform mit einem Mini-Betriebssystem fragen, um die API-Oberfläche zu replizieren (eine andere Java/Silveright/Uno-Plattform/Unity/was auch immer … schließlich das mit HTML endet, das den Metal-Apps nahe kommt, kann nicht in Erwägung gezogen werden). Ich bin im Moment nicht in die neuesten MS-internen Initiativen eingeweiht. Wenn Sie von außen nach innen schauen, ist WinUI die wehende Flagge, die anzeigt, dass das Schiff wieder aufgerichtet wird (wie oft noch?). Die Verteidigung von Microsoft wurde mit dem Tod von Silverlight unmöglich. Ich werde dieses Schwert nicht mehr in die Hand nehmen. Ich nehme an, was ich wirklich tue, ist den Tod von UWP zu beklagen :-( ... schmerzhaft. https://www.youtube.com/watch?v=uBiewQrpBBA

Charlie == Microsoft

Plattformübergreifend? Microsoft sollte einfach UNO kaufen und mit Tit fertig sein.

Plattformübergreifend? Microsoft sollte einfach UNO kaufen und mit Tit fertig sein.

Ich würde hoffen, dass die sich bietende Lösung nicht auf einen Webbrowser oder eine Art Webansicht angewiesen ist. Zeigen Sie die UI in dem nativen Fenster oder der UI-Oberfläche der Plattform an – sehen aber genauso aus wie unter Windows.

Plattformübergreifend? Microsoft sollte einfach UNO kaufen und mit Tit fertig sein.

Ich würde hoffen, dass die sich bietende Lösung nicht auf einen Webbrowser oder eine Art Webansicht angewiesen ist. Zeigen Sie die UI in dem nativen Fenster oder der UI-Oberfläche der Plattform an – sehen aber genauso aus wie unter Windows.

So macht es UNO, außer unter Windows 7. Windows 7 ist die einzige Ausnahme, da es den Webbrowser verwendet.

Für diejenigen WPF-Entwickler, die eine plattformübergreifende Desktop-Lösung benötigen, ist Wine möglicherweise eine praktikable Option für Sie. Ich hatte großen Erfolg bei der Portierung großer WPF-Anwendungen (hauptsächlich .NET Core WPF) für die Ausführung unter Linux mit Wine. Ich habe eine Beschreibung, die Ihnen beim Einstieg helfen kann:
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

Ich habe auch damit begonnen, einige WinForms-Apps auch auf Linux zu portieren. Bisher bin ich auf keine Probleme gestoßen.

Wine sollte es Ihnen auch ermöglichen, auf Mac, Chrome OS und Android zu laufen. Ich habe es nur mit Linux versucht.

Für mich zeigt dies, dass die Verwendung von DirectX als Abstraktionsschicht funktioniert und ein praktikables Modell ist, dem man folgen kann. Ich vermute, es würde sogar im Web mit WebGL gut funktionieren, sobald .NET WASM ausgereifter ist.

Microsoft dazu zu bringen, mit Wine zu helfen (zumindest sicherzustellen, dass sie es nicht kaputt machen), würde sehr helfen. Sie könnten helfen, eine wirklich native Lösung mit WineLib zu erstellen, und angesichts ihres Fachwissens denke ich nicht, dass es zu viel Aufwand wäre.

AvaloniaUI ist bereits plattformübergreifend. Warum bitten Sie die Projektmitarbeiter nicht um Hilfe und Feedback, um WinUI zu verbessern?

Nun, nicht so sehr wie die Uno-Plattform. Die Uno-Plattform läuft auch im Web (WASM). Avalonia fehlt diese Fähigkeit.

Avalonia verwendet auch seinen eigenen XAML-Dialekt, was Uno zu vermeiden versucht.

Von: Shimmy [email protected]
Gesendet: Freitag, 27. März 2020 4:09:30 Uhr
An: microsoft/microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Kommentieren Sie [email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] Diskussion: WinUI sollte plattformübergreifend sein (#2024)

AvaloniaUI ist bereits plattformübergreifend. Warum bitten Sie die Projektmitarbeiter nicht um Hilfe und Feedback, um WinUI zu verbessern?

Nun, nicht so sehr wie die Uno-Plattform. Die Uno-Plattform läuft auch im Web (WASM). Avalonia fehlt diese Fähigkeit.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 an oder kündigen Sie https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA .

Der größte Teil der WinUI-Technologie stammt von Sliverlight, und Sliverlight hat es tatsächlich geschafft, plattformübergreifend zu sein. Die plattformübergreifende WinUI hängt also von der Strategie ab, nicht von der Technologie.

Ehrlich gesagt ... es ist eigentlich so erbärmlich, dass Microsoft jetzt versucht, aufzuholen ... sie kümmern sich nur um "große" Marktanteile, sie achten nicht darauf, was ihre Kunden / Produktfans wollen.

Microsoft ist der Grund, warum sich die Entwicklung von DESKTOP-APPs auf die veraltete WEB-Entwicklung verlagert hat, auch wenn das Web so schrecklich ist.

Ich bin mir sicher, dass jeder XAML-Entwickler zustimmt, dass HTML/CSS so Müll ist.

Aber immer noch ... HTML, CSS, DOM ... mit Frameworks wie React, Angular, Vue, die versuchen, es etwas angenehmer zu machen. Die Leute konzentrierten sich immer noch auf dieses veraltete Web, nicht auf die neue Closed-Source-Windows-Only-Plattform von Microsoft, die alle 2-4 Jahre für eine neue stirbt.

XAML-basierte Win-App-Plattform hätte schon vor JAHREN Open-Source sein sollen. Es sollte eine einmalige Bereitstellung auf WEBSITE, Windows, Mac, Linux, Android (jede Plattform, die der Kunde wünscht) haben. Windows Store sollte plattformübergreifend mit einem XAML/UWP-App-Renderer sein. (ähnlich wie Google Chrome plattformübergreifend mit HTML/CSS-Renderer ist).

Während des goldenen Zeitalters von Microsoft hätte eine XAML-basierte plattformübergreifende App das Web zerstören können, dann müssten wir uns nicht mit diesem CSS, HTML, DOM und unzähligen Frameworks auseinandersetzen.

Aber nein, die Besessenheit von Microsoft mit proprietärer Software hat dazu geführt, dass sie an das Internet verloren gegangen sind.

Mittlerweile wird Googles Flutter zu dem, was ich mir immer für XAML gewünscht habe.

Ich gehe davon aus, dass WinUI 3 eine Zielplattform in MAUI sein wird. Die Uno-Plattform hat bereits angekündigt, dass WinUI 3 Preview unterstützt wird.
Also, @jeromelaban / Microsoft, was wir wahrscheinlich wirklich brauchen, ist die Uno/MAUI-Vereinheitlichung? MAUI ist meiner Meinung nach weniger nützlich als Flutter oder Uno ohne ein Web- (Browser-) Ziel.

Bitte hinterlassen Sie Ihre Kommentare auch im MAUI-Repository .

WPF (Silverlight) überall!

Die Portierung von DirectX auf andere Plattformen scheint eine gewaltige Arbeit zu sein, vielleicht besteht die Lösung darin, OpenGL oder Vulkan anstelle von DirectX zu verwenden

Google hat ANGLE, mit dem OpenGL ES nativ auf jeder Plattform ausgeführt werden kann, indem Aufrufe und Shader in native APIs übersetzt werden (Desktop gl [möglicherweise von Swiftshader-Software-Renderer bereitgestellt], Vulkan, DirectX, Metal). Es ist auch ein Kernbestandteil von Chrome und Flutter und läuft neben Skia.

Microsoft könnte eine kleine (vielleicht nur als Ausgangspunkt) Teilmenge von DirectX für GUI-Apps erstellen und sie in native APIs übersetzen lassen, genau wie ANGLE es tut.

Was das Problem der „Unterstützung unterschiedlicher Linux-Distributionen“ betrifft, so sind Linux-Benutzer oft geschickt genug, um Inkompatibilitäten selbst zu beheben, und selbst dann gibt es Flatpak, das die Paketierung für Desktops vereinheitlicht, genau wie Docker dies für Server tut.

Erwähnt im Lonje-Chat https://www.lonje.com/message/1968439855/

Ich denke wirklich, dass WinUI auch native Themen auf Mac und Linux unterstützen sollte, während es weiterhin benutzerdefinierte Themen unterstützt.
Bei Mac-Benutzern bin ich mir nicht sicher, aber die Linux-Community kontrolliert gerne, wie ihr Desktop aussieht.
Sie haben bereits Gtk, was meiner Meinung nach eine gute Sache wäre, um es in das WinUi-Framework einzubinden

Ich denke wirklich, dass WinUI auch native Themen auf Mac und Linux unterstützen sollte, während es weiterhin benutzerdefinierte Themen unterstützt.
Bei Mac-Benutzern bin ich mir nicht sicher, aber die Linux-Community kontrolliert gerne, wie ihr Desktop aussieht.
Sie haben bereits Gtk, was meiner Meinung nach eine gute Sache wäre, um es in das WinUi-Framework einzubinden

Dies ist auf jeden Fall schwierig, da WinUI eine Stilsprache ist und die zugrunde liegenden XAML-Frameworks erfordern, dass Sie die Themen selbst vornehmen, während auch Standardthemen bereitgestellt werden.

Ich habe in der Vergangenheit vorgeschlagen, dass das Projekt so strukturiert werden sollte, dass es der Community ermöglicht wird, einen Metal-Renderer für macOS und iOS zu entwickeln – und möglicherweise einen Skia-Renderer für Android.

Dieselben Standardstile und -vorlagen könnten auf allen Plattformen verwendet werden, oder es könnten Standardvorlagen und -ressourcen im Stil von Android und macOS erstellt werden.