Dies sind meine ersten Gedanken zu den Fragen, die Sie im Inhalt der Ausgabe gestellt haben.

Ich komme aus einer Design- und Benutzerperspektive, mit nur wenig Entwicklungserfahrung, die sich damals sehr für die Entwicklung von Silverlight / Windows Phone 7 interessierte und sich jetzt ein wenig verbrannt fühlt.

Welche Vorlagen würden Sie am meisten interessieren?

Ich denke, bevor Sie nach einer Liste von Vorlagenideen fragen, muss eine Art Audit der größten und am häufigsten verwendeten Apps in jedem Framework durchgeführt werden, also WPF, UWP, WinForms, MFC usw.

Untersuchen Sie die "Silhouette" dieser Apps und finden Sie die gängigen UX-Szenarien heraus.

Aus meinem Kopf heraus gibt es:

• Hauptmenü (Alle Frameworks)
• MDI (mehrere Dokumente in einem einzigen Fenster) (meistens MFC)
• Registerkarten und Datagrid (WPF, WinForms, MFC)
• Multifunktionsleiste (Win32-Apps Office, 3ds max, Paint, Wordpad, Datei-Explorer usw.)
• Dienstprogramme in der Taskleiste (MFC, WinForms)
• Browser
• Assistenten (WPF, MFC)
• Komplexe MDI-Apps (Adobe-Software, Visual Studio)
• Mediaplayer
• Datenvisualisierung LoB (WPF und Web)
• Soziale Apps (React Native, PWA – Skype, Facebook, Twitter)

Alle oder einige davon könnten von der WinRT/UWP-Systemintegration mit Notifications/Action Center profitieren.

Alle diese neuen Projektvorlagen sollten die integrierten Windows.Xaml-Namespaces, das WPF-Steuerelementdesign und die visuellen WinForms-Stile zugunsten neuer Vorlagen und visueller Stile vermeiden, die den FabricWeb/Fluent-Steuerelementdesigns entsprechen.

Es sollte auch eine einfache Möglichkeit für Entwickler mit vorhandenen WPF- und WinForms-Apps geben, eine WinUI 3.0-Abhängigkeit hinzuzufügen, die ihnen die neuen Steuerelementdesigns mit einer einfachen using-Anweisung oder einem Manifesteintrag zur Verfügung stellt

XAML-Inseln

Da Xaml-Inseln einfacher zu ermöglichen wird - das Ersetzen alter Webview-Steuerelemente, Farbauswahlen und XAML-basierter Dialoge könnte so einfach sein wie ein Hinzufügen neuer ... sie haben ihren eigenen CodeBehind.

Moderne App- und Seitenvorlagen wie Xbox Next-Apps, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop und Pivot – könnten alle für alle Windows-Präsentationsplattformen verfügbar gemacht werden – mit XAML-Inseln und Beispielinhalten.

Jedes dieser Szenarien, die derzeit in UWP XAML nicht möglich sind, sollte mit Steuerelementen und Vorlagen ausgestattet sein, um dies zu vereinfachen.

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Diese Frage sollte gestellt werden, wenn jemand sein Projekt in der neuesten Version von Visual Studio mit einem aktuellen Windows 10 SDK öffnet. Drücken Sie die Schaltfläche und es ersetzt entweder die Namensräume und die Verwendung oder markiert sie, wenn es sich nicht um ein Steuerelement handelt, mit dem es vertraut ist.

Bei neuen Projekten sollte dies der Standard sein, und das Nuget-Paket sollte zusammen mit zukünftigen Versionen des Windows SDK installiert werden.

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Komponenten mit WinUI 3?

Wie bei der automatischen Aktualisierungsantwort sollten neue Seiten und Projekte diese standardmäßig enthalten und eine Nachricht mit der Frage, ob sie automatisch zu WinUI wechseln möchten | ToDo-Kommentare hinzufügen, um Namespace- s Wechseln Sie nicht zu WinUI .

Für welche Art von Apps würden Sie WinUI 3.0 am liebsten verwenden?

Als Benutzer möchte ich, dass alle unter Windows ausgeführten Apps eine gemeinsame Benutzeroberfläche und UX haben, unabhängig davon, welches Framework verwendet wurde.

Ich möchte, dass Apps installiert werden, ohne die Registrierung zu stören und Müll zu hinterlassen. (also Hundertjahrfeier)

Ich möchte, dass alle Apps aus dem Store oder von einem Centennial-Installationsprogramm installiert werden können. Virtualisieren Sie die System- und Windows-Ordner für jede App.

Modernisierung einer C++-MFC-App mit Fluent UI?

Acrylic sollte für WPF-, WinForms- und MFC-Apps verfügbar und in neuen Standardvorlagen über eine WinUI 3.0-Abhängigkeit oder ein Manifest enthalten sein. CommonControls und Fensterstile sollten Acryl und erweiterte Titelleisten verwenden (die überschrieben werden können, um zu den aktuellen Standardeinstellungen zurückzukehren).

Microsofts Win32-Nicht-UWP-Apps müssen alle mit WinUI 3.0 neu kompiliert werden, damit sie alle Acrylfensterrahmen, Hauptmenüs, ThemeShadows, Kontextmenüs , Textfelder, Fortschrittsbalken usw. verwenden.

Und dann benötigen vorhandene Apps eine einfache Lösung, um WinUI 3.0+ hinzuzufügen, die dann das Aussehen aller Steuerelemente aktualisiert - oder die Möglichkeit, sie selektiv jeweils in einem Dialogfeld anzuwenden, bis die gesamte Benutzeroberfläche aktualisiert ist.

Re: Namespaces, ich würde erwarten, dass sie sich nur basierend auf dem Ziel ändern, auch wenn bedingte Namespaces erforderlich sind.

Hier meine Antworten:

Erstellen einer neuen App

Welche Vorlagen würden Sie am meisten interessieren?

• Ich würde gerne c++/winRT win32+xaml und .net core+xaml zuerst dort sehen, UWP-Vorlagen an zweiter Stelle, verpackte Win32-App sollte nicht als Vorlage kommen, da aktuelle App-Paketvorlagen einfach so funktionieren sollten, wie sie es bereits mit aktuellen tun win32/.Net-Apps.
• Darüber hinaus würde ich gerne Elementvorlagen wie "Neues XAML-Fenster" mit Boiler-Plate-Code sehen, um sie in einer vorhandenen Win32- oder .net-Core-App-Anwendung anzuzeigen (z neues Xaml-Fenster der obersten Ebene)

Hinzufügen von WinUI 3.0 zu bestehenden Win32-Apps

• Nicht-Abwärtskompatibilität ist der genaue Grund, warum ich Xaml-Inseln nie in einem echten Projekt verwendet habe (allerdings zum Spaß für persönliche Dinge). Die Entkopplung des UI-Frameworks von der Windows-API ist eine der größten Neuerungen, die mit der WinUI 3.0-Roadmap angekündigt wurden (neben der Möglichkeit für nicht gepackte/nicht Uwp-Targeting-Apps, sie zu nutzen).

Aktualisieren Ihrer vorhandenen UWP-Xaml-App auf WinUI 3.0

Es mag hart klingen, aber ich habe das Gefühl, dass die UWP-Xaml-App eine Nische ist (seit dem Wegfall von Windows Phone gibt es keine Zugkraft mehr in Richtung UWP als Zielplattform), und selbst wenn Tooling / Interop wünschenswert wäre, tue ich es nicht Ich denke nicht, dass dies der Hauptfokus für WinUI 3.0 sein sollte.
Sowohl die Namespace-Update-Tools (die tatsächlich mit einem globalen Suchen und Ersetzen durchgeführt werden könnten) als auch das Mischen von UWP-xaml und WinUI-xaml erscheinen mir nicht kritisch.

Außerdem möchte ich nur erwähnen, dass dies ein sehr willkommener Schritt ist und dass es großartig ist, das gesamte UI-Framework als Open Source auf Github zu haben! Vielen Dank dafür!

Das ist zunächst einmal ein toller Schritt! Leider kann ich nicht vernachlässigen, dass ich mich durch den Umgang von Microsoft mit den wenigen letzten Entwicklern auf ihrer Plattform etwas verletzt fühle. Im Moment verwende ich UWP nur für verbraucherorientierte Apps, weil:

1. WPF ist viel ausgereifter als WinUI (Validierung, vorhandene Steuerelemente usw.), daher ist WPF für Unternehmen besser geeignet
2. UWP eignet sich hervorragend für mehrere Gerätekategorien (Mobilgerät, Tablet, Desktop usw.), hier sind die Verbraucher unterwegs

Es ist toll zu sehen, dass Punkt 1 mit WinUI in Angriff genommen werden konnte, was mich von den Fortschritten für WinUI begeistert. Leider ist 2 nicht mehr anwendbar (keine coolen Geräte mehr, nur Desktops). Da fragt man sich, was Entwickler zum Zeitpunkt der Auslieferung (frühestens 1 Jahr?) brauchen würden.

Ich denke, der Konsumkram ist nicht mehr Teil der Gleichung, dass das Schiff mit der Kürzungs-"Strategie" gesegelt ist. Das einzige, wofür es gut sein könnte, sind Unternehmensanwendungen.

Im Allgemeinen wäre ich mehr an einer guten Migrationsstrategie von WPF zu WinUI interessiert, um zu versuchen, unsere massive WPF-Codebasis auf Windows 10 zu migrieren. Der Nachteil der Aktualisierung von verbraucherorientierten Apps (derzeit UWP) besteht darin, dass sie stark abhängig sind auf externe Komponentenentwickler (zB Win Toolkit, etc). Ich denke, es gibt keine praktikable Option mehr, diese zu aktualisieren, da die meisten Entwickler (die mir bekannt sind) das Interesse an der Entwicklung von Consumer- / Windows-Clients verloren haben.

Antworten auf die Fragen

Erstellen einer neuen App

Welche Vorlagen würden Sie am meisten interessieren?

Ich würde gerne .net core / xaml / C# hier sehen, da dies meiner Meinung nach die am häufigsten verwendete Sprachkombination ist. Aber vielleicht wäre hier eine Migrationsvorlage besser (versuchen Sie, alle so schnell wie möglich an Bord zu holen, je länger es dauert, desto schmerzhafter wird es).

Hinzufügen von WinUI 3.0 zu bestehenden Win32-Apps

Ich denke, das ist sehr schön und wir würden es oft verwenden (aber realistischerweise ist dies mindestens ein Jahr entfernt, da Unternehmenskunden immer noch Windows 7 verwenden, selbst wenn der MS-Support endet, werden Unternehmen Windows 7 verwenden). Dann können wir WPF langsam auf WinUI 3 migrieren.

Kennen Sie Xaml Islands für die Modernisierung von Desktop-Apps?

Ja, aber zu viele Kunden verwenden (oder waren) Windows 7, daher war dies keine Option für Unternehmensentwickler. Und für Verbraucher könnte man sowieso einfach UWP verwenden.

Macht diese erweiterte Abwärtskompatibilität unter Windows 10 Xaml Islands für Sie nützlicher?

Es ist ein guter Anfang, denn zum Zeitpunkt der Auslieferung dieses Materials würde es auf allen unterstützten Versionen von Windows 10 im Unternehmen funktionieren.

Aktualisieren Ihrer vorhandenen UWP-Xaml-App auf WinUI 3.0

Verbraucher-Apps für MS sind vorbei, alles wegen der Entscheidungen, die MS getroffen hat, dafür gibt es keinen Platz mehr. Ich würde diese ganze Option einfach überspringen und vergessen. Es ist traurig, weil ich Tausende von Stunden in UWP-Apps gesteckt habe, aber ich denke, wir müssen diesen Tod schnell machen, um ihn weniger schmerzhaft zu machen.

Die ganze versprochene Geschichte war immer aktuell, alle Geräte unterstützen. Ich denke, wir alle wissen, in welche Richtung dieses Versprechen ging.

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Wenn es sich nur um Namensräume handelt, sollte auch ein Suchen / Ersetzen den Zweck erfüllen.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Nicht mehr wichtig, ich bin bereit, den Verlust von Tausenden von Entwicklungsstunden in Kauf zu nehmen, es gibt sowieso keine Benutzer mehr.

Erstellen oder verwenden Sie UWP-Xaml-Steuerelementbibliotheken oder WinRT-Komponenten, die Sie nicht einfach zusammen mit App-Code neu kompilieren und aktualisieren können?

Nö.

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Komponenten mit WinUI 3?

UWP-Inseln (eine Art gehosteter Komponenten)

Allgemein

Was halten Sie von dem oben und in der Roadmap skizzierten Gesamtplan 3.0? Würde es Ihnen ermöglichen, WinUI für Ihre neuen und vorhandenen Windows-Apps zu verwenden?

Es muss wahrscheinlich etwas gereift sein, aber ich sehe mich dieses Zeug in 1 - 2 Jahren für die Unternehmensentwicklung verwenden. Je nachdem, wie schwierig die Migration ist, wählen wir entweder WinUI oder Web (je nachdem, wie sich Windows selbst "entwickelt").

Für welche Art von Apps würden Sie WinUI 3.0 am liebsten verwenden? Erstellen einer neuen Win32-App und Verpacken mit MSIX? Hinzufügen neuer Ansichten zu einer WPF-App? Modernisierung einer C++-MFC-App mit Fluent UI?

Wahrscheinlich einfach nur neue Ansichten zu einer WPF-App hinzufügen und langsam mit der Migration beginnen.

Diese Roadmap gefällt mir sehr gut. UWP muss von seinen Fesseln befreit werden, und dies ist eine großartige Möglichkeit, genau das zu tun.

Aktualisieren Ihrer vorhandenen UWP-Xaml-App auf WinUI 3.0

Das ist für meinen Arbeitgeber sehr wichtig. Wir haben eine komplexe UWP-Desktop-App im Store. Wir benötigen jetzt Desktop Bridge, um Zugriff auf Win32-APIs zu erhalten, die von .NET Native nicht unterstützt werden.

Ich würde gerne

• direkter Zugriff auf alle win32-APIs;
• mit einem einfachen alten Win32-Ausführungsmodell. Ich bin gut mit einigen Desktop Bridge-ähnlichen Sandboxing (zB Virtualisierung der Registrierung);
• unsere App so in den Store (msix) zu stellen, wie sie jetzt ist;
• weiterhin WNS verwenden (Push-Benachrichtigungen);
• ein problemloses Update-Erlebnis von UWP auf einen neuen Xaml-Desktop-App-Typ. Es macht mir nichts aus, etwas Handarbeit zu tun. Vielleicht bevorzuge ich hier eine gute Dokumentation gegenüber Werkzeugen.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Bestehende Stile sollten weiterhin funktionieren. Mit kleinen optischen Veränderungen kann ich leben. Aber nicht mit Verhaltensänderungen.

Erstellen oder verwenden Sie UWP-Xaml-Steuerelementbibliotheken oder WinRT-Komponenten, die Sie nicht einfach zusammen mit App-Code neu kompilieren und aktualisieren können?

Nein.

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Komponenten mit WinUI 3?

Wenn sie nicht neu kompiliert werden können (Drittanbieter): Xaml Islands-ähnlicher Ansatz. Ansonsten sollte eine Portierung auf WinUI 3 problemlos möglich sein.

Allgemein

Für welche Art von Apps würden Sie WinUI 3.0 am liebsten verwenden? Erstellen einer neuen Win32-App und Verpacken mit MSIX? Hinzufügen neuer Ansichten zu einer WPF-App? Modernisierung einer C++-MFC-App mit Fluent UI?

• Desktop-Win32-Apps, verpackt mit MSIX.
• Uno plattformübergreifende Apps ;)

Bitte führen Sie keine neuen Namespaces für Dinge wie _INotifyDataErrorInfo_ ein - sie sollten in Ansichtsmodellen verwendet werden, die normalerweise plattformübergreifend sind und nicht von WinUI abhängig sein sollten. Es sollte definiert werden, wo sich andere Dinge wie diese befinden (dh _INotifyPropertyChanged_ oder _INotifyCollectionChanged)_

Ich würde nur gerne wissen, ob das ultimative Ziel darin besteht, einen plattformübergreifenden UI-Stack zu erstellen. Es zu verstehen, ist möglicherweise nicht vollständig verstanden, wie wir dorthin gelangen. Wenn dies jedoch die Absicht ist, wäre es besser, dies zu Beginn dieser Bemühungen ohne die Win- Referenzen zu brandmarken. Es wird auf lange Sicht weniger Kopfschmerzen geben, wenn Sie dies tun.

Wäre es besser, als XamlUI oder ähnlich zu bezeichnen? Die Microsoft.UI.*-Namespaces sind in Ordnung, branden Sie einfach das Repository und z. B.

Danke, dass Sie sich gemeldet haben. Seien Sie gespannt, was in diesem Raum kommen wird :smile:

Für mich sind alle technischen Details weniger wichtig.
UWP, WPF oder ein beliebiges Windows-only-Framework, so großartig es auch sein mag, wird nicht ausreichen, solange es nicht auf jeder Plattform läuft (zumindest Windows, Droid, iOS und Web) und freundlich mit jede Bildschirmgröße.

TBH war beim letzten Build enttäuscht, als ich feststellte, dass MS keine Pläne hat, UWP oder XAML plattformübergreifend zu machen. Uno erhielt außer einer Rede keine offizielle Anerkennung. Noch frustrierender, ich würde sagen verletzend, war zu entdecken, dass MS React Native und HTML/JS-gesteuerte Frameworks WIEDER (WinJS) so viel Liebe schenkt, während die verantwortlichen .NET-Stack-Entwickler vernachlässigt werden.
Ich würde mir wünschen, dass MS offiziell einen plattformübergreifenden UI-Stack wie Uno erstellt und die richtigen Tools, Vorlagen und integrierten Support bereitstellt.

Übrigens, ich arbeite seit der Übernahme durch MS mit XF und wünsche mir aus folgenden Gründen eine Alternative: a. Keine Webunterstützung, b. Sehr mobil voreingenommen, keine Vorliebe für Desktops c. Seine Bibliothekshierarchie fühlt sich schlampig an, definitiv im Vergleich zur WPF/UWP-Kontrollbibliothek d. Verwendet kein MS XAML.
Hier ist die Funktionsanfrage, die ich in der Microsoft Developer Community gepostet habe: .NET UI Standard .

Danke euch allen!

Wir benötigen eine XAML-Benutzeroberfläche, die auch im Web (Assembly) ausgeführt wird. Zumindest eine Teilmenge von UWP.
Warum nicht die UNO-Plattform nutzen und das Web-Rendering mit SkiaSharp erstellen?
Könnte Silverlight 6 sein , das Web-Pendant von WinUI

Schnelle Antworten auf die Fragen

Welche Vorlagen würden Sie am meisten interessieren?

.NET-Core-SDK-Projekte oder ein vereinfachtes MSVC-Projektformat.
Die alten Projektdateien sind zu kompliziert, um sie manuell zu bearbeiten, und es gibt unzählige Interaktionsprobleme zwischen dem alten und dem neuen Projektsystem. Wir sollten das alte Projektsystem für brandneue Projekte komplett fallen lassen.

Kennen Sie Xaml Islands für die Modernisierung von Desktop-Apps?

Nein. Ich schreibe meine Anwendung mit einer vollständigen Änderung des Datenmodells um, sodass keine schrittweise Migration stattfindet.

Macht diese erweiterte Abwärtskompatibilität unter Windows 10 Xaml Islands für Sie nützlicher?

Es gibt immer noch viele Benutzer auf Windows 7 und Xaml Islands können nicht helfen.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Nein. Alle meine Komponenten sind selbst geschrieben oder von MUX und WCTK, sodass ich eine schnelle manuelle Migration durchführen kann.

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Nein, denn mein Projekt ist nicht groß (~20 Seiten und ~10 benutzerdefinierte Steuerelemente für den Moment).

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Komponenten mit WinUI 3?

Ich möchte, dass es eine Version gibt, die mit dem Betriebssystem geliefert wird , um die Erstellung sehr kleiner Tools und den

Für welche Art von Apps würden Sie WinUI 3.0 am liebsten verwenden? Erstellen einer neuen Win32-App und Verpacken mit MSIX? Hinzufügen neuer Ansichten zu einer WPF-App? Modernisierung einer C++-MFC-App mit Fluent UI?

Erstellen einer neuen Nur-Windows 10-App und Versand ohne Store.
Vertrauenswürdige Signaturen sind für einzelne Entwickler teuer, und das Hochladen in den Store ist nicht für domänenspezifische, nicht für langfristige Anwendungen geeignet.

Mein persönlicher Look für die UI-Plattform

Xaml-Toolchain

Die xaml-Sprache ist irgendwie nicht ernst gemeint und ich stehe vor vielen Problemen wie "wie soll ich das darstellen". WPF xaml und UWP xaml sind nicht vollständig kompatibel, daher muss ich mir ihre Unterschiede merken. Xaml ist nicht vollständig mit .NET-Features kompatibel, daher muss ich manchmal einige hässliche Tricks in mein Modell und eine Hilfsklasse schreiben.

Mit x:Bind wird es noch schlimmer. Die einfachen Szenarien sind einfach zu verwenden, aber es ist sehr kompliziert, Dinge zu tun, die mehr sind als ein Eigenschaftszugriff. Beispielsweise wird das Überladen von Methoden nicht unterstützt, daher muss ich kompilieren, um zu überprüfen, welche Überladung für diesen Bindungsausdruck ausgewählt wird. Ich kann nicht einmal einen einfachen Schalter oder eine "sichtbar, wenn eine Eigenschaft falsch ist"-Konvertierung durchführen, und eine Hilfsmethode ist erforderlich. Die Dokumentation sagt nichts über diese detaillierten Szenarien aus, daher denke ich, dass es einen Platz für Diskussionen über das xaml-Sprachdesign geben und xaml zu einer ernsthaft entworfenen Sprache wie C# machen sollte.

Der xaml-Editor ist auch schwer zu verwenden. Es ist sinnvoll, dass der Designer versucht, Code auszuführen, um die tatsächlichen Effekte anzuzeigen, aber der Texteditor sollte nur die Metadaten berücksichtigen. Das Öffnen einer xaml-Datei in der Quellansicht ist langsam, da der Designer aktiviert wird und einige Interaktionsausnahmen für ein absolut einwandfreies xaml ausgelöst werden, z. B. NullReferenceException und Cannot convert __ComObject to some type . Es berührt ProjectReference durch erstellte Bibliotheken und führt zu komplizierten Fehlern, selbst wenn eine einfache Bearbeitung des nicht öffentlichen API-Bereichs in der Abhängigkeitsbibliothek erfolgt, normalerweise die Implementierung des Datenmodells. Daher denke ich, dass es einen Metadaten- und Quellcode-bewussten, vollständig in Roslyn integrierten Xaml-Compiler geben sollte.

Ein besseres Fenstermodell

Für informations- und zustandsreiche Anwendungen ist es üblich, ein Multi-Window-Modell anstelle des Navigationsmodells zu verwenden. Derzeit ist in UWP das Erstellen eines neuen Fensters mit ApplicationView mühsam, da Threading-Probleme auftreten. Das neue AppWindow teilt sich den UI-Thread, und ich bin mir bezüglich seiner UI-Leistung nicht sicher.

Das Umschreiben von Visual Studio in WinUI zu einem späteren Zeitpunkt kann beweisen, dass es sich um ein ausgereiftes UI-System handelt.

Datenbindungsschnittstellen

Wir sind es leid, Modelle zu erstellen, die INotifyPropertyChanged implementieren. Ich habe eine benutzerdefinierte MSBuild-Aufgabe geschrieben, um eine XML in erweiterte Eigenschafts-Accessoren zu konvertieren, aber es hilft nicht, wenn ich im Setter etwas benutzerdefiniertes tun möchte, wenn sich die Eigenschaft ändert.

Und es gibt Threading-Probleme. Meine Daten stammen vollständig von einem Hintergrundnetzwerkserver, daher kann mir die Kontexterfassung für await nicht helfen. In WPF und Binding ist es so, wie es ist, weil Binding das Threading selbst löst. Wenn ich zu x:Bind wechsele, muss ich es im Event Raiser lösen, weil x:Bind nur den aufrufenden Thread bearbeitet. Die Dinge werden noch schlimmer, wenn ich mehrere Anwendungsansichten habe, die dieselben Daten berühren, was bedeutet, dass kein globaler UI-Dispatcher verfügbar ist und die einzige Lösung darin besteht, SynchronizationContext.Current bei der Ereignisregistrierung zu erfassen. Für Sammlungen ist ItemsSource nicht threadsicher, und dieselbe Problemumgehung ist erforderlich.

Es sollte definitiv eine Toolchain geben, um die Modellierungs-, Threading- und Erweiterungsprobleme für veränderliche bindbare Modelle zu lösen. Und eine generische integrierte Lösung für bindbare Sammlungen sollte einen Mechanismus für "angegebene Eigenschaften eines geänderten Kindes" bereitstellen.

IObservableVector<T> ist ein gefälschter generischer Typ, der nur object , INotifyCollectionChanged ist nicht generisch. Implementieren Sie es einfach für eine integrierte Sammlung wie ObservableCollection<T> ist nicht genug, besonders für komplizierte, ISupportIncrementalLoading / IItemsRangeInfo orientierte Szenarien. Die Plattform sollte eine abstrakte Standardimplementierung mit Best Practices bereitstellen, die es dem Benutzer ermöglicht, einfach eine abstrakte Datenfüllmethode zu implementieren.

@shaggygi @weitzhandler @TonyHenrique

Wenn es eine plattformübergreifende Zukunft für UWP/XamlUI3.0 geben soll, wäre die Abstraktion der XAML-Syntax vom Windows-Renderer und dem Rest der Windows-Runtime eine Möglichkeit, damit umzugehen.

Wenn das Projekt eine fast Plug-in-Mentalität aufweisen könnte, könnte es einen Android- oder iOS/AppKit-Renderer und einen Android/iOS-AppKit-Shim geben, um ART-APIs in C# und VB sowie in die vorhandene C++- und C-Sprache zu übergeben Unterstützung.
Xamarin könnte hier helfen.

Microsoft muss nicht diejenigen sein, die an diesen alternativen Plattform-Renderern arbeiten.

Aber vorerst auf Windows konzentrieren ... WinUI 3.0 könnte Fabric Web / React Native / WPF / WinForms / MFC umfassen. PWAs werden auch ein erstklassiger Bürger für die App-Entwicklung sein, sodass es plattformübergreifende Geschichten für Apps gibt, die nicht direkt für Windows/.NET/UWP entwickelt wurden.

Was jetzt benötigt wird, ist eine Story für C#/.NET/UWP-Entwickler bereitzustellen, um ihre Apps und Investitionen in die breitere Plattformlandschaft einzubringen.

Meine 2 Cent: Ich bin ein Xamarin.Forms-Entwickler und (wie viele andere) daran interessiert, dass alle XAML-Dialekte zu einem zusammengeführt werden, der überall funktioniert, einschließlich des mobilen Bereichs. Ich bin mir nicht sicher, wie das ausgehen würde, aber das ist zumindest mein Wunsch in dieser Angelegenheit.

Vielleicht ab WinUI 3.0 – aber es gibt zu viele WPF-Apps, um zu erwarten, dass sie alle das gesamte XAML neu schreiben und übersetzen. Neue WPF-Projekte könnten den moderneren WinRT-XAML-Dialekt verwenden. Sie könnten das Äquivalent eines DocType in XAML einführen, damit verschiedene Dialekte im selben Projekt gleichzeitig existieren können.

Natürlich leichter gesagt als getan.

@mdtauk Ich denke, dass wir, sobald die Xaml-Plattform tatsächlich Open Source ist, ein klareres Verständnis davon haben werden, worauf sie sich am unteren Ende des Stapels stützt (wir wissen bereits, dass die wichtigsten plattformspezifischen Abhängigkeiten DirectX11, Direct2D und Windows sind.) Media Foundation, aber wer weiß, welcher Teil des Windows SDK dort verwendet wird) und wie es geschichtet ist (damit wir ein tatsächliches Gefühl für die Machbarkeit einer Portierung bekommen).
Außerdem müssen wir noch sehen, unter welcher Lizenz der Quellcode verbreitet wird. Ich bin mir nicht sicher, ob es noch entschieden ist.

Android verwendet Vulkan und unterstützt meiner Meinung nach OpenGL
iOS und macOS verwenden Metal

Was die Mediencodecs angeht, ist es möglicherweise möglich, native C-basierte APIs zu verwenden, um sie zu ersetzen.

@simonferquel Es wird klarer, wenn der Code umgestaltet und eingecheckt wird. Und es kann erforderlich sein, dass einige iOS- und Android-Experten diese Bemühungen leiten.

Ich denke, das Ändern des Namespace war ein vernünftiger Ansatz, als Winui eine Sammlung von Steuerelementen war. Aber jetzt, da es die Plattform im Grunde ersetzt, denke ich, dass dies nicht mehr gerechtfertigt ist. Dies funktioniert bereits in gleicher Weise für WPF/Winforms, wo Code von .net Framework in .net Core verschoben werden kann, ohne die Namespaces im Code zu ändern. Die Plattform sollte bei Aktivierung automatisch in der Lage sein, die Winui-Versionen der erforderlichen DLLs zu laden. Auf diese Weise kann die Quell- und Binärkompatibilität (ich habe erfolgreich .net-Framework-Bibliotheken in .net-Core-Apps verwendet) erhalten bleiben.

Ich wollte mich nur bei allen für die bisherigen Kommentare bedanken! Das WinUI-Team prüft alle Antworten und Punkte sorgfältig.
Wir werden wahrscheinlich auch einige fokussierte Themen abspalten, um über spezifische Punkte zu sprechen, die aufgekommen sind (zB Kompatibilität mit bestehenden UWP-Frameworks und -Komponenten), sobald wir unsere Gedanken geordnet haben.

Ich möchte MS nur dafür danken, dass sie mehr zugehört und den .net-Entwicklern großartige Tools zur Verfügung gestellt haben, aber ich kann nicht anders, als von der Zukunft von UWP Xaml nach der Build-Konferenz enttäuscht zu sein.
Wenn man diesen Blog und viele Artikel im Netz liest, hat man das Gefühl, dass UWP ausschließlich zu „Unternehmen“ wird, und selbst das ist umstritten, da viele Unternehmen immer betriebssystemunabhängiger werden und ihren Mitarbeitern erlauben, beispielsweise MacBook Pros zu verwenden.

Lassen Sie mich klarstellen, dass ich stark in natives UWP und Xamarin Forms (Android, iOS) investiert habe und die Plattform liebe, aber nachdem MS die native Unterstützung für React angekündigt hat, bin ich kurz davor, das Schiff zu verlassen.

Ich weiß, dass ich meine UWP-App auf dem Desktop plattformunabhängiger machen muss, deshalb hatte ich gehofft, dass ich mit meiner aktuellen UWP-App als Shell eine „Hybrid-App“ erstellen und immer mehr Web-Frontend-Technologien integrieren kann, indem ich React im Mix verwende . So etwas wie die vorgeschlagene "Sets" -Funktion, von der ich weiß, dass sie sich aufgrund höherer Prioritäten in Edge verzögert, wäre für meine aktuelle Lösung ideal gewesen, da sie die Grenzen zwischen nativer UWP und Webtechnologien völlig verwischt, indem sie sowohl native als auch Webtechnologie in „Fenster/Rand-Tabs“. Dieser „hybride“ Ansatz wird es mir ermöglichen, die Webtechnologie langsam in meine aktuelle Plattform zu integrieren, gibt aber auch „nativen Apps“ sozusagen eine Registerkarte im „Browser“. (aus Verbrauchersicht) Das bietet mir auch einen Ausweg, wenn „native Uwp-Apps“ auf dem Desktop langfristig ausfallen.

Der Grund für das obige Denken ist, dass UWP mir keine Fluchtluke bietet, da es leicht zum nächsten Silverlight-Opfer werden kann, wenn es bald keine plattformübergreifende Fähigkeit gibt. MS sichert ihre Wetten ab, indem sie sicherstellen, dass sie den PWA-Trend nicht verlieren oder ihre Hand dafür gedreht wird, um die native Unterstützung von React unter Windows zu erhalten. Das Problem ist, dass ich gewettet habe, in der Hoffnung, dass es bis zu diesem Zeitpunkt einen „Pfad“ für UWP/c#/.net in den Browser oder die Cross-Plattform geben wird und dass ich den größten Teil meiner Investitionen in diese Plattformen wiederverwenden kann.

Ich erinnere mich, als jeder Entwickler da draußen rief, Xamarin zu kaufen, hat MS ewig dafür gebraucht. Ich denke, die meisten Entwickler, die mit Webassembly vertraut sind, wissen, dass sie es kürzlich geschafft haben, eine „Vollversion“ von Windows Server in der Webassembly auszuführen, werden sagen, dass sie die Uno-Plattform kaufen und sie mit erheblichen Investitionen riesig machen. Wenn ein vollständiges Betriebssystem auf Web-Assembly laufen kann, sollte MS jedem .net-Entwickler einen Migrationspfad zur plattformübergreifenden Fähigkeit bieten, um seine bestehenden Investitionen zu schützen.

Sie könnten sagen, dass Blazor da ist, aber ehrlich gesagt, bevor ich mehr Zeit in eine neue Plattform investiere, werde ich eher React lernen, oder Sie könnten sagen, dass wir MS nur begrenzte Ressourcen für all das haben. Wenn Sie 7,5 Milliarden US-Dollar für Github bezahlen, wird alles sicherlich relativ.

Ich denke, es ist wichtig, dass MS den Reputationsschaden versteht, der durch einen fehlgeschlagenen Migrationspfad zur Cross-Plattform-Fähigkeit für bestehende UWP/Win32-Investitionen entsteht. Cross-Plattform-Fähigkeit sollte gleichbedeutend mit .NET 5 sein und ist es nicht. Ich bin mir nicht sicher, ob in diesem Fall kleine Schritte zur Cross-Plattform für MS funktionieren werden und glauben Sie mir, ich war schon immer ein großer Fan von xaml/.net/c#

Welche Vorlagen würden Sie am meisten interessieren?

Meinst du auch Projektvorlagen oder Artikelvorlagen?

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Wäre dies nur ein Suchen und Ersetzen (weniger Wert) oder auch Aktualisierungsabhängigkeiten auf eine neue Version (wertvoller, aber nicht sicher, wie Sie das erkennen können)

Betreff: Abwärtskompatibilität für neue Funktionen

Wird die Abwärtskompatibilität zu Creators Update (15063) ein fester Bezugspunkt sein oder wird der Plan in Zukunft darin bestehen, die aktuelle Version und die X-Anzahl der Versionen davor zu unterstützen?

Was bedeutet dies für jeden, der eine Erweiterung oder ein eigenes Steuerelement oder eine Funktion erstellt, die er öffentlich freigeben möchte? Müssen sie diese Abwärtskompatibilität auch unterstützen? Auch auf Windows 8.1?

Betreff: Namespaces migrieren

Wird es möglich sein, eine bestehende UWP schrittweise zu migrieren (ich denke an Seiten) oder muss die gesamte App auf einmal aktualisiert werden? Wenn es die gesamte App auf einmal ist, wird die Akzeptanz verlangsamt.

Was ist mit der Migration von WPF-Apps? - Besteht die Migrationsstrategie auf XAML Islands, die WinUI 2.x oder 3.x verwenden könnten? Könnten beide in derselben App verwendet werden?

Ja, die Aufteilung dieses Themas in mehrere, fokussiertere Themen hilft dabei, Ideen klarer zu erfassen und Tangenten zu vermeiden.

Bitte ersetzen Sie alle Instanzen von UWP durch die entsprechenden Namen, da nicht klar ist, worauf Sie sich beziehen.

@mrlacey :

Meinst du auch Projektvorlagen oder Artikelvorlagen?

Element- oder Bibliotheksvorlagen sind auch interessant! Es gibt einige großartige Punkte in den bisherigen Antworten über die Bereitstellung zusätzlicher Boilerplate- und Starter-Codes, die wir im Laufe der Zeit hinzufügen könnten, vielleicht wie das Windows Template Studio .

Wäre dies nur ein Suchen und Ersetzen (weniger Wert) oder auch Aktualisierungsabhängigkeiten auf eine neue Version (wertvoller, aber nicht sicher, wie Sie das erkennen können)

Gute Frage – welche Art von Abhängigkeitsaktualisierungen würden es wertvoller machen? zB neue kompatible NuGet-Paketversionen finden?

Wird die Abwärtskompatibilität zu Creators Update (15063) ein fester Bezugspunkt sein oder wird der Plan in Zukunft darin bestehen, die aktuelle Version und die X-Anzahl der Versionen davor zu unterstützen?

Wir gehen davon aus, dass sich der Support-Versionsbereich im Laufe der Zeit je nach Nutzung ändert. Anstatt auf eine bestimmte Anzahl von Versionen beschränkt zu sein, werden wir uns wahrscheinlich weiterhin die Nutzungsdaten ansehen und die aktivsten auf dem Markt befindlichen Windows 10-Versionen unterstützen.

Was bedeutet dies für jeden, der eine Erweiterung oder ein eigenes Steuerelement oder eine Funktion erstellt, die er öffentlich freigeben möchte? Müssen sie diese Abwärtskompatibilität auch unterstützen? Auch auf Windows 8.1?

Wir sehen derzeit keine zusätzlichen Anforderungen oder "Zertifizierungen" für benutzerdefinierte Kontrollen vor. Die Versionierung wäre Ihnen überlassen. Die allgemeine Versionsgeschichte über das Update vom Mai 2019, WinUI 3.0 und zukünftige Versionen von WinUI ist definitiv ein Thema, auf das wir bald näher eingehen möchten.

Wird es möglich sein, eine bestehende UWP schrittweise zu migrieren (ich denke an Seiten) oder muss die gesamte App auf einmal aktualisiert werden? Wenn es die gesamte App auf einmal ist, wird die Akzeptanz verlangsamt.

Tolle Frage - danke für den Hinweis. Auch dieses Thema wollen wir demnächst vertiefen.

Bitte ersetzen Sie alle Instanzen von UWP durch die entsprechenden Namen, da nicht klar ist, worauf Sie sich beziehen.

@riverar :

Wir verwenden den Begriff " UWP Xaml ", um auf die Xaml-Plattform zu verweisen, die als Teil von Windows 10 und dem UWP SDK ausgeliefert wird, um sie von anderen Xaml-basierten Plattformen (zB WPF) zu unterscheiden.

Im Unterschied zu einem Win32-App-Modell beziehen wir uns auch auf das „ UWP-App-Modell “ (Paketierung und Installation, Daten- und Zustandsverwaltung, Laufzeitlebenszyklus usw.).

Selbst auf Windows-Desktops verbringen Benutzer viel Zeit damit, im Internet zu surfen.
Ich denke, wir brauchen einen Weg, um anständige Web-Apps zu entwickeln, indem wir die (Teilmenge der) UWP vNext XAML + .NET (C#/F#/VB.NET) verwenden.

Ich habe viele Jahre in WPF + ClickOnce entwickelt und dann angefangen, mich mit UWP zu beschäftigen. Ich mag UWP, aber es (oder die nächste Version) muss in der Lage sein, eigenständige EXE auszuführen, bessere Fenster-APIs (ermöglichen die Erstellung einer sogar benutzerdefinierten Winamp-Fenster-App, wenn wir WOLLTEN), mehr Druck-APIs, einfaches Interop mit C-dll , OCX, sollte zumindest eine Teilmenge der Komponenten im Web ausgeführt werden.

Als ich UNO sah, dachte ich: Microsoft könnte diese Firma kaufen und sich diesen Entwicklern mit den Teams von UWP und Xamarin anschließen. Ich würde mich freuen, wenn die nächste Version von UWP ein Azure-Ding wird, das auf Web, Windows, Mobile und IoT läuft. IMO könnte sogar das Azure-Portal in UWP vNext geschrieben werden.

Microsoft kann es tun. Sie haben es mit Silverlight gemacht, Sie haben WPF gemacht, Sie haben UWP gemacht, Sie haben Xamarin gemacht. Jetzt ist es Zeit für das ultimative GUI-XAML-Framework. Und meiner Meinung nach muss das Web unterstützt werden, zumindest eine Teilmenge der Funktionalität.

_INotifyDataErrorInfo_

Bitte führen Sie keine neuen Namespaces für Dinge wie _INotifyDataErrorInfo_ ein - sie sollten in Ansichtsmodellen verwendet werden, die normalerweise plattformübergreifend sind und nicht von WinUI abhängig sein sollten. Es sollte definiert werden, wo sich andere Dinge wie diese befinden (dh _INotifyPropertyChanged_ oder _INotifyCollectionChanged)_

Über dieses Thema. Windows.UI.Xaml.Interop verfügt bereits über eine INotifyCollectionChanged-Schnittstelle und Windows.UI.Xaml.Data verfügt über INotifyPropertyChanged. Diese beiden werden in Microsoft-Namespaces verschoben. Vielleicht können die System.Runtime.WindowsRuntime-Assemblys eine Zuordnung von WinUI zu .Net vornehmen

Meine einzige Sache, die ich hinzufügen möchte, wenn es nicht bereits hinzugefügt wurde, ist, dass ich das MSIX/Appx-Paketmodell zu 100% unterstütze und Win10 fantastische Arbeit geleistet hat, um den Scheiß zu reparieren, der während der Lebensdauer von Windows installiert und entfernt wurde. Ich hatte jedoch immer Schwierigkeiten, eine "UWP" -Anwendung zu erstellen, da die seltsame Teilmenge der verfügbaren API-Auswahlen in der AppContainer-Sandbox getroffen wurde. Als C++-Entwickler war das frustrierend und jedes Jahr war es eine Erleichterung zu sehen, wie Sie die Sandbox weiter öffnen, um den vollständigen Win32-API-Satz zuzulassen.

Wenn ich also mit WinUI 3.0 eine App mit Zugriff auf 100 % des Win32-Stack erstellen kann, ist dies Gold wert! Ich habe gerade versucht, XamlIslands zu verwenden, und es ist eine fantastische Fluchtluke, aber es war für mich instabil und es bleibt noch etwas zu tun, bevor es wirklich über die Ziellinie geht.

Wenn ich Projektvorlagen bekomme, mit denen ich eine Win32-App erstellen kann, ohne in einen AppContainer-Prozess gestopft zu werden, und auf alle Fortschritte zugreifen kann, die Sie mit der Benutzeroberfläche gemacht haben, dann passt WinUI 3 perfekt zu mir.

@eklipse2k8 Es muss immer noch ein Berechtigungssystem für den Zugriff auf die Dateien und Geräte eines Benutzers geben, selbst in einer entspannten Sandbox. Ich denke auch, dass es Regeln geben sollte, die man im Userland einhalten und die Erhöhung des Admin- und Kernal-Zugriffs vermeiden sollte - ohne irgendwelche offiziellen Test- und Code-Signing-Anforderungen.

Hallo Microsoft,

Ich weiß nicht, wie sehr dieser Beitrag das Thema Font Rendering , ClearType , DirectWrite und die Zukunft der Windows-Benutzeroberfläche beeinflussen wird, aber ich bin einer der kleinen, aber lautstarken und leidenschaftlichen Wenigen, die ernsthafte Beschwerden mit den Subsystemen für die Font-Rendering haben Fenster.

Es ist so ziemlich überall im Internet gut dokumentiert , wie frustriert (oder zufrieden) die lieben , und Sie werden andere finden, die es absolut hassen .

Ich bin nicht hier, um zu diskutieren, ob das eine besser ist als das andere. Ich bin auch nicht hier, um über Registry-Hacks, "Schrifttuner" zu diskutieren oder wie ich die Betriebssystemeinstellungen optimieren kann, damit Schriftarten besser erscheinen. Vertrauen Sie mir, ich habe alles getan; ging sogar so weit, einen Kernel-Modus-Treiber zu schreiben, um DirectWrite-Funktionen im Kernel-Modus zu patchen.

Ich bin hier, weil ich eine sehr häufige optische Erkrankung namens Myopie / Kurzsichtigkeit habe . Ich kann die Dinge aus der Nähe klar sehen. Aber nur auf Armesabstand ist meine Sicht genau am Rande meiner Sehschärfe und dort, wo der Text zu verschwimmen beginnt.

Außerhalb der Armdistanz muss ich Korrekturlinsen tragen. :Brillen: Ich bin sicher, dass wir alle wissen, dass Desktop-Computerbildschirme ungefähr in Armdistanz sind. Daher das Problem.

• Schriftarten, die glatt aussehen, sehen für mich verschwommen aus.
• Schriften mit scharfen Kanten (auf Pixel eingerastet) sehen für mich klarer aus.

Wenn Schriften an Pixeln ausgerichtet werden, sind die scharfen Kanten ein visuelles Signal für mein Gehirn, dass meine Sicht klar und scharf meine Sicht unscharf ist.

Als Entwicklerkollege, der lange Zeit damit verbringt, Code zu schreiben und Text anzuschauen, ist das frustrierend und tut höllisch weh. Dies ist der Hauptgrund, warum ich immer noch Windows 7 und nicht Windows 10 verwende . Fast die gesamte Metro-Benutzeroberfläche von Windows 10 verwendet überall die Schriftglättung.

Um dieses Problem der Schriftglättung zu veranschaulichen, sehen wir uns das services.msc MMC-Snap-In unter Windows 7 an :

Sehen Sie verschwommenen Text, der unscharf aussieht? Hier. Lass uns etwas näher heranzoomen...

Meine Güte, gnädig, es fühlt sich an, als würde ich Text in einem Autostereogramm schielen.

In diesem speziellen Fall stellt sich heraus, dass das MMC-Snap-In beim Durchsuchen der Steuerelementhierarchie dieses Fensters ein Internet Explorer-DHTML/ActiveX-Steuerelement hostet, das unscharfen Text im Feld "Element auswählen, um seine Beschreibung anzuzeigen" wiedergibt. Das scharfe (auf Pixel einrastende), "Hilfe"-Menü und die Liste der Dienste werden mit normalen USER32- und GDI32-Primitiven gerendert.

Dieses kleine Beispiel hebt eines der größten Probleme beim Rendering von Schriftarten in Windows hervor. Es stellt sich heraus, dass IE8 die globale Betriebssystemeinstellung respektiert, die ClearType und die Schriftglättung deaktiviert. Wenn Sie jedoch IE9 oder höher installieren, ignoriert IE9+ gerne alle Bemühungen, die Schriftglättung zu deaktivieren. IE9+ kümmert sich einfach nicht darum und zwingt alle Benutzer, Text auf Websites (und in ActiveX-Steuerelementen) mit geglättetem Text anzuzeigen.

Das Problem wird für Benutzer wie mich noch schlimmer, da im Laufe der Zeit die Geburt von Windows 8 und Windows 10, Metro Apps, WPF und UWP alle den gleichen Ansatz wie IE9+ verfolgt haben. Alle diese UI-Technologien unter der Haube ignorieren globale betriebssystemweite Einstellungen , die auf unseren Maschinen respektiert werden sollten. Wenn wir ClearType und Schriftglättung auf Betriebssystemebene deaktivieren, erwarten wir, dass ClearType- und DirectWrite-APIs (und folglich Metro-, WPF- und UWP-Apps) nicht mit Schriftglättung zeichnen.

Ich weiß, ich bin nicht der einzige mit diesem Problem.

Vor einiger Zeit hat Google Chrome das gleiche mit seiner v31-Version gemacht und versucht, dem IE9+-Ansatz zu folgen und das gesamte Schriftart-Rendering auf Chromium-Ausgabe 319429 . Schließlich, nach langem Zähneknirschen, kehrte Google den Kurs um und korrigierte das Problem in Chrome 37 für Benutzer mit kurzsichtiger Sehbehinderung und respektiert nun die betriebssystemweite Einstellung, die die Schriftglättung deaktiviert.

Dank der Macht und der Marktkräfte hat Microsoft den Browserkrieg verloren und übernimmt jetzt die Chromium-Rendering-Engine, aber ich halte mit angehaltenem Atem fest, dass das Edge-Team die deaktivierten Einstellungen zum Glätten von Schriftarten respektieren wird.

Ich bin nur hier, um zu befürworten, dass Microsoft eine globale Einstellung benötigt, die für alle Apps auf dem Betriebssystem, für alle UI-Stacks und für diejenigen mit Sehschärfeproblemen respektiert werden muss.

Und als freundliche Erinnerung, dies ist ein Problem mit der Barrierefreiheit für die Windows-Benutzeroberfläche im Allgemeinen und kein visuelles

Auf der Grundlage der weltweiten Prävalenz von Kurzsichtigkeit kann geschätzt werden, dass über 22% der gegenwärtigen Weltbevölkerung, dh 1,5 Milliarden Menschen, kurzsichtig sind. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Vielen Dank,
Brian

:walking_man: :walking_woman: Vermisste Personen - Wandern in LA

Dies bedeutet, dass das vollständige Xaml-Framework auf GitHub entwickelt und als NuGet- Pakete out-of-band ausgeliefert wird.

NuGet ist großartig, aber die Unterstützung von vcpkg (und CMake ) wäre auch wünschenswert (für diejenigen von uns mit großen, vorhandenen plattformübergreifenden Bibliotheken).

Welche Vorlagen würden Sie am meisten interessieren?

In bevorzugter Reihenfolge:
Win32 + Xaml-Desktop + WinUI
Win32 + Xaml-Inseln + WinUI
UWP + WinUI

Kennen Sie Xaml Islands für die Modernisierung von Desktop-Apps?Macht diese erweiterte Abwärtskompatibilität unter Windows 10 Xaml Islands für Sie nützlicher?

Ja, Xaml Islands ist interessant, aber da wir uns an Verbraucher und nicht an Unternehmenskunden richten, ist die erweiterte Abwärtskompatibilität kein Dealbreaker - die meisten Kunden sind ziemlich glücklich, ihr Betriebssystem zu aktualisieren (und haben einen Zeitrahmen für die Implementierung von Änderungen basierend auf der neuen WinUI). Xaml, wenn es bis 1903 gesperrt wäre, würde es wahrscheinlich bedeuten, dass es schon ein Jahr draußen ist).

Der Stammnamespace für Xaml-, Kompositions- und Eingabe-APIs in WinUI unterscheidet sich vom Stammnamespace des Windows UWP SDK:

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Dies betrifft mich nicht, da wir keine UWP-App haben (derzeit verwenden wir WPF für den Direktverkauf und WPF + Desktop Bridge für den Store), aber das Ändern von Namespaces ist eine einmalige Sache und selbst in den größten Codebasen, ein globales Suchen und Ersetzen für Windows::UI::Xaml ist nicht so entmutigend (wir verwenden alle Versionskontrolle, richtig...?).

Der schnellste Weg zur Veröffentlichung von WinUI 3.0 wäre, das Mischen nicht zu unterstützen:

Das ist für mich in Ordnung, sie sollten als separate inkompatible Bibliotheken behandelt werden. Sie zielen entweder auf UWP Xaml oder WinUI Xaml ab. Wie oben erwähnt, sollte die einmalige Konvertierung nicht so schwierig sein.

Eines unserer größten Bedenken sind jedoch die Kompatibilitätsprobleme und die Arbeit, die für vorhandene UWP-Apps und Komponentenbibliotheken entstehen können, insbesondere wenn Sie UWP-Xaml-Steuerelementbibliotheken erstellen oder verwenden.
Beispielsweise könnten vorhandene Versionen des Windows Community Toolkit in WinUI 3.0-Apps nicht verwendet werden, sodass sowohl das Toolkit als auch alle Apps, die es verwenden, vor der Verwendung von WinUI 3.0 aktualisiert werden müssen.

Microsoft muss eine Technologie auswählen und dabei bleiben. Seit Jahren werden uns die neuesten und besten Desktop-UI-Frameworks (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml und jetzt WinUI Xaml) versprochen. Die Auswahl ist zwar groß, führt jedoch zu einer Fragmentierung der Funktionalität und des Entwicklerwissens. Es ist viel einfacher, eine Sitzung / eine Webseite / eine Stackoverflow-Antwort auf die Implementierung einer Funktion in Windows zu haben, im Vergleich zu 7 verschiedenen, je nach Technologie. Wenn WinUI Xaml die Zukunft ist, muss das Community Toolkit aktualisiert werden, um es nutzen zu können.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Ich habe mich mit UWP Xaml zurückgehalten, weil die Funktionalität einfach nicht da ist (im Vergleich zu Win32 / WPF), und ich gehe davon aus, dass ich in dieser Hinsicht nicht allein bin. Daher ist die vollständige Kompatibilität kein Problem.

Erstellen oder verwenden Sie UWP-Xaml-Steuerelementbibliotheken oder WinRT-Komponenten, die Sie nicht einfach zusammen mit App-Code neu kompilieren und aktualisieren können?

Nein.

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Xaml-Komponenten mit WinUI 3?

N / A

1. Was halten Sie von dem oben und in der Roadmap skizzierten Gesamtplan 3.0? Würde es Ihnen ermöglichen, WinUI für Ihre neuen und vorhandenen Windows-Apps zu verwenden?

Es gibt keine Erwähnung von Xaml Desktop in der Roadmap. Fällt dies in den Zuständigkeitsbereich von WinUI?
Ich habe dies bereits vor Leuten bei //Build/ erwähnt, aber der Grund dafür, UWP Xaml nicht zu übernehmen, ist, dass es unmöglich war, eine Anwendung zu erstellen, die vorhandene C++-Bibliotheken verwendet. Wenn ein Benutzer beispielsweise eine Datei mit FileOpenPicker auswählt , wird das Ergebnis als IStorageFile geliefert, und es gibt keine Möglichkeit, diese zum Öffnen an eine vorhandene Bibliothek von Drittanbietern libpng , libjpeg , etc). Aus diesem Grund mussten wir bei WPF bleiben. Wenn also Xaml Desktop oder Win32 + Xaml Islands es uns ermöglicht, ohne diese Einschränkungen zu leben, dann ja, es würde uns ermöglichen, WinUI für eine neue Anwendung zu verwenden.

1. Für welche Art von Apps würden Sie WinUI 3.0 am liebsten verwenden? Erstellen einer neuen Win32-App und Verpacken mit MSIX ? Hinzufügen neuer Ansichten zu einer WPF-App? Modernisierung einer C++-MFC-App mit Fluent UI?

Erstellen einer neuen Win32-App mit WinUI (und Verpacken mit MSIX).

Wenn Sie Fragen haben, lassen Sie es mich bitte wissen, ich bespreche gerne das weitere.

Ich hoffe tatsächlich, dass es eine Möglichkeit gibt, Compact Overlay von WPF/WinForms aufzurufen.
Wir brauchen nur ein Administratorberechtigungssystem wie "Berechtigung für andere Apps zeichnen" in Android.

Hoffe, dass dieses App-Modell + Verpackung (UWP + AppX, Win32 + MSIX) dies zulassen (Vollständige Abstraktion in Sandbox)

Soll Windows nicht die fortschrittlichsten und unbegrenzten Möglichkeiten mit bester Sicherheit sein?
Nein durch verkrüppelte Funktion für die Sicherheit.

Vielen Dank, dass Sie sich der Community für Beiträge zur Roadmap geöffnet haben.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Auf den Punkt gebracht, wir haben derzeit eine ganze Reihe von UWP-Apps für Unternehmenskunden im Einsatz, und ich hoffe, der Migrationspfad wird nicht so schwierig sein. Wenn es bahnbrechende Änderungen gibt Es wäre sehr schön, ein Migrationstool ähnlich dem .Net Framework zu .Net Core , das generiert, wie kompatibel unser Migrationspfad wäre, dies sollte alles melden, was geändert werden muss ( B. APIs, die möglicherweise veraltet sind oder sich anders verhalten) und eine Option zum automatischen Ändern des Namensraums, falls möglich. Auf diese Weise wird der Migrationspfad von UWP zu WInUI für uns Unternehmensentwickler nicht so volatil sein.

Kennen Sie Xaml Islands für die Modernisierung von Desktop-Apps?
Macht diese erweiterte Abwärtskompatibilität unter Windows 10 Xaml Islands für Sie nützlicher?

Ja, war aber kein großes Problem, da alle unsere neu entwickelten Desktop-Apps UWP-Kommunikation über ein API-Backend verwenden und die meisten unserer Kunden bereits Windows10 ausführen.

Was halten Sie von dem oben und in der Roadmap skizzierten Gesamtplan 3.0? Würde es Ihnen ermöglichen, WinUI für Ihre neuen und vorhandenen Windows-Apps zu verwenden?

Das Desktop-Team freut sich bereits auf die Neuigkeiten von WinUI 3, fürchtet aber, wie oben erwähnt, die Migration all unserer UWP-Apps darauf, wenn der Weg nicht so reibungslos verläuft.

Was das allgemeine XAML anbelangt, da das gesamte XAML-UI-Framework von Windows entkoppelt lebt, wie andere es geäußert haben, so dass es möglich ist, die Renderer auszutauschen. Dies wird die Möglichkeit eröffnen, WinUI XAML auf anderen Plattformen auszuführen, was heutzutage ein großer entscheidender Faktor ist, wenn sich die Leute für einen Stack entscheiden, an dem sie festhalten möchten, wie die Popularität von Electron- und JS-Frameworks zeigt, die diese Vorteile für kleine Unternehmen nutzen, die keine haben die Arbeitskraft, um speziell native Codebasen für jede Plattform zu entwickeln.

Fügen Sie auch hinzu, dass ab WinUI 3 auch der XAML-Dialekt verbessert werden sollte, möglicherweise einen Versionsnamespace / Doctype einführen, um anzugeben, welche Version von XAML verwendet wird, um die Abwärtskompatibilität für ältere Apps zu gewährleisten. Es gibt eine Menge auf machen XAML weniger ausführlich oder Chunk einige Text aus gemacht werden, wie mit schreiben INotifyPropertyChanged für ein mit Sicherung privaten Setter statt nur eine einfache Eigenschaft sein Attribut sagen NotifyPropertyChangedAttribute und lassen Sie die Build-Schritt die Implementierung einfügen, um Laufzeit-Overhead zu vermeiden, oder DependencyProperties für benutzerdefinierte Steuerelemente, um die Erstellung von Komponenten zu vereinfachen. Vielleicht nehmen Sie auch einige der Verbesserungen des Razor-Teams für einige der guten Teile, die sie haben.

Diese Anfragen sind möglicherweise machbar oder auch nicht, aber ich liebe XAML und würde es lieben, wenn es weiter verbessert würde.

@mdtauk Ich bin nicht gegen anstatt einen ganz neuen Satz von APIs zu verwenden und die win32-Datei-API aufzugeben. Ich weiß auch, dass dies weit vom Thema abweicht, aber die StorageFile/StorageFolder-API ist ein schrecklicher Ersatz, der nicht einmal die Dateisicherheit berücksichtigt. Sie sind langsam und Sie werden immer über den Laufzeit-Dateibroker weitergeleitet. Darüber hinaus sollte es nie eine Einschränkung sein, dass Sandbox-Apps eine spezielle, von MS genehmigte Erlaubnis benötigen, um in den Dokumentenordner des Benutzers zu schreiben. Nur wie beschissen die Dateigeschichte für den AppContainer-Aufwand war, es war unmöglich, irgendwo anders eine SQLite-DB zu erstellen, als im versteckten LocalData-Ordner des Benutzers. Für ein Desktop-System, auf dem Benutzer Dateien erstellen, speichern und öffnen und als yadda yadda speichern möchten, mussten die Softwareentwickler ihre Benutzer in der Verwaltung der Benutzerinhalte umschulen.

Was den Administratorzugriff angeht, wurde in der Version vom Oktober 2018 "allowsElevation" als Berechtigung hinzugefügt, was sinnvoll ist. Eine App könnte es einem Benutzer ermöglichen, als Administrator auszuführen, wenn er diesen umfassenden Zugriff auf Systemebene für einige Funktionen benötigt. Wir bauen nicht alle niedliche kleine Bildbearbeitungs- und Flussdiagramm-Apps.

@MarkIngramUK Vielen Dank für Ihre Kommentare, Nur eine Klarstellung. Das Xaml Desktop-Konzept, das auf der //Build 2019 in einem Sneak Peek vorgestellt wurde, wurde in WinUI Desktop umbenannt. Dieses neue Visual Studio-Projekt verwendet ein Win32-App-Modell mit WinUI als Präsentationsframework und kann nativ oder verwaltet sein (mit .NET Core 3).

Danke @marb2000 - liegt das innerhalb des WinUI 3.0-Zeitrahmens?

@marb2000 von WinUI Desktop, meinst du Win32-Apps mit Xaml-Inseln? In welcher Build-Sitzung wurde dies angezeigt?

Eine Sache, die das WinUI-Team bei der Umbenennung von WinUI 3.0 beachten sollte: Wenn Sie einen der in .NET projizierten Typen umbenennen, funktionieren die Projektionen nicht (und wir planen nicht, weitere hinzuzufügen, da dies nicht der Fall ist .) ein wartbares erweiterbares System). Hier ist eine Liste der Typen, die wir projizieren: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Alle Änderungen an anderen Typen als diesen Typen erfordern, dass Benutzer ihre Objekte in neue Objekte umschließen, die die neuen Schnittstellen implementieren, oder ihre Daten in die neuen Typen kopieren. Insbesondere die Typen INotifyPropertyChanged und INotifyCollectionChanged sind in Bezug auf XAML-Inseln und die Bereitstellung von Downstream-Support von Interesse.

INotifyDataErrorInfo

Bitte führen Sie keine neuen Namespaces für Dinge wie INotifyDataErrorInfo ein - sie sollten in Ansichtsmodellen verwendet werden, die normalerweise plattformübergreifend sind und nicht von WinUI abhängig sein sollten. Es sollte definiert werden, wo sich andere Dinge wie diese befinden (dh INotifyPropertyChanged oder INotifyCollectionChanged).

Über dieses Thema. Windows.UI.Xaml.Interop verfügt bereits über eine INotifyCollectionChanged-Schnittstelle und Windows.UI.Xaml.Data verfügt über INotifyPropertyChanged. Diese beiden werden in Microsoft-Namespaces verschoben. Vielleicht können die System.Runtime.WindowsRuntime-Assemblys eine Zuordnung von WinUI zu .Net vornehmen

Danke für die Antwort, aber warum brauchen Sie es im Microsoft-Namespace, wenn .NET Standard es bereits in System.ComponentModel hat? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky. NET ist nur ein Framework, mit dem Sie Apps mit UWP XAML erstellen können. Sie möchten, dass Entwicklern eine Textfeldvalidierung zur Verfügung steht, unabhängig davon, welches Framework sie verwenden

@mdtauk , nein, WinUI Desktop (früher Xaml Desktop) ermöglicht es Ihnen, Xaml direkt mit Win32 zu verwenden, ohne die Insel zu verwenden.

@marb2000 Es wäre großartig, wenn Sie mit dem Application Packaging Project eine AppX mit einem Win32-Fenster erstellen und WinRT-Komponenten auf die gleiche einfache Weise einschließen können wie ein UWP-Projekt. Es gibt viele Dinge, die nicht funktionieren, ohne die vcxproj-Dateien manuell zu bearbeiten, z. B. das Hinzufügen von Ressourcen und der cppwinrt-Compiler, der die Header aus den enthaltenen WinRT-Komponenten generiert.

Ein weiteres Projekt, das für diese neue Benutzeroberfläche wichtig ist, ist das _PropertyChanged.Fody_ von Simon Cropp , das eine automatische Implementierung von INotifyPropertyChanged ermöglicht (ich habe es mit C# / F# versucht). Siehe https://github.com/Fody/PropertyChanged

Es ermöglicht einen einfachen Code wie diesen:

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

die wir verwenden können, um an die Benutzeroberfläche zu binden.

Eine Sache, die ich in WinUI 3.0 sehen möchte: Derzeit kann der UWP-XAML-Compiler ( genxbf.dll ) nur direkt von MSBuild aufgerufen werden, wenn er von einer csproj-, vbproj- oder vcxproj-Datei referenziert wird. Dies liegt daran, dass es kein Befehlszeilentool gibt, mit dem diese Funktionalität aufgerufen werden kann. Dies scheint mir eine sehr seltsame Entscheidung zu sein, da nichts anderes im Windows 10 SDK-Download Visual Studio erfordert. (Das WDK-Add-On enthält auch Visual Studio-Ziele, aber diese Ziele rufen alle Befehlszeilentools auf, die unabhängig von VS verwendet werden können.) Ich würde es sehr begrüßen, wenn zB XbfCompiler.exe und XbfCodeGen.exe in das bin-Verzeichnis des SDK. (Die erstere EXE würde XAML-Dateien in XBF-Dateien kompilieren, und die letztere würde die Code-Behind-Dateien generieren, die erforderlich sind, um XAML-Typen aus dem Code zu referenzieren.) Dies wäre hauptsächlich in C++-Projekten nützlich, die CMake oder andere nicht-visuelle verwenden Studio-Build-Tool, kann aber bei Bedarf auch für C#- und VB.NET-Projekte verwendet werden. Vielen Dank!

@MarkIngramUK wissen Sie zufällig, wo ich mehr über WinUI Desktop erfahren könnte. Diese Build 2019-Sitzungen können nicht online angesehen werden. Klingt nach wichtigen Informationen, die in diesem Repo verlinkt werden sollten

@mdtauk Es wurde in einem sogenannten Sneak Peek erwähnt, der nur für Build-Besucher https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk Die WinUI 3-Roadmap enthält die neuesten Informationen und Diagramme, die noch aktueller sind als das, was beim Build-Sneak-Peek gezeigt wurde. Es gibt weder "XAML Desktop" noch "WinUI Desktop"... das war nur eine verwirrende Wortwahl auf einer Folie, die fotografiert wurde. Das Konzept, das kommuniziert wird (und die Roadmap versucht, dies klarer zu erklären), ist, dass wir für WinUI 3 daran arbeiten, eine Projektvorlage zu erstellen, die eine neue traditionelle Desktop-/Win32-Modell-App mit WinUI 3 für die Benutzeroberfläche erstellt (genauso wie es heute Vorlagen für UI-Frameworks wie WinForms, WPF, MFC usw. zusätzlich zum traditionellen Desktop/Win32-Modell gibt) zusätzlich zu einer aktualisierten UWP/WinRT-Modell-App-Projektvorlage, die WinUI 3 verwendet helfen zu klären?

Die 3.0- Roadmap scheint für die folgende Strategie durchaus sinnvoll: Ermöglichen Sie jeder Windows-Client-App die Verwendung von XAML und den "modernen" WinUI-Steuerelementen.

Diese Strategie erscheint jedoch kurzsichtig, wenn man die Realität des heutigen Marktes bedenkt: Für viele App-Entwicklungen sind Android und iOS die primären Ziele, und Windows ist ein Nice-to-have. Für .NET-Entwickler bietet Xamarin eine anständige Android- und iOS-Unterstützung, aber ihre Windows-Unterstützung ist unterdurchschnittlich. Für native Mobil-/Desktop-Apps trägt Win UI 3.0 also nicht dazu bei, die plattformübergreifende Entwicklung für .NET-Entwickler zu vereinfachen.

Was ich wirklich gerne sehen würde, ist ein zukunftsweisender XAML-Dialekt mit wirklich universellen Bestrebungen. Ich sollte in der Lage sein, eine .NET-App mit XAML zu schreiben und diese App unter Windows, iOS und Android ausführen zu lassen. Die App sollte auf jeder Plattform wirklich erstklassig sein und bei Bedarf Zugriff auf native Elemente haben. Wie bereits erwähnt, ist Xamarin ein guter Anfang, aber sein XAML-Dialekt ist sehr unterschiedlich, es hat eine schlechte Windows-Unterstützung und keine Ihrer Arbeiten hilft.

Also, tldr, gut, dass Sie weiterhin eine moderne UI-Plattform für Windows bereitstellen. Gut, dass Sie die Verwendung von verschiedenen Arten von Apps vereinfachen. Schade, dass Sie keine plattformübergreifende Unterstützung anstreben.

Deaktivieren oder deaktivieren Sie optional die Lebenszyklusverhalten älterer mobiler Anwendungen, z. B. Suspend + Tombstone.

Die Realität ist, dass UWP eine Desktop-Umgebung ist, und zumindest bei Spielen kann der Benutzer die App oft minimieren, was normalerweise zum Suspendieren/Tombstoning der App führt. Dies ist eine erschütternde Erfahrung, die sich stark von jeder Win32-Desktop-App oder jedem Win32-Spiel unterscheidet. Die Beantragung einer verlängerten Stundung, die wahrscheinlich noch ausläuft, reicht nicht aus, um dies nahtlos zu bewältigen.

Während dieser Lebenszyklus für einige Apps praktisch ist, ist er für andere nachteilig. Im Idealfall sollte eine Desktop-App oder ein Spiel in der Lage sein, eine Funktion zu deklarieren, die es der App ermöglicht, sich vom Suspend+Tombstone-Lebenszyklusmodell abzumelden, was verhindern würde, dass es beim Minimieren schließlich ausgesetzt wird.

@natemonster

Per: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

Auf Desktop-Geräten haben erweiterte Ausführungssitzungen, die mit ExtendedExecutionReason.Unspecified erstellt wurden, ein batteriebewusstes Zeitlimit. Wenn das Gerät an das Stromnetz angeschlossen ist, ist die Länge der verlängerten Ausführungszeit unbegrenzt. Befindet sich das Gerät im Akkubetrieb, kann die verlängerte Ausführungszeit bis zu zehn Minuten im Hintergrund laufen.

Ein Tablet- oder Laptop-Benutzer kann das gleiche lange Betriebsverhalten erzielen – auf Kosten der Akkulaufzeit –, wenn die Option Ausführen von Hintergrundaufgaben durch die App zulassen in Akkunutzung durch App-Einstellungen ausgewählt ist.

@TonyHenrique Wenn Sie Fody erwähnen , möchten Sie ein Bewusstsein dafür schaffen oder sagen Sie, dass es in WinUI integriert werden sollte?

Element- oder Bibliotheksvorlagen sind auch interessant! In den bisherigen Antworten gibt es einige großartige Punkte in Bezug auf die Bereitstellung zusätzlicher Boilerplate- und Starter-Codes, die wir im Laufe der Zeit hinzufügen könnten, etwa wie das Windows Template Studio.

@Jesbis Ich trage maßgeblich zu Windows Template Studio bei und beobachte die WinUI-Roadmap im Hinblick auf unsere zukünftigen Aktivitäten und die Einführung der Unterstützung für WPF. ;)

Welche Art von Abhängigkeitsaktualisierungen würden es wertvoller machen? zB neue kompatible NuGet-Paketversionen finden?

In der Lage zu sein, NuGet-Updates zu erkennen, wäre nützlicher, aber es gibt andere potenzielle Kompatibilitätsprobleme bei der Durchführung von Updates. Ich würde der Erkennung neuer Versionen und der automatischen Konvertierung eine niedrige Priorität einräumen. Es gibt so viele Überlegungen, dass es ein großes Projekt für sich wäre und ich würde lieber Zeit in die Plattform investieren als in ein Tool wie dieses.

@mrlacey Ich habe einen besseren Weg brauchen
Es funktioniert auf C#-Klassen und sogar auf F#-Datensätzen (hatte jedoch einige Schwierigkeiten).
Auf der WinUI-Roadmap sollte dies also auch stehen.

Hinweis: Es wäre gut, wenn wir auch die F#-Datensätze verwenden könnten, um unsere Datenentitäten zu definieren und dann direkt an die XAML-Benutzeroberfläche zu binden. Es wäre cool, wenn wir F# Records + Fody + DataBinding ohne Probleme verwenden könnten.

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

Dies wäre für Leute, die von C# kommen, vertrauter.
Ein anderer Ansatz wäre der Elmish-Weg. Ich denke, dass beides interessant ist und unterstützt werden könnte.

@tonyhenrique / @mrlacey Ich denke, das Fody-Zeug (OAP) sollte außerhalb des Geltungsbereichs liegen. Das WinUI-Team hat bereits genug auf dem Teller, und ich denke, es ist besser, das Weben in separaten Projekten zu haben (viel schnellere Release-Zyklen bei Verbesserungen).

Und ich denke, dies ist eigentlich ein .NET (IL)-Implementierungsdetail der Modelle, nicht wirklich etwas mit WinUI zu tun (obwohl es auf die Änderungsereignisse hören kann). Mein Vorschlag ist, sie getrennt zu halten. Zum Beispiel verwende ich Catel und es hat seine eigenen Fody-Weber, um sicherzustellen, dass alles richtig gewebt wird.

Was ich wirklich gerne sehen würde, ist ein zukunftsweisender XAML-Dialekt mit wirklich universellen Bestrebungen. Ich sollte in der Lage sein, eine .NET-App mit XAML zu schreiben und diese App unter Windows, iOS und Android ausführen zu lassen. Die App sollte auf jeder Plattform wirklich erstklassig sein und bei Bedarf Zugriff auf native Elemente haben.

Es gibt einen langjährigen Vorschlag, in diese Richtung zu gehen: Plattformübergreifendes UX für .NET 5 – Originaltitel Cross platform UX for .NET Core 3.0 . Die überwältigende Unterstützung der Community dafür ist offensichtlich und wir können hoffen, dass MSFT erkennt, dass dies die beste Richtung ist, um ein UI-Framework zu entwickeln, das auf .NET funktioniert. Es gibt so gut wie keinen Grund, separate Codebasen für verschiedene Plattformgruppen zu unterhalten und auf der Grundlage unterschiedlicher UX-Frameworks, die von .NET unterstützt werden, zwangsweise separate Entwickler-Skills zu erstellen.

Durch die Schaffung einer einzigen UX für alle Plattformen beseitigen wir alle Ineffizienzen bei der Framewrk-Entwicklung und senken die Hindernisse für die Akzeptanz durch Entwickler.

@mfeingol / @4creators , ich würde mich damit

Die App sollte auf jeder Plattform wirklich erstklassig sein

unter Windows zum Starten...

Es ist 2019, ich möchte eine schnelle, native Benutzeroberfläche und ich möchte nicht ernsthaft darüber nachdenken müssen, eine Benutzeroberfläche mit CreateWindowExW , GDI usw.

Gibt es jetzt, da mit WinUI3.0 und höher der Code von Windows 10 entkoppelt ist, Pläne, dass WinUI in Zukunft auf Linux und Mac funktioniert?

@jesbis Touch-Interaktionen werden in WinUI 3.0 beibehalten?

Danke für die Klarstellung, ich hatte angenommen, dass 3.0 funktionieren würde, indem man Xaml Islands in WinUI einbindet, anstatt das Community Toolkit zu verwenden.

Da es zu XAML plus Win32 wird, ist es sinnvoller, insbesondere wenn das Windows Core OS seine Shell in XAML umschreibt.

So wie ich es jetzt verstehe, ist dieser umfangreiche Win32-API-Zugriff in C und C++ | mit allem in C#, das auf .NET basiert (alles sei es jetzt .NET Core).

Vielleicht sollte es eine sichere und einfache Möglichkeit geben, auf diese Win32-APIs sowie auf mehr Einstiegspunkte zum Anzeigen einer Apps-Benutzeroberfläche zuzugreifen?

• XAML-Flyout in der Taskleiste für WinUI 3-Apps

• einfache Picker-UIs für Hololens/Xbox/Surface Hub/IoT usw.

• aktualisierte XAML-anpassbare allgemeine Dateidialoge und Ordnerauswahl

• einfacher C# .NET-Zugriff auf Win32-APIs

• kompakte Einstellung für alle XAML-Elemente, die der Größe von Win32- und WPF-Steuerelementen entsprechen (dies hilft Frameworks, bequem zusammen zu sitzen)

• passende Steuerelementstile/Schriftarten/Akzentpinsel/Acryl bei Verwendung von WinUI

• klare Definition, welche Geräte den WinRT/Mobile Lifecycle benötigen

• Integrierte Xbox Next-Steuerungsstile für die Entwicklung und das Testen von Xbox-Apps unter Windows

• Speichern und einzelnes exe/MSI/APPX-Verpacken und Herunterladen werden standardmäßig unterstützt, KEINE INSTALLATEUR, standardmäßige Dateisystemvirtualisierung vom Typ Centennial

• WinForms WinUI 3.0 - einfache Benutzeroberfläche, Zugriff auf MFC, Maus und Tastatur nur

• WPF WinUI 3.0 - dichte Benutzeroberfläche, 3D-Rendering, DPI-fähig, simulierte Berührung und grundlegende Tintenunterstützung

• Xaml WinUI 3.0 - Full Touch, MR, Gamepad, Freihand, Stimme, Maus, Tastatur. Dichte und einfache Benutzeroberflächen. Neue Fensterunterstützung. MR-3D-Rendering. Optional verwalteter Lebenszyklus oder Desktop-Lebenszyklus. Der beste Standard

Touch-Interaktionen werden in WinUI 3.0 beibehalten?

@r7dev Ja, der Plan ist, das gleiche Maß an Touch-Unterstützung

F# wird in der WinUI 3.0-Roadmap ignoriert. Microsoft ignoriert erneut eines seiner Produkte.

Gedanken zur Win32-API

Etwas, worüber ich auch nachgedacht habe, ist der Grund, warum Win32 auch geblieben ist. Ich denke, es gibt eine Vermutung, dass dies auf Legacy-Projekte zurückzuführen ist, aber es ist tatsächlich viel tiefer. Das Win32-ABI lässt sich super einfach mit der Sprache Ihrer Wahl verbinden, nodejs, python, rust, go, ruby, c#, c++ usw. Wenn mein Kernprojekt zum Beispiel in rust ist und ich ein Fenster generieren möchte Um die Ausgabe zu verwalten, ist es als Rust-Entwickler sehr mächtig, auf das Win32-API-Set zuzugreifen und ein Frontend in derselben Sprache zu erstellen.

Unter OS X mussten Sie für den Zugriff auf AppKit nur die objc_msgSend C-API überbrücken und Zugriff auf die gesamte obj-c-Infrastruktur erhalten. Alle oben genannten Sprachen haben dies wirklich gut überbrückt und es war einfach, in der Sprache Ihrer Wahl zu schreiben und etwas Fesselndes zu produzieren.

Wenn Sie also WinUI 3.x zum echten Weg für den Zugriff auf eine Win32-Benutzeroberfläche mit geringer Latenz, geringem Speicher und hoher Qualität machen möchten, müssen Sie die Leichtigkeit berücksichtigen, mit der andere Sprachverwalter auf die Infrastruktur zugreifen können.

UI-Konsistenz

Wenn Sie wirklich planen, die Benutzeroberfläche vom System zu entkoppeln, wie sieht der Plan aus, damit die Benutzeroberfläche bei jedem Betriebssystem-Upgrade konsistent bleibt? Wenn Apple in AppKit oder iOS Änderungen an Schatten und Farbverläufen vornimmt, übernehmen Apps, die auf den Systemframeworks basieren, alle diese Optimierungen und bleiben konsistent. Es wird Ihnen auch erschweren, systemweite Erfahrungen hinzuzufügen, da Apps, die vor 3 Jahren an UI-Infrastrukturen gebunden waren, mit einigen neuen Systemdiensten möglicherweise nicht gut funktionieren, sodass sie im Laufe der Zeit eine andere Kompatibilitätsebene haben werden.

Es wird immer Funktionen geben, die aktiviert werden müssen. Ich kann mir den Dark Mode als etwas vorstellen, das, wenn die App nicht dafür entwickelt wurde, wirklich keinen Sinn machen würde, es als Option anzubieten, aber es gibt immer noch Anpassungen an Systemkomponenten, die sich im Laufe der Zeit ändern würden.

Binäre Größe

Was ist die geplante Geschichte für die Bereitstellung all dieser UI.dlls mit unseren Projekten? Werden diese Dinge 40 MB Laufzeit haben, die mit unseren Projekten ausgeliefert werden müssen? Was passiert, wenn ein Projekt aufgegeben wird, werden sie veraltet aussehen, weil sie alte UI-Frameworks verwenden?

Einer der Vorteile von C++ besteht darin, dass es je nach Codebasis einen minimalen Bibliotheks-Overhead hat. Wenn jede einzelne App von hier an WinUI 3.x benötigt, werden dies sicherlich 40 MB x Anzahl von Apps sein.

Binäre Größe

WinUI ist bereits eine Abhängigkeit, genau wie .NET. Es ist bereits eine systemweite Bibliothek. :)
Sie haben keine duplizierten DLLs, und Sie werden sie nicht haben.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

"Etwas, worüber ich auch nachgedacht habe, ist der Grund, warum Win32 auch geblieben ist. Ich denke, es gibt eine Vermutung, dass dies auf Legacy-Projekte zurückzuführen ist, aber es ist eigentlich viel tiefer. Die Win32-ABI lässt sich super einfach mit der Sprache deiner Wahl verbinden , nodejs, python, rust, go, ruby, c#, c++ usw. usw. Wenn mein Kernprojekt zum Beispiel in rust ist und ich als rust-Entwickler ein Fenster zum Verwalten der Ausgabe generieren möchte, ist es super mächtig, um greifen Sie auf das win32-API-Set zu und erstellen Sie ein Frontend in derselben Sprache."

Dies ist jedoch eine gemischte Sache, da die Implementierung der WinRT-Unterstützung für eine neue Sprache zwar ein riesiger Buckel ist, den es zu überwinden gilt, aber wenn Sie dies tun, erhalten Sie automatisch generierte typisierte Bindungen an alle neuen APIs. Ich habe vor kurzem an einem Rust-Projekt gearbeitet, das Win32 und WinRT überbrückt (unter Verwendung der Kompositions-APIs in einem Win32-Fenster), und die Win32-Teile waren insgesamt definitiv schmerzlicher, obwohl ich die restlichen ungeschickt umgehen musste fehlende Rust-Unterstützung für einige WinRT-Funktionen wie die Klassenvererbung. (Es hilft definitiv, dass die Verwendung von Composition in Win32 jetzt möglich ist, da die Unterstützung für diese Funktion schrittweise verbessert werden kann, anstatt das gesamte App-Modell auf einmal angehen zu müssen.)

Das wahrscheinlich größte Problem ist, dass die Dokumentation für WinRT ABI-Details auf niedriger Ebene irgendwie desorganisiert ist und es in der Welt / Community nur sehr wenig Verständnis oder Bewusstsein dafür gibt. Ich hoffe jedoch, dass sich diese Situation mit dem xlang-Projekt verbessert.

Welche Vorlagen interessieren Sie am meisten?

Derzeit beginne ich lieber mit einem Blank App (Universal Windows) Projekt. Ich mag auch Templates mit vorkonfiguriertem Framework, aber nur, wenn ich schnell etwas ausprobieren möchte. Eine "Hauptmenü"-Vorlage und eine MDI-Vorlage für UWP wäre auch schön (da diese Vorlagen auch für WinForms existieren)

Kennen Sie Xaml Islands für die Modernisierung von Desktop-Apps?
Macht diese erweiterte Abwärtskompatibilität unter Windows 10 Xaml Islands für Sie nützlicher?

Ja, ich kenne Xaml Island. Wenn ich kann, werde ich versuchen, bei einer reinen WPF- oder reinen UWP-App zu bleiben. Ich war nicht in einer Situation, in der ich eine solche Funktion benötigen würde.

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Ja, sicher, wenn es zuverlässig funktioniert! Ich bin überrascht von den vielen Kommentaren, die ein so nettes Feature nicht zu schätzen wissen. Auch dieses Feature könnte prüfen, ob ein Update auf WinUI 3.0 machbar ist, den XAML-Code übernehmen, die Namespaces anpassen und die benötigten WinUI-Nugets installieren.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Ich würde erwarten, nur die Namespaces des Steuerelements zu ändern, damit es vollständig mit WinUI 3.0 funktioniert. Ich möchte nicht viel Zeit in das Upgrade auf WinUI 3.0 investieren

Erstellen oder verwenden Sie UWP-Xaml-Steuerelementbibliotheken oder WinRT-Komponenten, die Sie nicht einfach zusammen mit App-Code neu kompilieren und aktualisieren können?

Ich verwende UWP-Xaml-Steuerelementbibliotheken von Drittanbietern (wie das Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement ). Ich denke, ich wäre in der Lage, einfache Steuerelemente aus Bibliotheken von Drittanbietern wie einem Dockpanel selbst auf WinUI 3.0 zu aktualisieren.

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Xaml-Komponenten mit WinUI 3?

• Erstellen Sie in Visual Studio für UWP eine "Leere App mit WinUI 3.0"-Projektvorlage. Die WinUI 3.0-Abhängigkeit wird als Nuget installiert (wie in WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . Ich würde eine solche Lösung unbedingt bevorzugen, solange ich alle grundlegenden Steuerelemente bekomme. Ich würde erwarten, dass alle Klassen von Windows.UI eine entsprechende Klasse im Microsoft.UI-Namespace haben.

Das Hauptthema in WinUI 3.0 war alles über Steuerelemente und Windows 10-Kompatibilität, die von UWP und WPF oder WinForms über XAML Island verwendet werden können, wenn ich richtig liege. Besteht die Möglichkeit, dass das UWP-XAML-Markup irgendwie zusätzliche Funktionen erhält?

• Style-Trigger fehlen
• Stil `BasedOn={StaticResource {x:Type TextBlock}} fehlt
• Definierte DataTemplates mit DataTypes werden nicht wie in WPF automatisch angewendet (nur über Key)
• Warum wird jedes zweite Windows.UI.Xaml.Controls Steuerelement (TextBlock, Border,...) als versiegelt deklariert?! Bitte tun Sie dies nicht in WinUI 3.0 mit UWP.
• Markup-Erweiterungen für WPF-Parität
• Dies wurde bereits erwähnt, aber ich werde es noch einmal erwähnen. Es ist traurig, dass UWP die System.ComponentModel.IDataErrorInfo nicht verwendet. Auf diese Weise kann ich mein Modellprojekt nicht für die UWP-Lösung freigeben.
• ReportControl (für Unternehmensanwendungen)

Ich freue mich sehr auf WinUI 3.0 und seine Abwärtskompatibilität!

F# wird in der WinUI 3.0-Roadmap ignoriert

Besteht die Möglichkeit, dass das UWP-XAML-Markup irgendwie zusätzliche Funktionen erhält?

@Happypig375 , @mfe-:

Die Roadmap deckt nur die erste Version 3.0 ab, und für die erste Version konzentrieren wir uns hauptsächlich auf Parität und Abwärtskompatibilität für vorhandene Funktionen mit einer kleinen Anzahl neuer Funktionen.

Wenn Sie der Meinung sind, dass andere neue Funktionen wie eine bessere F#-Unterstützung oder neue Markup-Funktionen wichtig sind, öffnen Sie bitte

Warum wird jedes zweite Windows.UI.Xaml.Controls-Steuerelement (TextBlock, Border,...) als versiegelt deklariert?! Bitte tun Sie dies nicht in WinUI 3.0 mit UWP.

Das Entsiegeln von Kontrollen ist tatsächlich eine der wenigen neuen Funktionen, die wir in 3.0 einbinden möchten 😊

Wenn es um Sprachen geht, wäre es nett, sie zu kombinieren (was in Ordnung sein sollte, wenn alles vor dem Verpacken kompiliert wird).

F# wird für Back-End-Logik verwendet - C# für Databinding und UI-Code - C++ für Steuerelemente und vielleicht einige Low-End-Win32-Hooks oder sogar zum Starten eines WinForms-Dialogs.

Alle Codesprachen sind gleich und austauschbar, wobei WinUI 3.0 die gesamte Benutzeroberfläche verarbeitet

Das ist xlang 😉

Das ist xlang 😉

@MarkIngramUK Hmm , ich dachte, es wäre eine Brücke zwischen den Sprachen, die jede Sprache abstrahiert, anstatt

Ich hatte Mühe, den Zweck von xlang zu verstehen - die Aktualisierungen zu beschönigen, die im Repo stattgefunden haben (aber habe es immer noch auf meiner Beobachtungsliste).

Funktioniert xlang vor oder nach der Kompilierung? Ist es eine eigene abstrahierte Sprache, die projiziert werden kann, oder sitzt sie nur zwischen bestehenden Codedateien?

Ja, Sie können keine Sprachen in einem einzelnen Projekt mischen. Es ist eine Brücke, aber immer noch nützlich für diese Zwecke.

@MarkIngramUK Ich denke schon, wenn sein Code kompiliert werden kann, dann ist er enthalten.

Es wäre gut, C# verwenden zu können, um auf native Win32-Funktionen zuzugreifen, ohne PInvokes und andere .NET-Tricks

@jesbis Ich bin ehrlich gesagt mehr an plattformübergreifenden Aspekten dieses Projekts interessiert ...

Ich denke, am Anfang solltet ihr es in etwas _generischer_ umbenennen und nicht streng in "Windows".

Ich habe es verstanden, dass die anfängliche Implementierung strikt auf Win32 und zurück UWP/Xamarin-Apps und Windows ausgerichtet sein sollte, aber nur OSS es und es von Anfang an wie ein "nur Windows"-Framework nennt, wird definitiv nicht viel Zugkraft bekommen, genau wie UWP nicht und Entwickler von anderen Plattformen würden sich nie dafür interessieren.

Wenn das Ziel von .Net 5 "One .Net Everywhere" sein soll, was im Grunde seit .Net 1.0 immer jeder erwartet hat, sollten die Grundlagen für das Framework "Anything but Win UI" plattformübergreifend beginnen.

Ein sehr gutes Beispiel dafür, wie man es richtig macht, ist Google Flutter. Flutter befindet sich noch in den Anfängen, hat aber VIEL Traktion aufgrund der Tatsache, dass ihr Kern (auch bekannt als Flutter Engine) zu 100% plattformübergreifend ist und überall funktioniert (einschließlich IoT, Win, OSX und jetzt sogar Web!).

Das ist nur mein 2c. Ich würde gerne wieder an Xaml arbeiten, aber wenn es auf der gleichen Linie wie bei UWP bleibt, fürchte ich, dass es nicht die richtige Traktion bekommt und ein weiterer Versuch sein wird, WPF neu zu schreiben, der schließlich einen weiteren Versuch in die Zukunft und so weiter.

Bitte machen Sie mich nicht wütend und verstehen Sie meinen Kommentar nicht als schlechte Kritik. Ich wünschte nur, dass die Bemühungen um die Benutzeroberfläche in der .Net-Welt so etwas wie Flutter, .Net Core 3.0/.Net 5 und sogar Blazor erhalten würden.

Für das Protokoll habe ich ein Projekt gestartet, um die Flutter-Engine vollständig auf C# und .Net Core umzuschreiben/zu portieren, da es in .Net World an Optionen mangelt...

Übrigens, CoreUI ist ein guter Name...

Ein großes Lob an Jake Helfert für diesen Vorschlag 😄

💃

Übrigens, CoreUI ist ein guter Name...

Ein großes Lob an Jake Helfert für diesen Vorschlag 😄

💃

CoreUI kann mit .NET Core verwechselt werden

WinUI konzentriert sich stark auf Windows, aber das darin enthaltene XAML-Framework könnte Renderer für Metal (iOS und macOS) oder Vulkan (Android) erhalten – und FabricWeb könnte der PWA/ChromeOS-Weg sein, um mit den anderen Plattformen umzugehen.

Wenn sich das Team jemals dafür entscheidet, die Präsentationsplattform zu übernehmen, könnten Xland oder Xamarin die Laufzeit für plattformübergreifende Apps übernehmen.

Zur Migration von Posteingangs-UWP-UI zu WinUI 3.0 zitiere ich einen aktuellen Blog-Beitrag von @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ):

Fun Bottom Note: Was mit UWP passiert, ist nicht, dass es getötet wird: Microsoft dreht sich um und bringt die besten Teile dorthin, wo wir sie brauchen. Dies geschah tatsächlich schon einmal, wurde aber leider nicht zum Anlass genommen, einen Pivot durchzuführen. Erinnern Sie sich an Silverlight? Erraten Sie, woher die plattformübergreifende CLR von .NET Core stammt. Und auch viel Code von Silverlight landete in UWP. Hätten sie sich nur gewendet und gesagt: "Ja, wir sind uns einig, dass Silverlight im Consumer-Bereich keinen Sinn macht, aber im Unternehmensbereich floriert, also bauen wir darauf auf und entwickeln es in .NET Core und Windows Store weiter". Leider lief das nicht so reibungslos, und viele Leute leiden immer noch an PTSD und sind misstrauisch gegenüber allem, was Microsoft tut, das jede Technologie zu zerstören scheint.

Ich denke, es ist wirklich wichtig, sich daran zu erinnern, dass die Wahrnehmung, dass bestehende Frameworks zerstört oder zurückgesetzt werden, ohne Entwicklern und Codebasen einen guten Weg nach vorne zu geben, nicht nur die Entwickler des bestehenden Frameworks beeinflusst - es kann eine Wolke über zukünftige Bemühungen werfen, da sich jeder fragt, warum dies Neues wird nicht nur das gleiche Schicksal erleiden. Dies ist nicht als Bemerkung zu einem bestimmten vorgeschlagenen Migrationsansatz gedacht, sondern als Reaktion auf die Kommentare, dass die Migration keine Rolle spielt, da nicht viele Leute das vorhandene UI-Framework für den Posteingang verwenden. Das ist nicht die einzige Überlegung!

Bei @weitzhandler WinUI 3.0 geht es darum, verschiedene Win32-, .NET Core- und UWP-Frameworks mit einem einzigen XAML-Framework zu kombinieren und mit WPF, WinForms und MFC++ zu interagieren

XAML unter Windows wird auf Direct X heruntergerendert.

Wenn Sie dasselbe XAML in Kombination mit .NET Core verwenden und auf anderen Plattformen zum Laufen bringen möchten. Sie müssten für diese Plattformen neue Renderer schreiben. iOS und macOS verwenden Metal als ihr Direct-X-Äquivalent. Android verwendet Vulkan. Keine Ahnung, wie Linux das Rendering handhabt, ich würde vermuten, dass es nur Open GL ist.

Microsoft wird das nicht selbst machen wollen, weil es für sie keinen Sinn macht. Aber WinUI 3.0 wird Open Source sein – also könnten andere versuchen, es plattformübergreifend zu bringen

@mdtauk

Danke für die Klärung. Flutter ist wahrscheinlich die Zukunft für mich.

Das ist nur mein Verständnis, ich könnte mich irren.

Flutter soll in Zukunft Windows-Support bekommen. Und die Unterstützung von React Native wird auch für Windows verfügbar sein. Außerdem gibt es PWAs, wenn Sie in diese Web-HTML- und Javascript-Welt investiert sind.

Für mich kann die ganze WinUI-Geschichte mehr Sinn machen, wenn sie auch berücksichtigen, dass zumindest eine grundlegende Teilmenge davon plattformübergreifend (macOS, iOS, Android) einschließlich Web ausgeführt wird und auch eine bessere F#-Unterstützung und Projektvorlagen (einschließlich XAML-Zwei-Wege-Bindung an F#-Datensätze und auch ein funktionalerer Elmish-Weg)

XAML muss umgebungsunabhängig sein, genau wie HTML, ohne selbst für die einfachsten Tool-Apps mehr als 100 MB zu benötigen, wie dies bei HTML-Apps der Fall ist. Damit ist ein XAML-Framework gemeint, das in reinem C/C++ oder C# geschrieben ist und mit minimalem Portierungsaufwand in WASM, Win32, UWP, iOS, Android, macOS, Linux etc. gehostet werden kann. Sie benötigen ein agnostisches Rendering-Backend, wie es Game-Engines zu Beginn verwenden.

Keine, wenn dieses UWP-fokussierte XAML irgendwelche Probleme löst, die mein Unternehmen oder ich persönlich seit Jahren mit XAML hatte ... und das ist Portabilität. TBH MS geht über die Benutzeroberfläche völlig falsch und wird schnell nirgendwo hinkommen (es verschwendet viel wertvolle Zeit für viele Leute). Dieser UWP-XAML-Hacker kommt bei den Leuten, denen ich ihn zeige, einfach nicht gut an ... was traurig ist, denn es bedeutet nur einen nie endenden Widerstand gegen die Einführung von XAML und ich habe an dieser Stelle keine Argumente mehr.

Die einzige Möglichkeit, XAML zu speichern, ist meiner Meinung nach:

• Erstellen Sie eine neue agnostische/portable Framework-Basis für .NET Core und C/C++.
• Erstellen Sie eine agnostische Rendering-Abstraktionsschicht, die jeder über Pull-Requests erweitern kann.
• Genau wie HTML konzentriert sich XAML auf Einzelfenster-App-Konzepte (wie auch in Spielen), ABER erweiterte Desktop-Funktionen für mehrere Fenster usw. (Dies ermöglicht es der App, in fast jedem Kontext ausgeführt zu werden, genau wie eine Spiele-Benutzeroberfläche).

Einfach ausgedrückt gibt es zwei Bedingungen, die zu einer kombiniert werden müssen, bevor die XAML-Anpassung ausgenommen wird.

1 MS muss das XAML-Projekt unterstützen oder die Leute befürchten, dass es herausfällt.

2 Es muss plattformübergreifend sein, oder jeder wird mit verrückten, aufgeblähten HTML-Laufzeiten stecken bleiben.

Wie auch immer, das sind meine zwei Cent und wenn WinUI 3.0 richtig ausgelegt ist, ist vielleicht eine Portierung möglich. An diesem Punkt jedoch idk, was Sie fühlen sollen.

Es gibt hier ein paar Kommentare zur plattformübergreifenden Nutzung, und ich bin mir nicht so sicher, ob WinUI plattformübergreifend sein muss, um erfolgreich zu sein. Auf Mac oder Linux würde es sowieso nicht gut funktionieren, da es so unterschiedlich ist, dass es sich auf keiner dieser Plattformen nativ anfühlt. Dieses Projekt gehört einem Team, das über umfassende Kenntnisse über die Funktionsweise von Windows-Interna verfügt.

Außerdem ... Fluent auf dem Mac würde sich klobig anfühlen, schauen Sie sich nur iTunes an, Apple musste sein gesamtes UI-System auf Windows portieren, und es fühlt sich definitiv fehl am Platz an. Das Rendering von Schriftarten ist anders, die Animationskurven und Schatten und die Farbauswahl fühlen sich in Win10 einfach so fehl am Platz an. Ich meine, es ist sicher gut und verwendbar, aber ich bevorzuge Spotify, das nicht versucht, eine Desktop-Benutzeroberfläche zu emulieren und nur einen Webbrowser unter der Haube verwendet. Auf einem Mac würde das Ansehen des Enthüllungsscheinwerfers mit quadratischen Komponenten in einem Desktop voller abgerundeter Ecken und ohne Enthüllungseffekt so hart kollidieren.

Nein, ich denke, dieses Projekt sollte sich darauf konzentrieren, die beste Methode zur Erstellung nativer Windows-Software für Entwickler anzubieten, die Windows-Software erstellen möchten / müssen. Überlassen Sie die Lösung des Cross-Plattform-Zeugs den Electron/Typescript-Teams.

Es gibt hier ein paar Kommentare zur plattformübergreifenden Nutzung, und ich bin mir nicht so sicher, ob WinUI plattformübergreifend sein muss, um erfolgreich zu sein. Auf Mac oder Linux würde es sowieso nicht gut funktionieren, da es so unterschiedlich ist, dass es sich auf keiner dieser Plattformen nativ anfühlt. Dieses Projekt gehört einem Team, das über umfassende Kenntnisse über die Funktionsweise von Windows-Interna verfügt.
Außerdem ... Fluent auf dem Mac würde sich klobig anfühlen, schauen Sie sich nur iTunes an, Apple musste sein gesamtes UI-System auf Windows portieren, und es fühlt sich definitiv fehl am Platz an. Das Rendering von Schriftarten ist anders, die Animationskurven und Schatten und die Farbauswahl fühlen sich in Win10 einfach so fehl am Platz an. Ich meine, es ist sicher gut und verwendbar, aber ich bevorzuge Spotify, das nicht versucht, eine Desktop-Benutzeroberfläche zu emulieren und nur einen Webbrowser unter der Haube verwendet. Auf einem Mac würde das Ansehen des Enthüllungsscheinwerfers mit quadratischen Komponenten in einem Desktop voller abgerundeter Ecken und ohne Enthüllungseffekt so hart kollidieren.
Nein, ich denke, dieses Projekt sollte sich darauf konzentrieren, die beste Methode zur Erstellung nativer Windows-Software für Entwickler anzubieten, die Windows-Software erstellen möchten / müssen. Überlassen Sie die Lösung des Cross-Plattform-Zeugs den Electron/Typescript-Teams.

Ich glaube nicht, dass irgendjemand wirklich ein vollständiges Fluent-Design auf anderen Plattformen wünscht, sondern einfach nur in der Lage sein soll, den gemeinsamen Code zwischen den Plattformen zu maximieren.

Dies wurde bereits vom Microsoft Design-Team angesprochen. Auf der Fluent-Website heißt es ausdrücklich: "Entwerfen und erstellen Sie benutzerdefinierte Apps, die nativ iOS sind, während sie immer noch einzigartig Fluent sind". Die Fluent-Dokumentation zeigt, dass native Steuerelemente verwendet werden sollten.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

Was vermieden werden sollte, ist, für jede Plattform völlig separate Benutzeroberflächen entwerfen und warten zu müssen. Das bedeutet nicht, dass es auf der Oberfläche identisch aussehen muss, sondern ein gemeinsames Layout aufweisen sollte und UI-Designer in der Lage sein sollten, so viel wie möglich wiederzuverwenden. Das eigentliche Styling muss (und sollte) nicht dem Windows 10-System-Design entsprechen.

Im Wesentlichen wird eine einfache Möglichkeit gesucht, Windows-Apps auf anderen Plattformen zum Laufen zu bringen, ohne die gesamte Benutzeroberfläche neu erstellen zu müssen – nicht um Fluent-Design auf andere Plattformen zu bringen. Das würde es den Leuten ermöglichen, zuerst für Windows zu schreiben und ihre App dann ohne viel Arbeit auf andere Plattformen zu bringen.

@KyleNanakdewa Nun, wenn sie Open

Ich denke, dieses Projekt sollte sich darauf konzentrieren, die beste Methode zur Erstellung nativer Windows-Software anzubieten

Dieses Argument könnte überzeugend sein, wenn Microsoft nicht bereits über ein vorhandenes plattformübergreifendes XAML-Toolkit verfügt, das zufällig einen ganz anderen XAML-Dialekt als WinUI bietet.

Außerdem gibt es PWAs, wenn Sie in diese Web-HTML- und Javascript-Welt investiert sind.

Ja... "diese Welt", die schnell alles ersetzt, was wir über native OS/Store/Hosted-Entwicklung wissen. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Stellen Sie sich vor, dass "diese Welt" auf _allen_ modernen Geräten mit einem HTML5-Renderer existiert:

• Apple mit 1,4 Milliarden
• Droide mit 2,5 Milliarden
• Windows 10 mit 800 Millionen

Sie werden feststellen, dass Windows jetzt den kleinsten Marktanteil hat, was bedeutet, dass jedes Angebot, das speziell auf diese Plattform ausgerichtet ist, auch den kleinsten Markt erreicht. Dadurch wird nur die maximale potenzielle Marktreichweite einer Anwendung verringert, was wiederum die maximale potenzielle Umsatzobergrenze senkt.

Vergleichen Sie dies mit Flutter, das mit _einer_ Codebasis _alle_ der oben genannten Marktplätze erreicht, zusammen mit dem Web , das sich wie erwähnt aus allen dreien zusammensetzt – wodurch die Marktreichweite und potenzielle Einnahmen für Anwendungsentwickler maximiert und gleichzeitig die notwendigen Baukosten gesenkt werden Anträge dazu.

Obwohl ich ein großer Fan der Bemühungen hier bin, Open Source zu öffnen, zusammenzuarbeiten und Community-Feedback einzuholen, habe ich noch nichts von diesen Diskussionen (die mir auch Spaß machen 😁) gesehen, die mir mit Zuversicht signalisieren, dass die Bemühungen hier sein werden konkurrenzfähig – und daher _profitabel_ – im Vergleich zu Leuten wie Flutter (welches übrigens auch auf PWAs ausgerichtet ist ).

Die Diagrammsteuerung ist in jedem datengesteuerten modernen Desktop-Erlebnis in der bald offiziellen NET CORE 3 (September 2019) und schließlich. NET 5 (November 2020)

Ich sehe das bereitgestellte Open-Source-Steuerelement von Networkview als einen effektiven Anwendungsfall für die Arbeit mit Xaml zum Portieren von WPF auf das Win-UI-Steuerelement. Diese portierte Win-Benutzeroberfläche wird anderen als gute Gilde dienen, um andere etwas komplexere WPF-Steuerelemente auf die Win-Benutzeroberfläche zu portieren.

Wir sehen einen 2-in-1-Anwendungsfall, bei dem unsere App den Tablet-Modus in zukünftigen Windows Core-Betriebssystemen unterstützen muss. Wir vermuten, dass Winform in. NET Core 3 nicht helfen wird.

Wenn Sie der Meinung sind, dass andere neue Funktionen wie eine bessere F#-Unterstützung oder neue Markup-Funktionen wichtig sind, öffnen Sie bitte

Scheint, dass @migueldeicaza die Sache selbst in die Hand nimmt: https://github.com/microsoft/microsoft-ui-xaml/pull/736

Ich möchte die Gedanken von @eklipse2k8 plattformübergreifend CreateWindowExW !) und es muss eine Demonstration dessen sein, was Sie unter Windows tun können. WinUI auf macOS oder Android würde immer eine Erfahrung liefern, die niemals mit der nativen Erfahrung mithalten könnte. Wir schreiben plattformübergreifende Anwendungen und schreiben native Benutzeroberflächen auf jeder Plattform. Auf diese Weise erhalten die Kunden die beste Erfahrung auf der Plattform ihrer Wahl. Wenn die Leute eine plattformübergreifende Lösung wünschen, ist das in Ordnung, sie sollten zu diesem Zweck nach einer anderen Bibliothek suchen - vielleicht einer, die WinUI auf der Windows-Plattform umschließt.

Und in Bezug auf PWA stellen diese nicht die volle Nutzung des Windows-UI-Systems dar. Die Empfehlung, sich auf "Single Window Applications" zu konzentrieren, würde jede professionelle Software (außer Spiele) sofort ausschließen. Lösungen für PWA und Cross-Platform gibt es bereits – wir brauchen keine weitere.

Obligatorische XKCD:
https://xkcd.com/927/

@MarkIngramUK Ich denke, bei Cross Platform geht es mehr darum, in .NET und XAML zu codieren, um die Benutzeroberfläche zu deklarieren - und dann diese App auf Android, iOS, macOS, Linux ausführen zu lassen?! - ohne den Code dahinter ändern oder XAML aufgeben zu müssen.

Wenn es nun XAML-Renderer für diese anderen Plattformen gäbe - wie sie XAML interpretieren könnten, könnte dies wie Xamarin Forms sein, das an native UI-Plattformen übergibt - oder einfach nur in den Grafikkartenpuffer zeichnen und die Pixel auf dem Bildschirm zeichnen - unter Beibehaltung der meisten der gleiche Steuerelemente.

WinUI 3.0 sollte ein auf Windows fokussiertes Projekt bleiben, um die verschiedenen APIs und ABIs mit einer modernen XAML-basierten UI-Plattform zu vereinen. Das bedeutet jedoch nicht, dass Xamarin oder Einzelpersonen nicht den Renderingcode verwenden und Versionen für andere Plattformen erstellen können.

Alles, was wirklich (auf einem hohen Denkniveau) erforderlich wäre, wäre sicherzustellen, dass der Code, der XAML auf dem Bildschirm in Windows rendert, enthalten ist, damit andere Renderer für plattformübergreifende Szenarien einspringen könnten.

WinRT/UWP/XAML wird einige Refactorings benötigen, um sie aus dem Windows 10-Betriebssystem herauszulösen. Ob Cross-Plattform Realität wird oder nicht.

@MarkIngramUK Ich stimme @mdtauk zu

Es sollte keinen Grund geben, warum wir xaml nicht verwenden können, um UI-Komponenten in anderen Bibliotheken einschließlich React zu beschreiben. Wenn Sie sich ein Projekt wie http://www.cshtml5.com ansehen, verwenden sie xaml, das in html konvertiert wird.
Ich glaube auch nicht, dass irgendjemand darauf anspielt, dass das Endziel darin besteht, dass die Benutzeroberfläche auf anderen Plattformen gleich aussieht, aber was ich persönlich möchte, ist etwas auf der Benutzeroberfläche, mit dem ich meine bestehende Investition in zB UWP nutzen kann

Der Punkt ist einfach dieser. Wenn ich einem Unternehmenskunden einen Vorschlag mache und eine tolle UWP-App präsentiere, die in jeder Hinsicht fantastisch ist. Wenn dieser Unternehmenskunde 1 Benutzer hat, der zum Beispiel ein MacBook Pro verwendet, dann habe ich sofort ein Problem, da der Unternehmenskunde lieber etwas nimmt, das überall funktioniert (kleinster Nenner => Website) als meine "native App", auch wenn sie läuft unter Windows 10.

Erreichbarkeit ist also der Schlüssel. Die Tatsache, dass MS 2019 immer noch erwartet, dass wir in „native Apps“ investieren, ohne dass eine Roadmap zur Cross-Plattform-Fähigkeit vorliegt, ist verrückt.

Jedes neue Projekt aus Unternehmenssicht folgt wahrscheinlich der oben genannten Logik für die Zugänglichkeit und daher werden alle neuen Projekte auf das Web ausgerichtet sein, und das alles, weil es keine Roadmap gibt, die plattformübergreifende Funktionen für XAML/UWP umfasst

Also spulen wir in 2-3 Jahren vor, keine neuen Investitionen von Unternehmen in UWP/win32 und Sie sitzen mit einem anderen "Silverlight", um das sich niemand kümmert.

MS kann mir sogar sagen, dass XAML morgen veraltet ist und die "neue" UI-Bibliothek beispielsweise React ist. Solange c# an diese neue Bibliothek gebunden werden kann, werde ich meine Verluste reduzieren, XAML ausgeben und diese neue plattformübergreifende UI-Bibliothek annehmen. Zumindest meine Investition hat Haltbarkeit und ist langfristig zugänglich.

Indem MS keine Klarheit über dieses spezielle Problem der plattformübergreifenden UI-Fähigkeit bietet, schafft MS Unsicherheit in Bezug auf ihren "nativen Stack", und daher werden die meisten Unternehmen lieber mit einem Holzbein durchs Feuer laufen, als das Unbekannte zu umarmen.

Und in Bezug auf PWA stellen diese nicht die vollständige Nutzung des Windows-UI-Systems dar

Fair genug, und ich stimme zu. Mein Hauptziel bei PWA bestand darin, zu zeigen, dass sein Marktanteil jeden einzelnen Markt in den Schatten stellt, da er sich aus der Gesamtheit aller Märkte zusammensetzt.

Trotzdem nehme ich an, dass ein Teil der Verwirrung hier meinerseits die Namensteilung ist, die Microsoft.* widerspiegelt, obwohl es wirklich so klingt, als ob es immer noch Windows.* (oder sogar Microsoft.Windows.* ) sein sollte. .

Lösungen für PWA und Cross-Platform gibt es bereits – wir brauchen keine weitere.

Leider ist dies bei der .NET-Entwicklung nicht der Fall, was Teil der Verwirrung und der plattformübergreifenden Angst um diese Ankündigung und die anschließende Diskussion ist.

Dadurch werden die Marktreichweite und potenzielle Einnahmen für Anwendungsentwickler maximiert und gleichzeitig die dafür notwendigen Kosten für die Erstellung von Anwendungen gesenkt.

Manchmal können Performance- und UX-Details einen großen Unterschied machen. Skype hat die Marktreichweite durch den Einsatz des Electron-Frameworks auf Kosten von Leistungseinbußen maximiert, und das Ergebnis ist eine kommerzielle Katastrophe.

In Bezug auf plattformübergreifende (xplat) Lösungen.
Xplat-Lösungen sind eine Abstraktion über mehrere native zugrunde liegende Systeme. Mein Verständnis von WinUI ist, dass es das native System für Windows sein wird.

Wenn WinUI auch xplat sein sollte, wie würde es Dinge integrieren, die für Windows einzigartig sind? Würde das sie nicht daran hindern, neue und innovative Dinge zu tun? Oder würde das bedeuten, dass es Microsoft obliegt, alles Neue oder sich von Windows unterscheidende Produkt auch auf andere Plattformen zu portieren? Was ist mit Dingen, die nicht portiert werden konnten, weil das andere zugrunde liegende Betriebssystem sie nicht unterstützen konnte – sollten sie nicht zu Windows hinzugefügt werden?

Wenn Sie etwas mit nativen Windows-Technologien erstellen, ist es vernünftig anzunehmen, dass Microsoft dies für eine gewisse Zeit unterstützt und in Zukunft einen Weg zu neueren Windows-basierten Systemen bereitstellt. (SilverLight als Ausnahme anerkennen.) Ich denke nicht, dass es an Microsoft/Windows liegt, dies einfach zu machen, wenn Sie etwas mit nativen Windows-Technologien erstellen und es dann auf einem konkurrierenden Betriebssystem ausführen möchten. Wenn Sie mit Swift eine App für das iPad erstellt haben und diese auch auf den Windows-Desktop bringen möchten, würden Sie erwarten, dass Apple die iOS-Entwicklung so einfach ändert, dass dies einfacher wird?

Wenn Sie gerne native Windows-Technologien verwenden oder bevorzugen, ist das großartig. Was Sie nicht tun können, ist die geschäftliche Entscheidung, die Sie bei der Auswahl dieser Technologien treffen, auf eine andere Person zu verschieben. Alle Technologieentscheidungen haben Konsequenzen und niemand weiß, was in einigen Jahren erforderlich sein könnte oder was Ihre Kunden verlangen. Die Forderung, dass speziell für Windows entwickelte Software auch anderswo lauffähig ist, kann den Eindruck erwecken, eine Technologieentscheidung zu vermeiden, die in Zukunft möglicherweise negative Folgen haben könnte. Aufgrund der Natur der Technologie und der Geschwindigkeit des Wandels halte ich das nicht für realistisch.

Das heißt, wenn Sie eine xplat-Lösung erstellen möchten (und es gibt viele Leute, die dies tun und Gründe dafür), weil Sie entweder jetzt oder in Zukunft auf mehrere Betriebssysteme abzielen möchten, dann ist das vernünftig und verständlich Szenario.
Dafür hat Microsoft Xamarin. Oder, wenn Sie etwas mit XAML eher wie UWP bevorzugen, gibt es Uno. (Es gibt auch viele andere Möglichkeiten.)
Wenn Sie, wie ich, eine bessere native Unterstützung für das Erstellen von Windows-Apps in Xamarin sehen möchten, ist es meiner Meinung nach nicht die Antwort, dass WinUI versucht, mehrere Dinge zu tun.

Bei WinUI geht es um mehr als nur XAML und spezifische Steuerelemente. Es enthält Details zur Integration dieser Steuerelemente und der mit ihnen erstellten Apps in das zugrunde liegende Betriebssystem.
Wenn sich die WinUI-Planung darauf konzentriert, die Windows-Entwicklung unter Windows so gut wie möglich zu gestalten, dann ist dies ein guter Grund für Innovation und guten zukünftigen Support. Es erhöht wahrscheinlich auch die Wahrscheinlichkeit, dass die Leute Windows weiterhin verwenden möchten, und daher wird es wichtig, dass es eine solide Unterstützung durch mehrere xplat-Lösungen bietet.

In Bezug auf plattformübergreifende (xplat) Lösungen.
Xplat-Lösungen sind eine Abstraktion über mehrere native zugrunde liegende Systeme. Mein Verständnis von WinUI ist, dass es das native System für Windows sein wird.

Tut mir leid, aber so geht es mir nicht...

Schauen Sie sich Flutter an... Es hat eine Kern-Engine, die alles auf jeder unterstützten Plattform rendern kann.

Darüber hinaus verfügt es über Komponenten, die vollständig auf Dart mit der von der Engine verwalteten Ebene implementiert sind und die (Zeichnen/Rendern) in Pixeltreue die Plattform und Designsprache darstellen, die Sie verwenden möchten, zum Beispiel Material.io und Apples Cupertino.

Das wäre also IMHO der beste Ansatz, um etwas plattformübergreifend zu machen und gleichzeitig die zugrunde liegenden Plattformfähigkeiten zu repräsentieren.

Ich denke, es ist nicht vernünftig anzunehmen, dass Microsoft/Windows es einfach macht, wenn Sie etwas mit nativen Windows-Technologien erstellen und es dann auf einem konkurrierenden Betriebssystem ausführen möchten

Richtig ... Ich denke, der Punkt, den andere hier machen, ist, dass dies heutzutage ein bisschen rückständig / taub erscheint, insbesondere im Zusammenhang mit dem Starten einer neuen Anwendung. Warum sollte jemand eine native Windows-Anwendung erstellen, wenn diese nur einen kleinen Prozentsatz des Marktes erreicht? Das ist kein guter Kapitaleinsatz.

Wenn es darum geht, ältere Windows-Anwendungen zu pflegen oder speziell eine Windows-Anwendung zu erstellen, dann bin ich damit einverstanden und es macht Sinn. Da es jedoch anscheinend bahnbrechende Veränderungen und weitere Investitionen zu geben scheint, muss das Wertversprechen dieser Vorgehensweise gegenüber der Verwendung von Flutter noch erklärt werden.

Genau das sage ich...

Zum Beispiel kommen die Flatter Embedder für Desktop sowohl auf Win10 (WPF und UWP) als auch auf OSX.

Sie werden zu 100 % von der Flatter-Laufzeit verwaltet, verwenden jedoch (zum Beispiel) nur WPF/UWP, um die Fensterverwaltung und den Graphics Zeiger zu erhalten. Den Rest erledigt der Motor...

Wir haben die Flatter-Engine selbst auf ein eingebettetes ARM-Gerät portiert und ich muss sagen, es war eine großartige Erfahrung. Wieso den? Weil es geboren wurde, portabel zu sein und überall zu laufen, indem es dem "Embedder" überlassen wird, plattformspezifische Implementierungsdetails von Primitiven wie GPU, Software-Rendering, Eingabeverwaltung usw.

Deshalb sage ich, dass WinUI mittels UWP: The empire strikes back auf Dauer nicht funktionieren wird.

MSFT muss etwas plattformübergreifend, offen und portabel sein. Genau wie sie es mit .Net Core, mit Blazor usw. getan haben... Reinvent UWP/XAML wird nirgendwohin führen.

Ich glaube, XAML hat ein gutes Potenzial, wenn es richtig in einem Sinne verwendet wird, in dem es verwendet wird, um die Benutzeroberfläche zu "beschreiben" (oder zu deklarieren, wie manche sagen). Die "Engine" erstellt daraus den Renderbaum und sendet dann die Renderbefehle an die zugrunde liegende Plattform.

Wie MSFT es kürzlich mit Chromium als Kern für Edge getan hat, glaube ich, dass WinUI (oder wie auch immer es hieß) Skia nutzen könnte, da es Backends für GL, DX, Vulkan, Software Rendering, FB usw dass Sie ein RIESIGES Potenzial haben, später andere Plattformen hinzuzufügen ...

@galversribeiro ,

Schauen Sie sich Flutter an... Es hat eine Kern-Engine, die alles auf jeder unterstützten Plattform rendern kann.

Darüber hinaus verfügt es über Komponenten, die vollständig auf Dart mit der von der Engine verwalteten Ebene implementiert sind und die (Zeichnen/Rendern) in Pixeltreue die Plattform und Designsprache darstellen, die Sie verwenden möchten, zum Beispiel Material.io und Apples Cupertino.

Großartig, sobald Apple ein Update für macOS veröffentlicht und die Benutzeroberfläche aktualisiert wird (vielleicht ändert sich der Radius der Schaltflächen oder die Hintergrundverläufe usw.), wird Ihre Flutter-Anwendung nicht aktualisiert und sieht weiterhin wie das vorherige Betriebssystem aus - im Gegensatz zu einem nativen Kontrolle, die die Vorteile kostenlos erhalten würde.

@MarkIngramUK , das ist die Arbeit des Teams, um Updates zu unterstützen.

Genauso wie das Xamarin-Team Updates ab Tag 0+1 bereitstellt, könnte dieses Team dasselbe tun. Das Google-Team macht das auch...

Durch die Verwendung des "nativen" Steuerelements sind Sie wieder in der Xamarin-Welt, wo Sie nur Wrapper (auch bekannt als Renders) ...

Wir diskutieren nicht über C#-Bindungen an native Steuerelemente (wie Xamarin) ... Wir sprechen über ein vollständiges UI-Framework wie Sie es mit Flutter tun ...

Für die Aufzeichnung verwendet niemand das "Standard"-Theme für irgendeine Plattform. Sie alle erstellen ihre einzigartige UX zusätzlich zu den Designsprachen jeder Plattform.

Wenn Sie so besorgt sind, immer wie die native Komponente aussehen zu müssen, wird Ihre App wahrscheinlich nie ein gutes Publikum haben, wie es aussehen würde ... Meh ...

Ich glaube, wir reden hier von zwei verschiedenen Projekten. WinUI muss der Win32-Ersatz sein. Die Leute fragen nach einer plattformübergreifenden Lösung, was vernünftig ist, aber ich denke nicht, dass es dieses Projekt sein sollte.

Außerdem können Sie mit Flutter das "Theme" auf allen Plattformen verwenden. So können Sie Cupertino auf Ihrem Win10-PC ausführen. Ein GROSSES Beispiel ist Material Design. Es handelt sich um eine Designsprache, nicht um eine Reihe von Steuerelementen. Es kann überall verwendet werden ... Es kommt einfach vor, dass einige Plattformen (wie Android) über ihre nativen Steuerelemente verfügen, die es implementieren ...

@MarkIngramDE

Ich kläre nur, warum WinUI nicht nur ein Win32-Ersatz sein sollte, das ist alles.

Wenn das der Fall ist, bin ich mir ziemlich sicher, dass es in absehbarer Zeit genauso fallen wird wie UWP ...

Ich stimme zu, dass @MarkIngramUK WinUI selbst darauf ausgerichtet sein sollte, eine einheitliche Benutzeroberfläche für Windows bereitzustellen, unabhängig davon, ob Sie C#, WinRT-APIs, Win32-ABIs, C++, F#, VB oder .NET Core verwenden.

WinUI 3.0 beinhaltet das Herauslösen des gesamten Codes und das Rendern von XAML aus dem Windows-Betriebssystem und das Erstellen eines Frameworks, unabhängig vom Aktualisierungszyklus des Betriebssystems, und Open Source.

Wie es angehoben und neu verpackt wird, ist noch in der Luft. Nur die Microsoft-internen wissen, wie sie es tun werden. Um die zukünftige plattformübergreifende Unterstützung für XAML zu unterstützen, hoffe ich nur, dass einige Überlegungen angestellt werden, wie dies in Zukunft erreicht werden könnte, da sie es aus Windows herauslösen.

.NET Core ist bereits auf anderen Plattformen verfügbar. Damit ist der C#-Code dahinter bereits übertragbar. Es ist jetzt nur noch XAML und die Benutzeroberfläche und Steuerelemente, die einen Pfad zu iOS/macOS/Android/Linux (und was auch immer in Zukunft kommen mag) benötigen.

Außerhalb des Umfangs von WinUI 3.0 vielleicht, aber definitiv mit diesem Projekt und diesem Aufwand verbunden.

@jesbis @terrajobst @jevansaks

Was sind die Pläne von Microsoft, ein UI-Framework in .NET Core einzubringen, das auf Desktops, Mobilgeräten (Droid, iOS) und im Web rendert?
Die Unsicherheit darüber besteht schon sehr lange.

@weitzhandler , sie haben bereits eine Roadmap mit folgendem Absatz:

Ein natives Windows-Ziel für Web- und plattformübergreifende Frameworks
WinUI 3 ist besser für Bibliotheken und Frameworks optimiert , auf denen .
Wir planen beispielsweise, die neue leistungsstarke C++ React Native Windows-Implementierung auf WinUI 3 zu basieren.

Beachten Sie den hervorgehobenen Teil "auf bauen". Wie ich oben gesagt habe, gibt es keinen Grund, warum dies nicht zuerst Windows sein kann, während andere Bibliotheken darauf aufbauen.

OK dann...

/me keep working on FluSharp

was vernünftig ist, aber ich denke nicht, dass es dieses Projekt sein sollte.

Es ist durstig da draußen @MarkIngramUK , entschuldigen Sie unsere Prognosen. 😅

mit folgendem Absatz

Sagt nicht viel. Es zeigt nicht die klare Absicht von MS, C#- und .NET-Entwicklung xplat zu machen. Es sagt vielleicht, dass HTML JS & CSS shi{ die bessere Ausrüstung für Sie sind als C#, wenn Sie portabel sein wollen.

Im Moment ist Xamarin und Xamarin Forms Microsofts Geschichte für die Entwicklung von C# und .NET Core außerhalb von Windows.

React Native für Windows kommt für Javascript-Code und Native UI (die WinUI 3.0 XAML verwendet)

Im Moment hat Microsoft keine Pläne angekündigt, XAML von WinUI 3.0 auf andere Plattformen zu bringen.

WinUI Das Projekt versucht, die Entwicklungsframeworks Win32, WPF, MFC, UWP und .NET Core unter einem einzigen modernen XAML-Präsentationsframework zu vereinen.

Ich denke, danach sollte daran gearbeitet werden, Wege zu finden, um für WinUI 3.0 geschriebenes XAML zu rendern – auf Plattformen wie macOS, iOS, Android usw. – aber das steht bisher nicht auf der Tagesordnung.

Sobald hier die Arbeit an WinUI 3.0 beginnt, wird es Open Source sein, so dass zukünftiges plattformübergreifendes Arbeiten für die Zukunft möglich ist, wenn genügend Bedarf dafür besteht. Und vielleicht ist es nicht Microsoft, das diese plattformübergreifenden Pfade schließlich zur Verfügung stellt, sondern die Open-Source-Community.

Irgendwelche Pläne, F#, das rothaarige Stiefkind von .NET, zu einem erstklassigen Bürger zu machen? Und dann fragen sich die Leute, warum die große Mehrheit der .NET-Entwickler F# nicht mit einer drei Meter hohen Stange anfassen wird.

Im Moment ist Xamarin und Xamarin Forms Microsofts Geschichte für die Entwicklung von C# und .NET Core außerhalb von Windows.

Ja, Xamarin.Forms wird auf macOS, GTK, UWP und WPF portiert, und es ist überall Materialdesign in Arbeit, was es zum de facto .NET UI Framework macht, aber es ist so langsam und fehlerhaft, dass ich mich frage, was Microsoft denkt über seine Entwickler. Schauen Sie einfach in die Themenliste! Sobald eine ernsthafte Entwicklung begonnen hat, werden Fehler links und rechts getroffen. Ich hoffe, dass wir mit WinUI endlich eine bessere Entwicklungserfahrung machen können.

Re: F#

Wenn Sie der Meinung sind, dass andere neue Funktionen wie eine bessere F#-Unterstützung oder neue Markup-Funktionen wichtig sind, öffnen Sie bitte eine neue Funktionsanfrage, damit wir sie separat verfolgen können!

Ja, es ist immer F#, die separat verfolgt und wieder ignoriert werden. Schauen Sie sich nur UWP und .NET Native an – beide hatten nicht F# im Sinn und die gesamte Community musste alles herausfinden. 🙄 Nach 4 Jahren wird F# auf .NET Native immer noch nicht unterstützt.

Für F# -Vorschläge/Fragen habe ich ein spezielles Problem erstellt:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

Bitte zögern Sie nicht, F#-Diskussionen dorthin zu leiten.

Wir ignorieren definitiv nicht das Feedback dazu - ein spezielles Problem hilft uns nur, es zu organisieren und zu verfolgen.
Das Team diskutiert, wie es in die Roadmap für 3.0 und darüber hinaus passen könnte und wird die neue Ausgabe mit allen Entwicklungen aktualisieren.

RE: Plattformübergreifende Benutzeroberfläche:

Vielen Dank an alle für die bisher angesprochenen Punkte und für die Leidenschaft für .NET und Xaml.
Ich möchte nur noch einmal sagen, dass wir uns das ganze Feedback genau anhören und unsere Gedanken und Updates im weiteren Verlauf teilen werden.

Nur um die aktuelle Roadmap und einige Punkte zu bekräftigen, die aufgekommen sind:

WinUI ist die native UI-Plattform für Windows (einschließlich nativer Apps, nicht nur .NET) und für die erste 3.0-Version konzentrieren wir uns hauptsächlich darauf, sie vom Betriebssystem unabhängig zu machen und darauf hinzuarbeiten, sie in einer schnelleren Version für die Open-Source-Entwicklung vorzubereiten Kreislauf. Wir möchten sicherstellen, dass der Umfang so machbar ist, dass wir dieses Jahr eine Vorschau herausgeben können.

Eines unserer anderen aktuellen kurzfristigen Ziele ist es, WinUI als natives Ziel für andere Plattformen zur Verwendung unter Windows zu ermöglichen: Wir arbeiten beispielsweise auch daran, react-native-windows sicherzustellen - eine leistungsstarke C++ React Native-Implementierung für Windows – verwendet WinUI und dass WinUI-Steuerelemente verwendet werden können, um native UI-Ansichten in React Native-Apps zu erstellen.

Ich werde ganz ehrlich sein. Ich habe eine native Windows-Desktop-App, die ich 2006 auf WinForms geschrieben habe und die ich heute noch online verkaufe.

Ich habe nicht vor, diese App zu WPF, UWP zu migrieren oder eine exklusive Windows-UI-Technologie zu verwenden. Es ist mir egal, wie überzeugend die Windows-Demos aussehen. Wenn ich mich jemals entscheide, wieder an dieser App zu arbeiten, wird die nächste Hauptversion eine Art plattformübergreifende Implementierung sein, die auf MacOS, Linux und Windows ausgeführt werden kann.

Derzeit würde das wahrscheinlich wie Blazor + .NET Core + Electron aussehen.

Ich denke, @Mike-EEE macht einige großartige Punkte. Die UX/Plattform, die es mir ermöglicht, meine C#-Kenntnisse zu nutzen, um die größtmögliche Anzahl von Zielgruppen zu erreichen, ist die wahrscheinlichste Technologie, die ich wählen werde.

Microsoft sollte sich darauf konzentrieren, Entwicklern zu ermöglichen, ihre vorhandenen Fähigkeiten zu nutzen, um mit ihren Apps ein größeres Publikum zu erreichen. Ich denke, das ist eine Gewinnstrategie und wird Microsoft im Spiel halten.

An der Wand steht, dass Betriebssystemsoftware immer mehr zu einer Ware wird. Das heißt, die Leute können jedes beliebige Betriebssystem auswählen und die Apps erhalten, die sie verwenden möchten. Ich denke, dies wird im Laufe der Zeit deutlicher werden, da sich die Softwareanbieter der Welt weiterhin auf plattformübergreifende Lösungen konzentrieren.

In der Ökonomie ist eine Ware ein wirtschaftliches Gut oder eine wirtschaftliche Dienstleistung mit vollständiger oder erheblicher Fungibilität: Das heißt, der Markt behandelt Exemplare der Ware als gleichwertig oder nahezu gleichwertig, unabhängig davon, wer sie hergestellt hat. https://en.wikipedia.org/wiki/Ware

Microsoft muss sich entscheiden, will es Teil der Entwickler-Tooling-Geschichte sein? Oder investiert Microsoft Millionen von Dollar in einen neuen reinen Windows-UX-Stack, der am Ende auf den Friedhof der UX-Stacks stößt, die immer weniger Leute verwenden?

Dieses Projekt gehört einem Team, das über umfassende Kenntnisse über die Funktionsweise von Windows-Interna verfügt.

Es ist mit Sicherheit eine schwierige Position. Aber die Zeiten haben sich geändert. Die Welt von heute ist ganz anders als die Welt von 1995. Aus meiner Sicht gibt es zwei Möglichkeiten:

Sie könnten mehr Leute einstellen, um dieses Wissen über Windows hinaus zu erweitern.

Oder verwenden Sie das Wissen dieses Teams, um UX-Installationen in Windows zu erstellen, die die Kompatibilität für plattformübergreifende UI-Anwendungsframeworks verbessern, damit sie unter Windows besser ausgeführt werden.

Genau wie WSL für die Ausführung von Linux unter Windows.

• Nutzen Sie das Wissen des Teams, um GTK 200x schneller laufen zu lassen.
• Nutzen Sie das Wissen des Teams, um QT-Apps 200-mal schneller laufen zu lassen.
• Nutzen Sie das Wissen des Teams, damit Electron-Apps schneller als jedes andere Betriebssystem rendern.

Es gibt eine Menge Arbeit, die getan werden kann, um die Geschichte der plattformübergreifenden UX-Kompatibilität von Windows zu verbessern. Aber in einen ganz neuen UX-Stack zu investieren und zu hoffen, dass wir alle wechseln (ohne plattformübergreifende Geschichte) ist eine ziemlich große Wette. Sie müssen diese Angewohnheit brechen, indem Sie neue UX-Frameworks nur für Windows erstellen.

Nur meine zwei Cent. :Geldtasche:

:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (Offizieller Film) ft. Billy Ray Cyrus

@bchavez

Sie müssen diese Angewohnheit brechen, indem Sie neue UX-Frameworks nur für Windows erstellen.

-- Nicht nur das. Sogar die Angewohnheit, die eigene interne XAML-Portabilität von Windows zu brechen. WPF, Siliverlight, UWP alles auf eigene Faust... So etwas verdrängt immer mehr Leute von Windows-Entwicklungstools im Allgemeinen, die ich persönlich auch in Zukunft gerne weiter verwenden möchte. Je mehr Push-Back von Windows-Entwicklungstools bedeutet, dass C# immer weniger relevant ist und für mich ist es das, was mich interessiert, wenn ich dazu komme.

RE: Plattformübergreifende Benutzeroberfläche:

... WinUI ist die native UI-Plattform für Windows (_ einschließlich nativer Apps _, nicht nur .NET) und für die erste 3.0-Version konzentrieren wir uns hauptsächlich darauf, sie vom Betriebssystem unabhängig zu machen und auf Open Source vorzubereiten Entwicklung in einem schnelleren Release-Zyklus. Wir möchten sicherstellen, dass der Umfang so machbar ist, dass wir dieses Jahr eine Vorschau herausgeben können.

Fügen Sie ein +1 hinzu, um das visuelle Erscheinungsbild von WinForms-, MFC- und WPF-Steuerelementen zu aktualisieren, die mit WinUI 3.0 ausgeführt werden, um den Stilen von Fluent/FabricWeb-Steuerelementen besser zu entsprechen.

Sicherlich unterschiedliche Steuerelementgrößen (alles andere als WinRT-XAML sollte wahrscheinlich seine Metriken an die Compact-Version der UWP-Steuerelemente anpassen), aber ein kohärentes und konsistentes, poliertes Aussehen.

Fügen Sie WinForms eine WinUI 3.0-Abhängigkeit hinzu, und die Steuerelemente ändern sich.

WinUI 3.0 WPF-Apps erkennen und verwenden Fluent.Light.xaml- oder Fluent.Dark.xaml-Steuerelementdesigns.

@weitzhandler Ich verstehe dein Gefühl. Ich hoffe, dass ich nie Javascript und ähnliches berühren muss, um diese plattformübergreifende GUI zu erstellen. Ich mag es nicht einmal daran zu denken, ein Projekt mit Elektron, Angular, Dart, Flattern zu starten.
Ich hoffe, wir können mit .NET 5 bald eine Lösung haben, die den universellen XAML-Traum bringt. Microsoft XAML kann WIN, Web, Mobile, Desktop und IoT.
Silverlight hat es für viele Anwendungsfälle fast geschafft .

Sie müssen diese Angewohnheit brechen, indem Sie neue UX-Frameworks nur für Windows erstellen.

WinUI 3.0 wird nie veröffentlicht, wenn wir auf (auf allen Plattformen zwangsläufig kompromittierte) plattformübergreifende Unterstützung warten müssen. WinUI sollte das UI-Framework der niedrigsten Ebene unter Windows sein, und wenn Sie plattformübergreifende Fähigkeiten wünschen, bauen Sie darauf auf (oder verwenden Sie React Native, Xamarin usw.).

Sie müssen diese Angewohnheit brechen, indem Sie neue UX-Frameworks nur für Windows erstellen.

Ich möchte nur klarstellen, dass wir nicht versuchen, mit WinUI 3.0 ein neues UI-Framework zu erstellen.

Unser ursprüngliches Ziel ist:

• Entfernen Sie Hindernisse für die Verwendung der vorhandenen modernen nativen Technologien (Windows 10 Xaml-Benutzeroberfläche und Compositor), indem Sie sie vom Betriebssystem entkoppeln und ihnen ermöglichen, über vorhandene App-Modelle (Win32 und UWP), Sprachen, andere Frameworks (über Inseln) und Windows-Versionen hinweg zu arbeiten

• Aktualisieren Sie unseren Engineering-Prozess, um Open Source zu sein

WinUI 3.0 wird nie veröffentlicht, wenn wir auf (auf allen Plattformen zwangsläufig kompromittierte) plattformübergreifende Unterstützung warten müssen.

Mann... Wenn Sie das wirklich glauben, meinen Sie, dass erfolgreiche Frameworks wie Flutter nicht funktionieren...

Ich mag Dart auch nicht, aber sie haben ein ziemlich absteigendes Produkt herausgebracht, das sich weiterentwickelt und WIRKLICH schnell Traktion bekommt.

Ich bin frustriert, dass WinUI nur ein Windows-Ding wird ...

.Net benötigt ein UI-Framework, das der Großartigkeit der plattformübergreifenden .Net Core-Funktionen entspricht, genau wie wir es gerade für das Web mit Blazor (client- und serverseitig) erhalten haben.

Ich denke, im Moment müssen wir uns noch auf gemeinschaftsgetriebene Bemühungen verlassen.

Ich verstehe, was Ihr Team zu tun versucht @jesbis... Es ist nur so, dass viele von uns es satt haben, die Benutzeroberfläche auf .Net/C++/UWP/MFC/Windows als _silo_'ed Ding zu sehen, das nur unter Windows läuft, während die ganze Welt (ofc außer Apple und OSX) gehen den umgekehrten Weg und bieten Entwicklern immer bessere plattformübergreifende Lösungen. Wie Sie erwähnt haben, das React und Rect-Native (für die Aufzeichnung mag ich beides nicht, ich erwähne nur, dass sie sich weiterentwickeln).

Was wir jetzt also haben, sind nur von der Community betriebene Initiativen wie Avalonia oder sogar Uno und andere Frameworks (wie FluSharp, an denen ich wie erwähnt arbeite), die sich aus offensichtlichen Gründen SEHR LANGSAM entwickeln ...

Mein Vorschlag ist, das XAML und den Compositor nicht einfach aus der Windows-Codebasis zu heben und es zu einem Nur-Windows zu machen, um es zu erhalten und geeignete Abstraktionen vorzunehmen, damit es auf mehreren Plattformen funktioniert. Genau wie bei .Net Core, das ursprünglich nur für Windows war, aber durch die von der Community angetriebenen Bemühungen funktionierte es unter Linux, OSX und sogar auf ARM-Geräten ziemlich schnell ...

(ein unweigerlich auf allen Plattformen kompromittiert) plattformübergreifende Unterstützung

Ich glaube wirklich nicht, dass dies ein Problem sein wird, da plattformübergreifendes Design ein Schlüsselaspekt der XAML-Benutzeroberfläche von UWP und des fließenden Designs ist und war. Es gibt definitiv einige Steuerelemente, bei denen sich das visuelle Design zwischen den Windows-Versionen unterscheidet - dies wird nahtlos gehandhabt, Sie erhalten eine native Benutzeroberfläche, die dem Betriebssystem des Geräts entspricht.

Zum Beispiel sind Acrylic und Reveal in Steuerelemente integriert, Akzentfarben in Pivots und NavigationViews - diese Dinge erscheinen nicht im Creator's Update, aber auf FCU und neuer. Null Änderungen erforderlich.

Offensichtlich ist das Rendern der Benutzeroberfläche auf einem völlig anderen Betriebssystem hinter den Kulissen viel komplexer, aber in Bezug auf das tatsächliche Design der Benutzeroberfläche müssen meiner Meinung nach keine neuen Überlegungen angestellt werden, als jemals zuvor mit UWP und WinUI.

Ich denke, die große Sorge ist, was die langfristigen Pläne wirklich sind. Basierend auf den Antworten von @jesbis scheint es, als ob sie sich

So viel ist verständlich, der Umfang eines solchen Projekts ist riesig. Ich könnte absolut verstehen, wenn es nicht der kurzfristige Plan wäre, sondern der Endspielplan. Transparenz ist hier wichtig, klar ist, dass keiner eine Plattform ohne klare Zukunft unterstützen möchte.

Es ist klar, dass MS als Ganzes auf Cross-Plattform ausgerichtet ist – wir sehen dies bei Fluent Design (das jetzt Beispiele für iOS, Android und Web hat), einer großen Anzahl von MS-gemachten Apps auf anderen Plattformen – also geteilte Benutzeroberfläche ist wirklich nur ein großes fehlendes Glied. Und deshalb wäre es so enttäuschend, es nicht zu sehen - ich denke, viele Leute mögen die Idee einer von MS erstellten universellen App-Plattform, aber es macht keinen Sinn zu unterstützen, wenn wir keine haben Komplettlösung dafür.

Der Punkt ist... Wie bei material.io und Cupertino könnten wir (und ich bin nicht überrascht, wenn Google das nicht schon tut!) das "Thema" auf Flattern für flüssige Designsprache haben...

Und das ist mein Punkt, als ich sagte, dass ein wirklich plattformübergreifendes UI-Framework sich darum nicht kümmern würde und einfach funktionieren würde, wie es Flutter tut ... Ich sehe nicht, wo wir da Kompromisse haben ...

@weitzhandler Ich mag HTML auch nicht für native Apps. Sonst würde ich Electron mit React verwenden 😄

Ich bin hier einfach nicht leidenschaftlich, sondern nur rational.

Ich freue mich sehr auf die WinUI 3.0 und würde sie sofort für ein neues C++/WinRT Windows-Desktopprojekt verwenden. Und ich hoffe, dass die nächste Hauptversion nach 3.0 eine portable Runtime zum Hosten der WinUI-Anwendungen (wie die Flutter-Runtime) einführen wird. Für eine beträchtliche Anzahl von LOB-Anwendungen und Photoshop-ähnlichen Anwendungen kann die GUI auf jeder Plattform gleich sein, aber der Schlüssel liegt in der Leistung und der Wiederverwendung des Quellcodes. Und ich finde auch, dass das xlang-Projekt eine tolle Idee ist und für die Zukunft einige gute Neuigkeiten verspricht.

Ich schlage vor, dass sich die Benutzer hier Zeit nehmen, um Scott Hunter nach BUILD 2019 zuzuhören, wie Win UI, Xamarin Form, UNO und Web Assembly zusammenkommen könnten.

.NET Core 3 und darüber hinaus mit Scott Hunter @.NET Rock

Sowohl Xamarin Forms (XAML) als auch UNO (XAML) wurden mit der Vision für Cross-Plattform erstellt. Im Fall von UNO (zusätzlich zu iOS, Android, XAML für Web über Web Assembly).

UWP wurde ohne Vision über das Microsoft-Ökosystem hinaus erstellt, z. B. Web, Android, iOS. All die beeindruckenden Bemühungen des Fluent-Designs werden aufgrund der langsamen Einführung von UWP . nur wenig in Anspruch genommen

Wie @Mike-EE betonte, haben Droid und iOS 2 ~ und 1,5 ~ Milliarden, während Win10 0,9 Milliarden hat. Die meisten Entwickler zögern immer noch, von WinForm und WPF zu UWP zu wechseln.

WARUM? Die UWP-Steuerelemente von kommerziellen und Microsoft sind UNVOLLSTÄNDIG !!!!! im Vergleich zu denen in WinForm und WPF. Es gibt keine Bemühungen von Microsoft, diesen Übergang zu unterstützen. XAML Island wird dies nicht angehen, SOLANGE MICROSOFT BLIND SPOT als das Fehlen hat, das Entwickler MÜSSEN, um von winForm und WPF auf UWP umzusteigen.

Mit diesen fehlenden UWP-Steuerelementen werden jetzt erhebliche Anstrengungen unternommen, um die Win-Benutzeroberfläche in React Native for Web zu integrieren. ?????? Wir brauchen diese fehlenden Win-UI-Steuerelemente für UWP, damit wir uns für den Übergang von WinForm und WPF zu UWP einsetzen können .

Ein solches Steuerelement ist die Diagrammsteuerung . Alle datenintensiven Geschäftsanwendungen benötigen Diagrammsteuerung für UWP.

==> Ich verstehe die Notwendigkeit, die UWP-Benutzeroberfläche zu entkoppeln. Dies ist nur sinnvoll, um das Fluent Design Branding auf andere Plattformen wie iOS, Android, Web zu verbreiten.
==> Bitte konzentrieren Sie sich auf eine bessere 3D-Modellsteuerung und Diagrammsteuerung (beide 2D/3D)

Es macht nur Sinn, zu bleiben und auf NET5 zu warten, wenn ALLE BCL aus sind (mono wird mit dem nativen von Windows zusammengeführt, für Webassembly etc), denn ICH SEHE DIE ZUKUNFT DES kreativen 3D UI HOLOLENS.

Dazu benötigen wir 2d/3D-Diagrammsteuerung für UWP und 3D-Modellsteuerung , die nicht nur das Modell anzeigen soll, sondern dem Entwickler den Zugriff auf die Skelett- / Vertex-Animation ermöglicht.

@jesbis Ich fordere Sie auf, mehr Leute in diese USP (einzigartige Verkaufsargumente) von Win UI für UWP zu bringen.

@weitzhandler

Dieses Problem wurde erstellt, um die WinUI 3.0-Roadmap zu diskutieren.

@jesbis hat eine klärende Aussage gemacht :

WinUI ist die native UI-Plattform für Windows (einschließlich nativer Apps, nicht nur .NET) und für die erste 3.0-Version konzentrieren wir uns hauptsächlich darauf, sie vom Betriebssystem unabhängig zu machen und darauf hinzuarbeiten, sie in einer schnelleren Version für die Open-Source-Entwicklung vorzubereiten Kreislauf. Wir möchten sicherstellen, dass der Umfang so machbar ist, dass wir dieses Jahr eine Vorschau herausgeben können.

Ihre ersten beiden Kommentare waren themenbezogen.

Die folgenden sechs waren eine Kombination aus unproduktiv und abwertend, und Sie sind kurz davor, den Microsoft Open Source-Verhaltenskodex zu brechen.

Dies sollte ein produktives, professionelles Gespräch mit Microsoft bleiben.

// Ich verfolge dieses Gespräch nicht, um den ganzen Tag zuzuhören, wie sich ein Typ auslässt.

Ich denke, es gibt hier einige großartige Kommentare, obwohl es so aussieht, als ob es zwei separate Diskussionen geben könnte. Ich mache es kurz, weil das meiste schon gesagt wurde.

Plattform- und webübergreifend

.NET Core ist großartig. Wir können endlich jede Plattform und jeden Berührungspunkt mit großartigen Tools und einer großartigen Sprache ansprechen.
Das einzige, was fehlt, ist ein UI-Stack mit Ausnahme von Blazor (HTML / CSS ist jedoch scheiße). Für eine maximale Vergleichbarkeit wäre es großartig, ein Framework zu haben, das es Desktop-Entwicklern ermöglicht, mit den gleichen Fähigkeiten, Tools und Sprache (Xaml und C#) ins Web und darüber hinaus zu migrieren. Tbh, Silverlight hat dort eine tolle Sache gemacht - es hat einfach funktioniert). Ich bin mir nicht sicher, ob WinUI dieses Framework sein muss, aber bitte sprechen Sie das Problem intern an. Grundsätzlich wäre Flutter für .NET-Entwickler und das Targeting des Webs der größte Vorteil.

Ich bin mir nicht sicher, ob Xamarin diese Plattform sein könnte, aber wenn ja, stellen Sie sicher, dass Xaml so weit wie möglich auf WinUI und Xamarin ausgerichtet ist.

WinUI

Dies muss passieren. Es sollte einen gemeinsamen Xaml-Stack geben, um die bestmöglichen Erfahrungen auf der Windows-Plattform zu erzielen. Idealerweise sollten die fehlenden Lücken von WPF in Bezug auf Steuerung und Funktionalität geschlossen werden.

HoloLens und darüber hinaus

Mit Lite und neuen super aufregenden Formfaktoren wie HoloLens könnte man argumentieren, dass UWP in Bezug auf die Benutzeroberfläche noch nicht bereit dafür ist. Ja, wir können sie auf einer HoloLens ausführen, was nett ist, aber ich würde gerne eine Möglichkeit sehen, Apps wirklich für 3D zu optimieren, ohne auf volle Unity zu gehen.

WinUI ist Xamarin weit voraus. Aber Microsoft Team pusht Xamarin 4.0 einfach raus...
Ich persönlich mag Xamarin mehr, da es die niedrigste Stückelung für Cross Platform ist, es wird in Zukunft eine steigende Anzahl von nativen Apps für SaaS geben.

Abgesehen von Xamarin gibt es eine Alternative.
1) Warum nicht die UNO-Plattform nutzen und das Web-Rendering mit SkiaSharp erstellen?
2) @zezba9000 Sie benötigen ein agnostisches Rendering-Backend, wie es Spiel-Engines zu Beginn verwenden. Eigentlich erkenne ich es irgendwie an....

Vielleicht pusht Microsoft WinUI mehr, weil im Gegensatz zu anderen plattformübergreifenden Lösungen kein Open-Source-Code-Trace vorhanden ist: Xamarin, UNO, könnte UNIX-Bibliotheken haben ...

Wie auch immer, möge die Macht mit dir sein.
PS: Github Sponsor sind von Microsoft, also sponsern Sie bitte einige namhafte Mac/Linux-Entwickler für den Cross Platform Fork von WPF/Winforms.

@jkoritzinsky , Auf eine Sache sollte das WinUI-Team beim Umbenennen von WinUI 3.0 achten: Wenn Sie einen der in .NET projizierten Typen umbenennen, funktionieren die Projektionen nicht (und wir planen nicht, weitere hinzuzufügen) da es kein wartbares erweiterbares System ist). Hier ist eine Liste der Typen, die wir projizieren: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Alle Änderungen an anderen Typen als diesen Typen erfordern, dass Benutzer ihre Objekte in neue Objekte umschließen, die die neuen Schnittstellen implementieren, oder ihre Daten in die neuen Typen kopieren. Insbesondere die Typen INotifyPropertyChanged und INotifyCollectionChanged sind in Bezug auf XAML-Inseln und die Bereitstellung von Downstream-Support von Interesse.

Ich stimme zu und freue mich, dass Sie dieses Thema angesprochen haben, obwohl ich hinzufügen möchte, dass diese Prognosen meiner Meinung nach ein kleines bedauerliches Übel sind. Wir projizieren nicht jede einzelne API, die wahrscheinlich sein sollte (wenn man an die System.IO-APIs denkt), also sollten wir das entweder beheben oder anders denken. Eine Sache, die mir in den Sinn kommt, ist, .NET-Typen in einem anderen Namespace keine ähnlichen, aber unterschiedlichen Typen hinzuzufügen. Stattdessen sollten wir unseren C++-Entwicklern ermöglichen, auch System.ComponentModel.INotifyDataErrorInfo zu verwenden. So haben wir es mit C++/CLI gemacht, aber dafür müsste die CLR für eine reine C++-Anwendung nicht geladen werden. Ich weiß nicht, ob das verwirrender wäre, aber es fühlt sich an, als würden wir die grundlegenden und zugrunde liegenden Unterschiede in den .NET- und WinRT-Technologien auf der API-Ebene durchsickern lassen, was die Dinge inkohärent erscheinen lässt.

@meir-pletinsky. NET ist nur ein Framework, mit dem Sie Apps mit UWP XAML erstellen können. Sie möchten, dass Entwicklern eine Textfeldvalidierung zur Verfügung steht, unabhängig davon, welches Framework sie verwenden

Das ist richtig für das Geld, wir haben C++-Entwickler, die uns wichtig sind. Obwohl ich, wie oben erwähnt, gerne keine Verwirrung in der .NET-Community stiften würde, nur um dies zu ermöglichen.

@mdtauk , nein, WinUI Desktop (früher Xaml Desktop) ermöglicht es Ihnen, Xaml direkt mit Win32 zu verwenden, ohne die Insel zu verwenden.

Ich denke, @meir-pletinsky bezog sich auf .NET/C++, es sei denn, ich vermisse etwas?

@MarkIngramUK Ich glaube, wir sprechen hier von zwei verschiedenen Projekten. WinUI muss der Win32-Ersatz sein. Die Leute fragen nach einer plattformübergreifenden Lösung, was vernünftig ist, aber ich denke nicht, dass es _dieses_ Projekt sein sollte.

Ja, ich stimme voll und ganz zu! Für mich geht es bei WinUI darum, die modernste, leistungsfähigste und rundum beste Benutzeroberfläche für Windows zu definieren. Xamarin sollte die plattformübergreifende Geschichte von Microsoft sein und sollte sich auf WinUI entwickeln.

@mdtauk

Fügen Sie ein +1 hinzu, um das visuelle Erscheinungsbild von WinForms-, MFC- und WPF-Steuerelementen zu aktualisieren, die mit WinUI 3.0 ausgeführt werden, um den Stilen von Fluent/FabricWeb-Steuerelementen besser zu entsprechen.

Sicherlich unterschiedliche Steuerelementgrößen (alles andere als WinRT-XAML sollte wahrscheinlich seine Metriken an die Compact-Version der UWP-Steuerelemente anpassen), aber ein kohärentes und konsistentes, poliertes Aussehen.

Fügen Sie WinForms eine WinUI 3.0-Abhängigkeit hinzu, und die Steuerelemente ändern sich.

WinUI 3.0 WPF-Apps erkennen und verwenden Fluent.Light.xaml- oder Fluent.Dark.xaml-Steuerelementdesigns.

Ich möchte nicht, dass MS Zeit und Ressourcen in diese Frameworks investiert, damit sie wie native Windows 10-Apps aussehen. Deshalb wird es WinUI 3.0 geben. Sie möchten Windows 10 Look & Feel in WPF/WinForms Apps? Verwenden Sie WinUI 3.0.
MS sollten ihre Ressourcen viel lieber in das Schließen vorhandener (und blockierender) Lücken zwischen UWP/WinUI und ihren Win32-Gegenstücken investieren, als ihre älteren Frameworks erneut zu besuchen. Vor allem, da WinUI _das_ Präsentationsframework für Windows werden soll...

Ich möchte um Klarstellung zu WinUI und Microsofts Absichten in Bezug auf UI/UX bitten:

1. Ersetzt WinUI ALLE der folgenden (hypothetisch?): Win32, ATL, MFC, WinForms, Silverlight (ich weiß), WPF, UWP und/oder XAML Islands? Ich bin mir bewusst, dass diese Technologien weiterhin existieren und auf unbestimmte Zeit weiterhin unterstützt werden ; Ich möchte nur klar verstehen, dass dies von Microsoft als "der Weg nach vorne" bezeichnet wird und dass wir (zum Beispiel) WinForms und WPF genauso betrachten sollten wie Win32 oder MFC.

2. Leitet WinUI von UWP ab? (Oder wie ähnlich sind sich die beiden?) Wie ähnlich (oder anders) ist WinUI im Vergleich zu UWP, XAML Islands oder WPF?

Als professioneller C#- und C++-Entwickler begann ich mit WinForms zu arbeiten und wechselte dann zu WPF und dann zurück zu WinForms, einfach weil ich UI/UX für geschäftliche Zwecke in WinForms ungefähr doppelt so schnell entwerfen konnte wie in WPF. WPF bot viel mehr Flexibilität, Leistung und sah viel besser aus – aber die XAML-Mangel, die auftrat, sobald jemand die Benutzeroberfläche über den Designer berührte, anstatt das XAML von Hand zu bearbeiten, war schrecklich. In einigen Fällen denke ich, dass WinForms (mit dem Designer) um Größenordnungen schneller war, als ein ähnliches XAML-Formular oder -Steuerelement von Hand zu erstellen.

Persönlich würde ich mich über eine Benutzeroberfläche freuen, die für alle Microsoft-Produkte verfügbar und identisch ist. Ein Framework, das von Win32 oder .NET auf ähnliche Weise genutzt werden kann, würde konsistente, modern aussehende Anwendungen für ALLE Microsoft-Entwickler bedeuten und würde auch bedeuten, dass häufige Fragen und Probleme in Sitzungen gelöst werden können, die auf eine einzelne Technologie abzielen, z. Wenn Sie eine Frage zu einem Steuerelement stellen, wäre die Antwort für einen Win32-Entwickler ODER einen .NET-Entwickler identisch (wenn nicht fast identisch). Das würde das Erlernen von "WinUI" für jeden einzelnen Entwickler nützlich machen und auch den Zugriff auf Online-Informationen (StackOverflow usw.) viel wertvoller machen, unabhängig davon, wo Sie entwickeln. Obwohl ich Xamarin nicht verwende, könnte die obige Anweisung nicht nur auf Windows-Entwickler angewendet werden, sondern auch auf Android-, iOS- usw.

Für welche Art von Anwendungen würde ich WinUI gerne verwenden?

Wenn mein Verständnis von WinUI richtig ist und es "der Weg nach vorne" ist, Win32, MFC, Forms, WPF usw. zu ersetzen, und das gleiche Framework für die native oder .NET-Entwicklung verfügbar ist, werde ich die Komposition eifrig ersetzen in _ ALLEN _ der von mir unterstützten Anwendungen. Moderne, konsistente Benutzeroberflächen, die unabhängig von Plattform oder Stack gleich funktionieren (und sich verhalten)? Wollen wir das nicht alle? Ich glaube nicht, dass sich irgendjemand daran erinnern möchte, wie man sowohl CreateWindowEx () als auch eine Message Loop ausführt, um Ereignisse in Win32 auszulösen, während Ereignisse in WinForms oder WPF auf völlig separate Weise behandelt werden. Es ist Zeit für etwas "Modernes". Ich hoffe wirklich, das ist WinUI (3.0).

Betriebssystemkompatibilität und Downlevel-Support

Ich finde es toll, dass sich WinUI auf die Entkopplung der Komposition vom Betriebssystem konzentriert, aber es gibt eine Vielzahl von Kunden, die noch nicht einmal Windows 10 verwenden. Ich weiß, es ist ein Schmerzpunkt, und wir alle wünschen uns, dass unsere Zielgruppen das Neueste wären, aber es ist ein echtes Problem, mit dem wir alle täglich konfrontiert sind. Welche Diskussion wird darüber geführt, WinUI für ältere Plattformen nach 1703 verfügbar zu machen, die meiner Meinung nach die derzeit älteste Plattform ist, die derzeit anvisiert wird?

Ist WinUI statisch verknüpfbar oder einbettbar (wie .NET Core/5) eine Option? Wir müssen auf Windows 8.1, Windows 8, Windows 7 – sogar Windows PE – abzielen. Wie können wir WinUI mit diesen Anforderungen verwenden?

@shidell :

Leitet WinUI von UWP ab? (Oder wie ähnlich sind sich die beiden?) Wie ähnlich (oder anders) ist WinUI im Vergleich zu UWP, XAML Islands oder WPF?

WinUI 3.0 wird gewissermaßen die nächste Version der UI-Plattformkomponenten von Windows 10/UWP sein, einschließlich der Xaml-Plattform, Komposition und Eingabe. Es kommt von dieser Codebasis.

Es sollte den Windows 10/UWP Xaml-Plattform-APIs sehr ähnlich sein, abgesehen von dem, was in der Roadmap erwähnt wird : nämlich ein anderer Root-Namespace, bessere Unterstützung für das Mischen und Abgleichen mit anderen Technologien (z. B. Verwendung eines Win32-App-Modells anstelle von UWP) und einige neue additive Funktionen.

Ersetzt WinUI ALLE der folgenden (hypothetisch?): Win32, ATL, MFC, WinForms, Silverlight (ich weiß), WPF, UWP und/oder XAML Islands? Ich bin mir bewusst, dass diese Technologien weiterhin existieren und auf unbestimmte Zeit weiterhin unterstützt werden; Ich möchte nur klar verstehen, dass dies von Microsoft als "der Weg nach vorne" bezeichnet wird und dass wir (zum Beispiel) WinForms und WPF genauso betrachten sollten wie Win32 oder MFC.

WinUI ist der Ort, an dem unsere wichtigste aktive Entwicklung und unser Fortschritt für die native App-Benutzeroberfläche unter Windows liegt. Es ist auch das, was Windows selbst und native Microsoft-Apps und -Geräte verwenden.

Xaml-Inseln werden Teil von WinUI sein und ermöglichen Ihnen die Verwendung von WinUI zum Erstellen neuer Ansichten in bestehenden Apps (zB WPF, WinForms).

Welche Diskussion wird darüber geführt, WinUI für ältere Plattformen nach 1703 verfügbar zu machen, die meiner Meinung nach die derzeit älteste Plattform ist, die derzeit anvisiert wird?
Ist WinUI statisch verknüpfbar oder einbettbar (wie .NET Core/5) eine Option? Wir müssen auf Windows 8.1, Windows 8, Windows 7 – sogar Windows PE – abzielen. Wie können wir WinUI mit diesen Anforderungen verwenden?

Danke für das Teilen des Feedbacks dazu. Für 3.0 konzentrieren wir uns auf die Plattformen in der Roadmap (1703+, mit etwas Unterstützung für 8.1). Wir verstehen definitiv, dass Entwickler auch Kunden für andere Versionen haben, und das planen wir in Zukunft zu evaluieren.

Großartig – es klingt, als wäre WinUI „der Weg nach vorne“, und angesichts dieses Verständnisses wäre es eine Untertreibung zu sagen, dass ich aufgeregt bin.

Insbesondere finde ich es fantastisch, dass XAML-Inseln Entwicklern ermöglichen werden, WinUI auf ältere Technologien wie WPF und WinForms auszudehnen. Das ist eine großartige Brücke "nach vorne" während der Arbeit an/der Erweiterung alter(er) Projekte.

Großartig – es klingt, als wäre WinUI „der Weg nach vorne“, und angesichts dieses Verständnisses wäre es eine Untertreibung zu sagen, dass ich aufgeregt bin.

Insbesondere finde ich es fantastisch, dass XAML-Inseln Entwicklern ermöglichen werden, WinUI auf ältere Technologien wie WPF und WinForms auszudehnen. Das ist eine großartige Brücke "nach vorne" während der Arbeit an/der Erweiterung alter(er) Projekte.

Ich würde gerne denken, wenn ein WinForms-, MFC- oder WPF-Projekt mit enthaltenem WinUI 3.0 erstellt wurde - sie könnten einfach XAML-Seiten/Inhalte/Fenster rendern, ohne eine XAML-Insel in einem Formular/WPF-Fenster/HWND-Fenster verwenden zu müssen.

Die Möglichkeit, einfach reines XAML zu verwenden oder ein Island zu verwenden, um XAML in die vom Framework bereitgestellten Oberflächen zu platzieren – würde WinUI 3.0 wirklich zu "der einzigen Benutzeroberfläche, die sie alle beherrscht" machen.

würde WinUI 3.0 wirklich zu "Die eine Benutzeroberfläche, um sie alle zu beherrschen" machen

... unter Windows. 😉

WinUI 3.0 wird gewissermaßen die nächste Version der UI-Plattformkomponenten von Windows 10/UWP sein, einschließlich der Xaml-Plattform, Komposition und Eingabe. Es kommt von dieser Codebasis.

In diesem Sinne ,

Es wurde natürlich die WPF-Implementierung blieb trotz einer Entwicklungszeit von mehr als zwei Jahren

Darüber hinaus müssen noch viele Dienste, die im WPF-Markup verfügbar waren, in UWP verfügbar und implementiert werden. Ist der Aufwand hier, um sicherzustellen, dass das neue UWP-basierte WinUI 3.0-Markup die volle Übereinstimmung mit WPF aufweist? Entschuldigung, wenn dies irgendwo erklärt wird, aber ich muss die Nachrichten noch analysieren, um sie zu sehen (und begrüße alle Ressourcen, um mein Verständnis zu korrigieren / zu ergänzen).

würde WinUI 3.0 wirklich zu "Die eine Benutzeroberfläche, um sie alle zu beherrschen" machen

... unter Windows. 😉

Zumindest für das Release-Fenster von WinUI 3.0. Ich hoffe, es könnte der Beginn eines Prozesses sein, um das XAML-Rendering auf andere Plattformen zu bringen...

Ich frage mich, ob Sie dafür sprechen können, wie die Integration zwischen WPF und UWP verlaufen wird. Insbesondere bei Konzepten wie Markup-Erweiterungen, nach denen wir in UWP seit Jahren mit sehr geringem Erfolg gefragt haben. [...] Bemühen Sie sich hier um sicherzustellen, dass das neue UWP-basierte WinUI 3.0-Markup die volle Übereinstimmung mit WPF aufweist?

@Mike-EEE volle Treue mit WPF ist kein Ziel für 3.0. Wir sind jedoch eine Reihe von Workitems zu schließen Lücken im Laufe der Zeit - Tracking (zB # 741 Markup Erweiterung Verbesserungen - bitte einen Blick nehmen und einen Kommentar lassen , ob diese Ihren Anforderungen entsprechen würde) und weiter WinUI über WPF (zB erweitern # 686 3D-Modellunterstützung).

Wenn es andere spezifische Funktionen in WPF gibt, die Sie in WinUI verwenden möchten/müssen, können Sie gerne neue Feature-Vorschlagsprobleme dafür öffnen oder in der aktuellen Ausgabe #719 " WPF-Features, die in WinRT XAML sein sollten " kommentieren. Wir haben nicht unendlich viele Ressourcen, aber wir versuchen auf jeden Fall, den Beitrag der Community in unserer Planung zu berücksichtigen. Sobald alles Open Source ist, gibt es auch die Möglichkeit für jeden, potenziell mitzuhelfen, Funktionen beizutragen.

Das ist ermutigend, @jesbis danke, dass du das

Ich denke, meine größte Sorge ist, wenn die vollständige WPF-Wiedergabe kein Ziel ist, während die Verwendung von WinUI innerhalb von WPF ein Ziel ist, werden Sie bei der Einführung von WPF auf Reibungen stoßen, da es das überlegene (und ursprüngliche) Xaml-Modell hat.

Das heißt, es scheint kein offensichtliches Wertversprechen für die Integration von WinUI3.0 in WPF zu geben, genauso wie Xaml-Inseln kein offensichtliches Wertversprechen haben. Am Ende des Tages scheint es, dass Sie versuchen, ein zurückgegangenes / minderwertiges / unterentwickeltes Xaml-Modell in das etablierte und überlegene Xaml-Modell einzubringen, was einfach keinen Sinn ergibt.

Für Anwendungsfälle in WinForms, MFC usw. ist dieser Ansatz für WinUI3.0 ja sinnvoll. Mit WPF verfügt es jedoch über ein überlegenes Präsentationsmodell und ein überlegenes Entwickler-/Designer-Paradigma, das von keiner anderen Initiative von MSFT oder externen Anbietern erreicht wird.

@Mike-EEE basierend auf Scott Hunters Vortrag scheint es mir, was falsch sein könnte, dass das Ziel von "ONE BCL To Rule them all" eine höhere Priorität hat als das "One UI to rule them all".

Durch das Ersetzen von MONO, das Xamarin Forms XAML und UNO XAML in Web durch Webassembly zugrunde liegt, durch eine gemeinsame BCL mit AoC, profitieren Apps, die auf Xamarin Forms XAML, Uno XAML on Web basieren, von der Geschwindigkeitsleistung.

Diese Geschwindigkeitsleistung IST KRITISCH für jeden, der sich um die Zukunft seiner Karriere kümmert, die in C# für Cross-Plattform investiert, angesichts des intensiven Wettbewerbs, der von anderen Technologien wie Flattern, Reagieren usw.

Hoffentlich wird auf dieser Reise in Richtung .NET5 = eine gemeinsame BCL, um sie alle zu beherrschen , die XAML-Standardisierung teilweise oder vollständig während des Prozesses berücksichtigt, ABER nicht das Hauptziel von .NET5.

Eine weitere Priorität neben der Notwendigkeit der XAML-Standardisierung ist die Verbreitung des Microsoft-Brandings durch fließendes Design auf alle Plattformen (Mobil, Desktop und Web). [Technisch gesehen Entkopplung durch Win UI 3.0, die immer wieder gefragt wird, um den Zweck der WinUI 3.0-Roadmap zu fokussieren]

AM ENDE, wie viel UWP, von dem Win UI stammt, tatsächlich eine Rolle in dieser EINEN BCL spielt, um sie alle bis NOV2020 zu regieren, wenn .NET5 veröffentlicht wird, IST meiner Ansicht nach AUCH KEIN vorrangiges Ziel.

Aus Marketing-Sicht, leider nicht in Technologie übersetzt, die uns sehr am Herzen liegt, ist, dass Microsoft-Branding durch fließendes Design allgegenwärtig ist und die App, die dieses Design fördert, ÜBERALL SCHNELL ist.

So sehe ich die langfristige Strategie von Microsoft, "Marktanteile einzuholen" aufgrund mangelnder mobiler Präsenz.

Dies ist offensichtlich, außer ICH SEHE EIN WEITERES POTENZIAL in Hololens 2 und darüber hinaus. Dafür MÜSSEN WIR SICHERSTELLEN, DASS UWP-APPS mit WinUI 3.0 über 3D-Diagramm-Steuerelemente und einen erweiterten 3D-Modell-Viewer verfügen.

Tut mir leid, Leute, ich fordere das immer wieder auf, da ich die begrenzte Zeit, die ich habe, für die BEST OF THE BEST TECHNOLOGY nutzen möchte. :-)

In Bezug auf die WinUI 3.0-Übergangszeit

Ich würde vorschlagen, dass Microsoft direkt mit den Betreuern des Windows Community Toolkits (von denen einige für MS arbeiten) zusammenarbeitet, um:

1. Testen Sie, ob es beim Retargeting des Toolkits auf WinUI 3.0 (einschließlich der Beispiel-App) unvorhergesehene Hindernisse gibt.
2. Testen Sie die automatische Namensraum-Umbenennung über Visual Studio oder "ein anderes Tool", um zu sehen, wie reibungslos es geht.
3. Berichten Sie öffentlich über den Verlauf des Prozesses (Blog-Post/GitHub-Ausgabe/was auch immer Sie möchten).
4. Stellen Sie einen Textblock zum Kopieren und Einfügen über WinUI 3.0 und den Übergang bereit, den Projektbetreuer an ihre GitHub/Nuget/anderen Readme-Dateien anhängen können, oder zumindest eine URL mit prägnanten Informationen dazu. Dies wird dazu beitragen, Benutzer dieser Projekte schnell auf WinUI 3.0 zu bringen und zu erklären, was sie tun müssen, um den Übergang abzuschließen.
5. Skizzieren Sie einen vorgeschlagenen Übergangsprozess und einen Zeitplan, den Projekt-/Bibliothekspfleger übernehmen können.

In Bezug auf den letzten Punkt sollte dies Vorschläge umfassen wie:

• Erstellen Sie eine neue Hauptversionsnummer, die angibt, dass sie mit WinUI 3.0-Apps (wie WCT v6.0) verwendet werden soll.
• Erstellen Sie optional(?) einen Branch, der den Legacy-Code enthält, der Projekte unterstützt, die noch nicht auf WinUI 3.0 aktualisiert wurden.
• Geben Sie einen Zeitraum (zB 3/6/12 Monate) an, über den Support für Legacy-Projekte geleistet wird (zB Zusammenführen von Bugfixes und dergleichen aus dem Hauptzweig). Dies könnte möglicherweise bestimmte Daten haben, um den Supportzeitraum zwischen Gemeinschaftsprojekten/Bibliotheken zu "synchronisieren".

Schließlich denke ich, dass es wichtig sein wird, herauszufinden, was getan werden kann, wenn Sie Windows 10, Version 1507 & 1607 LTSB, unterstützen müssen. Dies sind die einzigen 2 unterstützten Versionen von W10, die in freier Wildbahn sein werden und mit denen WinUI 3.0 zum Zeitpunkt der Veröffentlichung nicht kompatibel ist.

Ursprünglich wollte ich den Prozess mit dem Windows 10-Rechner testen, da es sich um eine Open-Source-App in Produktionsqualität handelt. Dann wurde mir jedoch klar, dass diese App noch 6-7 Jahre auf 1507 & 1607 LTSB laufen muss. Die Unterstützung dieser Art von Apps wird natürlich umstritten sein, insbesondere wenn es um kleinere Community-Projekte geht. Wenn sie diese Unterstützung wirklich benötigen, sollte eine klare langfristige Strategie dafür bereitgestellt werden.

Bezüglich WinUI 4.0/3.x/vNext

Wie die Kommentare hier zeigen, hat die Community eine ziemlich lange Wunschliste für zukünftige Versionen von WinUI. Wir sollten die Dynamik und den Enthusiasmus, die hier aufgebaut werden, wirklich nutzen, indem wir einige der längerfristigen Pläne öffentlich dokumentieren.

Da die meisten dieser Elemente nicht im Rahmen von v3.0 enthalten sind, sollte meiner Meinung nach eher früher als später ein neues Problem erstellt werden, um Community-Feedback zu WinUI 4.0/3.x/vNext zu sammeln. Wenn überhaupt, hilft dies dabei, sowohl die Arten von Arbeit zu identifizieren, die das WinUI-Team in Betracht zieht, als auch was für WinUI und/oder die Verantwortung anderer MS-Teams außerhalb des Geltungsbereichs liegt.

Ein Beispiel für den letzten Punkt - ich würde wirklich gerne diese Dinge sehen:

• .NET Core 3.0-Unterstützung für UWP-Projekte (Verantwortung des .NET-Teams, wie ich es verstehe)
• Volle Unterstützung für Windows Apps (UWP & Win32) aus dem Visual Studio App Center (offensichtlich nicht etwas, wofür das WinUI-Team verantwortlich ist)
• Konkretere Richtlinien für Fluent Design, ähnlich denen, die Sie in den Material Design-Dokumenten finden (wiederum separate Teamverantwortung)
• Verwendung von WinUI 3.0 und fließendem Design in den W10-Apps im Lieferumfang (separate Teams und einige dieser Apps müssen LTSB-Versionen unterstützen)

Indem wir diese außerhalb des Geltungsbereichs liegenden Elemente identifizieren, können wir die Community zu den richtigen Feedbackpunkten umleiten und/oder anderweitig erklären, was in diesen Bereichen vor sich geht.

Abgesehen von diesen Dingen kann die Wunschliste im Umfang zusammenkommen und die Community kann damit beginnen, ihre Unterstützung für das zu zeigen, was sie in Zukunft am meisten von WinUI erwarten möchte.

Es wäre toll, wenn F# eine gleichwertige Unterstützung mit C# hätte, zum Beispiel mit den gleichen Projektvorlagen wie C#.

Ich möchte, dass WinUI (UWP vNext) ein richtiges Window- Objekt wie WPF mit den Methoden Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency und Show() / ShowDialog() hat.

(_Ich bin mir nicht sicher, wie dieses Fenster auf Geräten mit kleinem Bildschirm wie Mobiltelefonen und IoT funktionieren (oder erlaubt) würde_)

@TonyHenrique 1903 gibt es eine neue Windowing-API für UWP, aber sie ist noch lange nicht fertig.

Betrachtet noch einmal das Rendering von XAML im Rahmen von WinUI 3.0.

Dinge, die ich für einen Schritt nach unten vom Rendering von WPF halte, sind:

• Text verwendet kein ClearType, sondern bevorzugt Graustufen-Anti-Aliasing;
• Mangel an Pixelpräzision für Dinge wie Randstriche;

Ich kann verstehen, dass sich Windows Phone 7 und Windows Phone 8 ein Rendering-System teilen mussten – die Art der Bildschirmtechnologie und die Geschwindigkeit des Renderings trieben zu mehr Leistung. Aber mit WinUI, das zuerst auf Desktop umschwenkt und größere Displays - vielleicht ist es an der Zeit, diese Qualitäten in der XAML-Render-Engine wiederherzustellen.

Und wenn Dinge wie Hololens und Xbox besondere Aufmerksamkeit erfordern, warum nicht einen Leistungsmodus anbieten, der auf Plattformebene auf den Geräten aktiviert werden kann, die das Rendering so benötigen, wie es jetzt ist?

Was ist mit der f#-Vorlage?

Wenn es nicht sofort in Standard-Windows Forms- und WPF-Projektvorlagen für .NET Framework 4.5 oder höher funktioniert, können wir die WinUI-Bibliothek nicht übernehmen.

Nur die neueste Version von Windows 10 und/oder die UWP-Anwendung zu benötigen, ist der Knaller für die Einführung von Fluent-Design.

Ich würde vorschlagen, dass Microsoft direkt mit den Betreuern des Windows Community Toolkits zusammenarbeitet (von denen einige für MS arbeiten).

@kmgallahan
Toller Vorschlag! Das ist definitiv geplant. Unser Team arbeitet oft eng mit den Betreuern des Windows Community Toolkits zusammen und es ist eines der Dinge, die wir gerne als Testprojekt verwenden würden.

Betrachtet noch einmal das Rendering von XAML im Rahmen von WinUI 3.0.

@mdtauk
Alle Rendering-Änderungen sind wahrscheinlich außerhalb des Umfangs von 3.0, aber bitte eröffnen Sie ein Problem dafür, damit wir die Idee möglicherweise für nachfolgende Versionen überdenken können. Ein großer Schwerpunkt war definitiv die universelle Leistung, die, wie Sie bemerken, zu einigen Rendering-Änderungen in Windows 8+ führte. Der Leistungsmodusschalter ist eine interessante Idee.

Was ist mit der f#-Vorlage?

@edgarsanchez , @khoshroomahdi
Es scheint, als würden wir viel Interesse an F# bekommen! Wir würden gerne mehr darüber erfahren, warum Sie F# wollen: Bitte zögern Sie nicht in der F#-Ausgabe zu kommentieren, warum Sie es wollen und wofür Sie es verwenden würden: #740

Wenn es nicht sofort in Standard-Windows Forms- und WPF-Projektvorlagen für .NET Framework 4.5 oder höher funktioniert, können wir die WinUI-Bibliothek nicht übernehmen.

@jozefizso
Haben Sie sich die Xaml-Inseln angesehen? Mit dieser Funktion können Sie WinRT Xaml in WPF- und Windows Forms-Anwendungen verwenden, damit Sie sie mit modernen Xaml-Ansichten/-Seiten verbessern können:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

Wir planen, dass WinUI 3.0 Inseln enthält und abwärtskompatibel zu Creators Update und neuer ist, das sind mindestens die letzten 5 Versionen von Windows.

Könnte Xaml Islands, die an Creators Update und neuer mit WinUI 3.0 arbeiten, Ihre Anforderungen erfüllen?

Alle Rendering-Änderungen sind wahrscheinlich außerhalb des Umfangs von 3.0, aber bitte eröffnen Sie ein Problem dafür, damit wir die Idee möglicherweise für nachfolgende Versionen überdenken können. Ein großer Schwerpunkt war definitiv die universelle Leistung, die, wie Sie bemerken, zu einigen Rendering-Änderungen in Windows 8+ führte. Der Leistungsmodusschalter ist eine interessante Idee.

Fertig #768

XAML Islands erfordern Windows 10, Version 1903, und die Windows Community Toolkit- Bibliothek erfordert, dass das Projekt UWP ist. Das geht nicht.

XAML Islands erfordern Windows 10, Version 1903, und die Windows Community Toolkit- Bibliothek erfordert, dass das Projekt UWP ist. Das geht nicht.

WinUI 3.0 wird nicht auf Windows 7/8/8.1 umgestellt - aber diese Betriebssysteme werden sehr bald das Ende ihrer Lebensdauer erreichen. Und für diese können Sie vorerst noch WPF und WinForms verwenden. Dies ist der Fall, wenn Ihre Benutzer auf Windows 10 umgestiegen sind

In diesem Fall handelt es sich bei dem Projekt um UWP für Windows 10, sodass es keinen Sinn macht, WPF/WinForms zu unterstützen. Dies bewegt sich nur im Kreis und fragmentiert die Entwicklertools.

@jozefizso Genauer gesagt, dass sich UWP ändert, damit es mehr wie WPF und WinForms wird, und die XAML-Benutzeroberfläche nähert sich den WPF- und WinForms-Plattformen.

UWP-Apps mit moderner XAML-Benutzeroberfläche brechen aus der restriktiven Sandbox aus und können eine Verbindung zu den WPF- und WinForms-Plattformen herstellen.

So verstehe ich es.

XAML Islands erfordern Windows 10, Version 1903

In diesem Fall ist das Projekt UWP für Windows 10

Mit WinUI 3.0 planen wir, Inseln ab 1703 verfügbar zu machen (so viel weiter zurück).

Wir arbeiten auch daran, dass WinUI mit einem Win32-App-Modell anstelle von UWP verwendet werden kann (informell als "WinUI-Desktop" bezeichnet), sodass es nicht unbedingt eine UWP-App sein muss.

Wir arbeiten auch daran, dass WinUI mit einem Win32-App-Modell anstelle von UWP verwendet werden kann (informell als "WinUI-Desktop" bezeichnet), sodass es nicht unbedingt eine UWP-App sein muss.

Darauf freue ich mich am meisten. Eine native Anwendung mit der vollständigen verfügbaren API von Windows, sei es Win32 oder die Windows-Runtime, die über eine leistungsstarke Benutzeroberfläche über Xaml verfügen kann.

Wir arbeiten auch daran, dass WinUI mit einem Win32-App-Modell anstelle von UWP verwendet werden kann (informell als "WinUI-Desktop" bezeichnet), sodass es nicht unbedingt eine UWP-App sein muss.

Darauf freue ich mich am meisten. Eine native Anwendung mit der vollständigen verfügbaren API von Windows, sei es Win32 oder die Windows-Runtime, die über eine leistungsstarke Benutzeroberfläche über Xaml verfügen kann.

Nehmen Sie eine WinForms-App, behalten Sie den CodeBehind bei, ersetzen Sie jedoch das Formular durch ein XAML-Fenster, und haben Sie Zugriff auf alle Pinsel und XAML-Steuerelemente.

WPF wäre etwas komplizierter, wenn man nur das WinUI-XAML verwendet - aber zumindest könnten die WPF-Steuerelemente so gestaltet werden, dass sie den WinUI-Steuerelementen entsprechen

1. Der Namensraum sollte umbenannt werden. "Xaml" ist nicht geeignet, da sich Xaml auf eine Markupsprache bezieht, die fälschlicherweise als Marketingsprache (die sich häufig ändert) für native UWP-Komponenten verwendet wird. "Xaml" sollte durch "WinUI" ersetzt werden. Wie viel Verwirrung entsteht, sieht man selbst in diesem Thread, wo sehr oft unklar ist, ob sich "Xaml" auf die .xaml-Sprache oder auf ui-Komponenten bezieht.
2. Insofern dies WPF und UWP näher zusammenrückt, ist dies gut. Sie verfügen jeweils über Funktionen, die im anderen nicht vorhanden sind, und es ist sinnvoll, eine "Windows-Benutzeroberfläche" zu haben, die die beiden kombiniert. Möglicherweise gibt es eine gewisse Duplizierung von Funktionen, aber dies kann auch ein Übergangspfad WPF -> UWP sein.
3. Die Entkopplung von Windows-Versionen ist sinnvoll, aber es ist auch in Ordnung, von einem relativ aktualisierten Win10 auszugehen, da Win7 nach Abschluss dieser Arbeit das EOL weit hinter sich haben wird.

Xaml ist der Name des UI-Frameworks. Daher Windows.UI.Xaml...

Xaml ist der Name des UI-Frameworks

Xaml war eine Technologie in WPF, die es Entwicklern ermöglichte, nicht nur Präsentationsszenen innerhalb ihrer Anwendungen, sondern Anwendungen selbst leistungsstark zu beschreiben und zu erstellen. Das heißt, Sie könnten UI-Elemente _sowie POCOs_ beschreiben. Wenn es .NET wäre, könnte es mit Xaml ausführlich beschrieben und in einen Anwendungskontext geladen werden.

Damit wir nicht vergessen (und es hört sich so an), dass Xaml für eXtended Application Markup Language steht, was bedeutet, dass es sich um eine Markupsprache handelt, mit der Sie .NET-_application_-Komponenten elegant und effizient beschreiben können. Obwohl es in erster Linie zur Beschreibung von Benutzeroberflächenelementen verwendet wurde, wurde es in der Praxis nicht als solches herabgestuft oder eingeschränkt.

Ich persönlich habe Xaml verwendet, um meine gesamte Anwendungskonfiguration zu beschreiben und App.config – und ja, sogar Web.config – Komplexität zu entfernen und zu ersetzen, außer in Fällen für die externen APIs, die dies unbedingt erforderten.

Xaml ist _keine_ Benutzeroberfläche. Es sind insgesamt zwei völlig unterschiedliche Konzepte, die aber leider seit Jahren unter UWP verschmolzen sind. Ich für meinen Teil würde es _lieben_, den Begriff "Xaml" von diesen Bemühungen zu entwirren, aber ich bin nicht sehr zuversichtlich, dass solche Maßnahmen in Betracht gezogen, geschweige denn unternommen werden.

@charlesroddie Ich stimme zu, dass die Benennung wirklich willkürlich ist. Nur ein Tangens, wenn Sie jemals die Stack-Traces von Dingen untersuchen, die aus dem WUXaml-Namespace stammen, befinden sie sich tatsächlich intern in einem DirectUI-Namespace. Ich würde gerne die Geschichte von Win8 wissen, wenn jemand während dieser Tage hier war, weil ich mir vorstellen kann, dass es eine andere Geschichte gab. DirectComp zum Zusammensetzen von Ebenen, DirectManipulation für sanftes Scrollen und Rubberbanding und dann Direct2D/DirectWrite als Vektorgrafik-Engine mit DirectUI darüber, um alles zusammenzufassen. Dann wurde aus irgendeinem Grund ein Teil davon auf Win7 zurückportiert, nur die Xaml-Bits wurden durch das WinRT-System freigelegt, während alle anderen APIs als kryptische Com-Schnittstellen mit seltsamen Fabriken und Mustern übrig blieben, die Sie in Beispielen sehen mussten, um zu erklären, wie es geht aufrufen.

Jetzt, wo ich darüber nachdenke, wäre es wirklich schön, wenn Direct2D/DirectWrite, genau wie WUComposition DirectComp und DirectManipulation über WinRT (oder eine Neufassung) enthüllte, auch hier eine formale Heimat hätte. Sie alle arbeiten zusammen, um verschiedene Ebenen von Fluchtluken und Berührungspunkten der Treue zu ermöglichen, wenn Sie danach suchen. Win2D ist wirklich halbherzig und auch keine gute API.

Windows.UI.Composition ist meiner Meinung nach eine Neufassung von DirectComposition. Die APIs sind ähnlich, aber nicht gleich.

Hören Sie auf, davon auszugehen, dass alle Monitore sRGB sind.
Behandeln Sie die Farben aller Legacy-Apps als sRGB und führen Sie die Konvertierung für jeden Monitor während der Komposition durch.

Dies könnte ein wenig off-topic, aber vorausgesetzt , dass Sie bereits eine große Win32 appliation in C geschrieben haben ++, Sie wollen das UI - System modernisieren, so dass Sie WinUI oder Comp mit minimaler Abhängigkeit, wie die Verwendung Comp verwenden möchten , nur ohne Ein- Box Control Set oder sogar ohne XAML .

Das ist aber schon jetzt möglich, dafür müssen wir nicht auf WinUI 3.0 warten.

Danke an alle für das Feedback zur Namensgebung. Wie bereits erwähnt, unterscheiden wir heute zwischen der "Xaml-Plattform" und der "Xaml-Sprache" (mit ihren eigenen unterschiedlichen Spezifikationen/Dialekten), was verwirrend sein kann. Ich glaube nicht, dass ein größeres Rebranding geplant ist, aber wir diskutieren definitiv über Namensgebung und Namespaces.

Verwenden Sie Windows.UI.Composition in einer C++-Win32-Anwendung ohne XAML, um vorhandene Anwendungen (wie Photoshop) zu modernisieren. Sie verfügen bereits über eine UI-Architektur.

Dies mag ein wenig vom Thema abschweifen, aber angenommen, Sie haben bereits eine große Win32-Anwendung, die in C++ geschrieben ist, Sie möchten das UI-System modernisieren, also möchten Sie vielleicht WinUI oder Comp mit minimaler Abhängigkeit verwenden, z. Box-Steuerelementsatz oder sogar ohne XAML.

Danke für das Feedback dazu - ich denke, das sollte mit WinUI 3 am Ende hoffentlich möglich sein, ähnlich einer "rahmenlosen" App mit Windows.UI.Composition, die man heute schon machen kann. Wir werden dies berücksichtigen, wenn wir bestimmen, wie die WinUI NuGet-Pakete und -Abhängigkeiten strukturiert werden.

Hören Sie auf, davon auszugehen, dass alle Monitore sRGB sind.
Behandeln Sie die Farben aller Legacy-Apps als sRGB und führen Sie die Konvertierung für jeden Monitor während der Komposition durch.

@reli-msft könnten Sie ein separates Problem öffnen, um das zu verfolgen?

@jesbis 👉 # 67

Apple hat heute SwiftUI...

Wie wäre es, wenn Xaml Direct Visual Studio-Vorlagen erhalten würde, damit Entwickler wählen können, ob sie Apps mit Code anstelle von XAML und Code

Ich glaube nicht, dass ein größeres Rebranding geplant ist, aber wir diskutieren definitiv über Namensgebung und Namespaces.

Danke @jesbis Ich schätze es, dass du dich so in diesen Thread

Und Sie haben Recht: Es gibt 1) die Plattform für die Benutzeroberfläche und 2) den Mechanismus für Sprache/Markup/Beschreibung. In meinen kritischen Anmerkungen werde ich sagen, dass ich der (ersten) Benutzeroberflächenplattform nie genug Anerkennung zolle, da ich weiß, dass das Windows-Team diesbezüglich viel großartige Arbeit geleistet hat. Das hat mich persönlich nie beunruhigt. Es ist der zweite Bereich, der meinen (und den anderer) Zorn und Bestürzung auf sich zieht, und wir sehen dies in den UserVoice-Problemen, die im Laufe der Jahre aufgetaucht sind.

All dies sagte, ich würde zumindest bitten (bitte sogar 😅), Branding-Bemühungen weiter in Betracht zu ziehen, um diese beiden Bereiche besser zu kategorisieren. Ich denke, "Xaml Direct" ist hier der Gipfel der Verwirrung, da der Name "Markup Language" impliziert - der Name ist richtig! -- aber in seiner tatsächlichen Verwendung gibt es nichts dergleichen. Schrecklich verwirrend und irreführend und grenzwertiger Markenmissbrauch, würde ich anbieten.

Apropos Xaml Direct, @mdtauk :

Wie wäre es, wenn Xaml Direct Visual Studio-Vorlagen erhalten würde, damit Entwickler wählen können, ob sie Apps mit Code anstelle von XAML und Code Behind erstellen möchten.

Wie in so etwas wie CSharpForMarkup ?

Ein viel besserer und passender Name als Xaml Direct, würde ich vorschlagen. Natürlich wäre _jeder_ Name. 😉

Apropos Xaml Direct, @mdtauk :

Wie wäre es, wenn Xaml Direct Visual Studio-Vorlagen erhalten würde, damit Entwickler wählen können, ob sie Apps mit Code anstelle von XAML und Code Behind erstellen möchten.

Wie in so etwas wie CSharpForMarkup ?

Ein viel besserer und passender Name als Xaml Direct, würde ich vorschlagen. Natürlich wäre _jeder_ Name. 😉

@Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Es wurde für Middleware entwickelt, um XAML-UI aus Code zu schreiben, aber was wäre, wenn es Vorlagen gäbe, um sie anstelle von XAML-Dateien zu verwenden? Nur so ein Gedanke, um ihn loszuwerden...

@mdtauk JA! SwiftUI sieht aus wie Xaml, ist aber im Code ausgeführt. Ich liebe die Idee von allem im Code so, wie React es macht. Es ist irgendwie altmodisch, Ihre Designdateien aufzubrechen und dann mit einer Art Code-Behind zu verknüpfen, und ich finde, dass es schwierig ist, es zu verwalten.

Ein Freund hat gerade erwähnt, dass sie die SwiftUI-Layout-Engine benötigen, um mit dem 120-Hz-Display des iPad Pro zu arbeiten. Darauf haben sie sich also konzentriert. Ziemlich faszinierend wirklich.

Ich habe eine neue Ausgabe #804 erstellt, in der die Diskussion über von SwiftUI inspirierte Änderungen @eklipse2k8 gehen

Bitte vergessen Sie nicht , Vorlagen für Visual Basic hinzuzufügen

Lassen Sie WPF die unteren Schichten von _on_ WinUI 3 bauen!

@reli-msft Welche Vorteile möchten Sie durch die Aktualisierung von WPF erzielen?

Wenn Sie sich auf bestimmte WPF-Funktionen verlassen, die Sie in WinUI sehen möchten, würden wir gerne mehr im Thread „WPF-Funktionen, die in WinRT [WinUI] sein sollten“ erfahren: https://github.com/microsoft /microsoft-ui-xaml/issues/719

Abschluss zugunsten der neuen angehefteten Ausgabe #888

Freue mich schon sehr darauf. Wird viele Probleme lösen, die speziell auf die Version bezogen sind.

@weitzhandler [am 16. Mai 2019

Für mich sind alle technischen Details weniger wichtig.
UWP, WPF oder ein beliebiges Windows-only-Framework, so großartig es auch sein mag, wird nicht ausreichen, solange es nicht auf jeder Plattform läuft (zumindest Windows, Droid, iOS und Web) und freundlich mit jede Bildschirmgröße.

In Bezug auf WinUI und XAML im Allgemeinen würde ich gerne Verbesserungen in den folgenden Aspekten sehen, von denen ich einige als lästig empfinde und meine Arbeit verlangsame.

• VIEL mehr eingebaute Konverter Es sollte eine Menge Konverter geben, von denen einige sogar als Markup-Erweiterung verwendet werden sollten, um die Ausführlichkeit zu reduzieren. Dies sollte auch das Negieren einfacher arithmetischer Aktionen, Objekt-zu-Boolean-Umsetzer (false nach semantischem Wert, dh leere Zeichenfolge, leere Sammlung, versteckte Sichtbarkeit usw. pro Kontext) beinhalten.
• Wie oben, aber mit Verhaltensweisen. Es sollte eine einfache Portierung zwischen Bindung und Ereignissen/Aktionen geben. Wäre viel einfacher, wenn das eingebaut gewesen wäre und der Entwickler nicht im Zweifel hätte, welches nicht getestete NuGet zu verwenden ist.
• Alle fehlenden Dinge von WPF, wie einige Bindungstypen, Markup-Erweiterungen, generische Ansichten und andere.

Dankeschön!

VIEL mehr eingebaute Konverter

Seit Babbages analytischer Maschine und Turings Theorie der universellen Berechnung ist es für einen einzigen Computer möglich, jedes Programm auszuführen, das jeder Computer ausführen kann. Sie möchten in eine Zeit zurückkehren, in der wir für jede Berechnung, die Sie durchführen möchten, einen neuen Computer erstellen müssen.

Das ganze Konvertergeschäft sollte kurzerhand abgeladen werden.

Objekt in Boolesche Konverter

boolesche Werte sind boolesche Werte. Andere Objekte sind keine Booleschen. Und es gibt keine natürliche Umwandlung von Objekten in boolesche Werte. Typen sind in .Net wichtig und weitere untypisierte Systeme sollten Benutzern nicht ausgesetzt werden.

Ja, und vorhandene untypisierte Systeme wie Bindungen sollten ebenfalls gelöscht werden.

Das ganze Konvertergeschäft sollte kurzerhand abgeladen werden.

Ich meine, was sind deine Alternativen?
Mein Problem bei Konvertern ist nur, dass Sie sie selbst neu schreiben / aus NuGet auswählen müssen, und dass sie so ausführlich sind. Dass sie nicht flexibel sind und keine Ausdrücke wie Arithmetik oder Negation usw.

boolesche Werte sind boolesche Werte. Andere Objekte sind keine Booleschen.

Sie haben Recht, aber wenn es um die Benutzeroberfläche geht, ist es nicht wirklich wichtig.
Sie möchten Dinge anzeigen/verbergen, die auf dem konventionellen Zustand des Objekts basieren. Nicht alles sollte eine dedizierte Sichtbarkeitseigenschaft haben.

vorhandene untypisierte Systeme wie Bindings sollten ebenfalls gedumpt werden.

Hä? Ich denke tatsächlich, dass es einen Vorteil hat. Lose Kopplung zwischen V und VM kann gut sein.

vorhandene untypisierte Systeme wie Bindings sollten ebenfalls gedumpt werden.

Lose Kopplung zwischen V und VM kann gut sein.

Für kleine Projekte vielleicht, aber es gibt bessere Abstraktionen für die lose Kopplung, als die Compiler-Unterstützung buchstäblich auszuschalten. Wenn Sie jemals eine große Anwendung mit Dutzenden oder Hunderten von Ansichten verwalten mussten und etwas umgestalten möchten, das an mehreren Standorten verwendet werden kann, ist es eine erhebliche Verschlechterung der Entwicklererfahrung, wenn der Compiler die Richtigkeit der Bindungspfade nicht überprüfen lässt. Es gibt einen Grund, warum wir Typsysteme in unseren Sprachen haben, große Projekte sind buchstäblich ohne Tools zur Unterstützung des Programmierers nicht zu warten, derzeit hinken UI-Sprachen viel hinterher.

Kompilierte Bindungen helfen dabei sehr.

@weitzhandler Ich meine, was sind deine Alternativen?
... Nicht alles sollte eine dedizierte Sichtbarkeitseigenschaft haben.
Hä? Ich denke tatsächlich, dass [Bindungen] einen Vorteil haben. Lose Kopplung zwischen V und VM kann gut sein.

In einem guten reaktiven Framework können Sie beobachtbare Variablen (im Code) wie name:Mutable<string> und sie dann let visibility = name.map(fun s -> s <> "") und sie dann mit visibility.bind someView.set_IsVisible oder name.bind(fun s -> someView.IsVisible <- s <> "") an Anzeigeeigenschaften binden

Ich verwende https://github.com/ReedCopsey/Gjallarhorn, aber es gibt verschiedene reaktive Frameworks.

Beachten Sie Folgendes: 1. Im Gegensatz zu Bindungen wird alles getippt. 2. Dinge (Funktionen, Eigenschaften, Ansichten) werden als Objekte bezeichnet, nicht indem Stringnamen herumgereicht werden, 3. Funktionen sind nur Funktionen, viel weniger klobig als Konverter, 4. Binding-Boilerplate, bei der einfache Objekteigenschaften extra angegeben werden müssen "bindable Properties" etc. entfernt werden.

Ansichten können immer noch in Xaml geschrieben werden, insbesondere wenn es sich um einfache, meist statische Layouts handelt, mit dem Nachteil, überall magische Zeichenfolgen zu haben, aber den Vorteil, einen Designer zu haben, der eine Live-Ansicht liefert. Besser wäre es, Code zu haben, der eine Live-Ansicht bietet. Mit Dolmetscher sehr gut möglich.

Apropos reaktive Frameworks, bitte schau dir Chain Reactive an und sag, ob ich es als Open Source verwenden soll.

Hallo, kann MS Team alle Fehler/Funktionen von
Wenn ja, wäre das ein großartiger Schritt, mehr als WinUI 3.0.

@hupo376787 Ich denke, Sie haben negative Stimmen erhalten, weil dies nicht der Thread ist, um die Windows-Entwicklungsplattform im Allgemeinen zu diskutieren, und selbst dieses Repository ist wahrscheinlich auch nicht der richtige Ort, da es sich nur auf einen Aspekt dieser Plattform konzentriert.

Aber es IST ein Problem, dass es keinen Platz für offene Diskussionen über Windows-Entwicklungsplattformen gibt, an denen Microsoft und Entwickler teilnehmen können, und es IST ein Problem, dass die entsprechende Microsoft-Gruppe keine Feedback-Mechanismen unterhält, da sie nicht aktualisiert oder darauf reagiert hat Uservoice seit mehreren Jahren.

@charlesroddie Ja, es scheint, dass die Benutzerstimme aufgegeben wurde. Ich schicke meine Stimme an Feedback Hub. Vielleicht ignoriert ms sie, aber ich werde meinen Job machen.

Die UserVoice wird diesen Monat vollständig eingestellt.

Für bestimmte Produkte sind GitHub-Repos (wie dieses) der beste Ort für Feedback, da die entsprechenden Engineering-Teams sie aktiv nutzen.

Für Feedback, das sich nicht auf ein bestimmtes Repository-Produkt bezieht, verwenden Sie bitte den Feedback Hub. Es gibt eine Kategorie "Entwicklerplattform" mit verschiedenen Unterkategorien speziell für Feedback zu APIs und Entwicklertools.

Ich weiß, dass es derzeit viel Geschichte und früheres Feedback zu UserVoice gibt (das wir noch verfolgen werden), aber sowohl GitHub als auch Feedback Hub bieten einen direkteren Weg zu unseren Entwicklungsteams und zur Nachverfolgung von Arbeitselementen, als es UserVoice jemals könnte, also hoffentlich dies sollte eine positive Veränderung sein. Wir sind dabei, verschiedene Support- und Feedback-Links zu aktualisieren.

Wir sehen alles, was von beiden Kanälen hereinkommt, und freuen uns sehr über Feedback und Fehlerberichte!

@jesbis OK, verstanden.

Funktioniert das Eigenschaftenfenster für WinForms bei Verwendung der neuen WinUI-Projektvorlage weiterhin und kann die Eigenschaften der WinUI-Steuerelemente festgelegt werden? Ich kann den ganzen Tag problemlos HTML programmieren (normalerweise Asp.net MVC), aber wenn es so viele Einstellungen für Steuerelemente gibt, habe ich es genossen, das Eigenschaftenfenster in den letzten 20 Jahren zu verwenden.

@Dean-NC Ich nehme an, Sie fragen nach dem XAML-Designer, nicht nach WinFoms / Windows Forms, oder? Wenn ja, funktioniert der Eigenschaftenbereich weiterhin für WinUI-Steuerelemente, wenn Sie ein Element im XAML-Designer auswählen.

@marb2000 Ich glaube, ich dachte naiv, dass WinUI 3 die neuen Steuerelemente in WinForms in dem Sinne einbringen würde, dass es größtenteils nahtlos wäre und dass ich ein Formular mit Legacy- und WinUI-Steuerelementen darauf haben könnte und dass das Eigenschaftenfenster funktionieren würde für Legacy- und WinUI-Steuerelemente.

Ich habe den gesamten Beitrag oben gelesen und habe ihn mit großer Aufregung verfolgt (als WinForms-Entwickler), aber ich glaube, ich habe den Workflow auf hoher Ebene missverstanden, wie dies funktionieren wird (wiederum aus WinForms-Sicht ).

Ich habe lange gesagt, dass WinForms auch in den kommenden Jahren eine großartige Sache sein könnte, aber die größte Schwäche ist, dass die grundlegenden Steuerelemente veraltet aussehen (das Textfeld lässt kein Auffüllen zu, daher sieht es dünn aus, kleine Optionsfelder und Kontrollkästchen) , etc.). Nur die Grundlagen der Win 10-Steuerelemente (Textfeld, Radio, Kontrollkästchen) würden viel dazu beitragen, WinForms neues Leben einzuhauchen.
Gibt es einen Artikel, oder macht es Ihnen etwas aus, eine kurze Beschreibung des Workflows für ein neues WinForms-Projekt zu geben, das sowohl ältere als auch neue Steuerelemente verwenden möchte?
Vielen Dank.

@marb2000 Ich glaube, ich dachte naiv, dass WinUI 3 die neuen Steuerelemente in WinForms in dem Sinne einbringen würde, dass es größtenteils nahtlos wäre und dass ich ein Formular mit Legacy- und WinUI-Steuerelementen darauf haben könnte und dass das Eigenschaftenfenster funktionieren würde für Legacy- und WinUI-Steuerelemente.

Ich habe den gesamten Beitrag oben gelesen und habe ihn mit großer Aufregung verfolgt (als WinForms-Entwickler), aber ich glaube, ich habe den Workflow auf hoher Ebene missverstanden, wie dies funktionieren wird (wiederum aus WinForms-Sicht ).

Ich habe lange gesagt, dass WinForms auch in den kommenden Jahren eine großartige Sache sein könnte, aber die größte Schwäche ist, dass die grundlegenden Steuerelemente veraltet aussehen (das Textfeld lässt kein Auffüllen zu, daher sieht es dünn aus, kleine Optionsfelder und Kontrollkästchen) , etc.). Nur die Grundlagen der Win 10-Steuerelemente (Textfeld, Radio, Kontrollkästchen) würden viel dazu beitragen, WinForms neues Leben einzuhauchen.
Gibt es einen Artikel, oder macht es Ihnen etwas aus, eine kurze Beschreibung des Workflows für ein neues WinForms-Projekt zu geben, das sowohl ältere als auch neue Steuerelemente verwenden möchte?
Vielen Dank.

Es ist wahrscheinlicher, dass Sie Ihr App-Projekt übernehmen, WinUI-Fenster und -Seiten hinzufügen und die moderne XAML-Benutzeroberfläche verwenden können, um Ihre Benutzeroberfläche entweder vollständig oder nach und nach zu ersetzen.

Und es gibt XAML-Inseln zum Einfügen von XAML in vorhandene Winforms- und WPF-UIs

Ihr Blazor-Team sollte mit Uno zusammenarbeiten, um einige seiner Hosting-Modelle in Uno aufzunehmen (insbesondere die Serverseite) und/oder die Uno-Benutzeroberfläche (und damit WinUI 3) Rendering-/Visual-Ebene für Blazor nutzbar zu machen.... und/oder vielleicht Xaml Islands für Blazor?

Ich fühle mich hier ein wenig außer sich, weil das meiste Feedback von Entwicklern kommt, die hauptsächlich im Xaml-Bereich arbeiten. Sie scheinen im Allgemeinen nach einer besseren Version dessen zu suchen, was sie bereits haben. Das mag für bestehende Benutzer gut sein, aber ich weiß nicht, ob es viele Entwickler anziehen wird, die UWP bisher gemieden haben.

Mein Team hat nur 1 UWP-App entwickelt. Wir werden nicht mehr entwickeln.

Die unüberwindbare Hürde ist das Fehlen eines integrierten tabellarischen Berichtsschreibers. Wir haben alle Berichtersteller von Drittanbietern auf dem Markt ausprobiert, die angeben, dass sie UWP unterstützen. Leider funktioniert keiner von ihnen gut mit UWP. Ihr UWP-Angebot ist normalerweise ein schneller Hack ihrer WPF/WinForms-Variante und funktioniert nicht richtig.

Wir verwenden Stimulsoft Reports in unserem UWP-Produkt. Es ist sehr fehlerhaft und sie haben uns gesagt, dass sie die Fehler nicht beheben werden, da ihre UWP-Aufnahme so gering ist.

Ich sehe, Sie haben eine Datenvisualisierung auf der Liste. Aber der Grund, warum es immer noch Millionen von grauen Schlachtschiff-Apps gibt, ist, dass viele Unternehmen sich nicht viel für die Grafik interner Apps interessieren. Sie wollen Zahlenspalten mit Zwischensummen.

Wenn WinUI also endlich die Formulare über Datenentwickler locken soll, brauchen wir einen integrierten tabellarischen Berichtschreiber.

Ich hoffe, das beleidigt die visuellen Leute nicht :-)

Ich stimme voll und ganz zu. Wie können wir moderne Business-Apps ohne ein Reporting-System entwickeln, das sich einfach in die App integrieren lässt? Es ist eine riesige Schlucht, die Entwickler daran hindern wird, sich zu bewegen.

Geschäftsanwender müssen in der Lage sein, mit tabellarischen Daten zu interagieren und sie dann auszudrucken oder in andere Formate zu exportieren. Sie müssen auch in der Lage sein, Rechnungen, Angebote, Kontoauszüge und andere wichtige Dokumente zu erstellen.

Nach meinem Verständnis sind Unternehmen/Unternehmen immer noch der größte Verbraucher von Windows. Warum wird etwas so Grundlegendes für das Windows-Ökosystem nicht für UWP entwickelt?

Danke für das Feedback @VagueGit und @Elmarcotoro ! Unternehmenskontrollen sind derzeit eine Lücke für uns. Aber Ihr Timing ist gut, wir sammeln Feedback für den Entwurf eines DataGrid-Steuerelements. Bitte lesen Sie hier und geben Sie Feedback: #1500 .

Ebenso benötigen wir neben der quadratischen tabellarischen Datenkontrolle ein Open-Source-UWP-Graphensteuerelement, um auf kreative und demokratisierende Weise komplexe Beziehungen durch Diagrammsteuerung zu teilen

Für ein Berichtssystem denke ich, dass Telerik UI derzeit die beste Wahl ist. Ein chinesisches Sprichwort sagt: "Manche Leute spezialisieren sich auf einige Berufe, während andere auf andere Berufe." Telerik, DevExpress oder jemand anderes können gut berichten.

Für das Fehlen verschiedener Kontrollen sollten wir nicht diesem Team die Schuld geben, sondern für die gesamte MS-Strategie. Von Anfang an gibt Satya das Handy auf, sie bevorzugen iOS und Android besser, weil Bosse wie sie sind. Das gesamte UWP-Ökosystem wird schwach und schwach.

Im Moment gibt es auf Twitter ein Argument namens "UWP ist tot". Ich denke, MS sollte dies klären und ihre UWP-Straße erklären.

Im Moment gibt es auf Twitter ein Argument namens "UWP ist tot". Ich denke, MS sollte dies klären und ihre UWP-Straße erklären.

Das hast du gerade im Roadmap-Thread gepostet...

@jevansaks Danke für die Info zur Datagrid-Steuerung. Dies betrifft nicht die Probleme des Druckens von Berichten und der Paginierung, des Exports und dergleichen. Dies sind reale Geschäftsszenarien, die behandelt werden müssen, nicht ob einige Schaltflächen animiert werden (so schön und cool das auch sein kann).

@hupo376787
"Für ein Berichtssystem denke ich, dass Telerik UI derzeit die beste Wahl ist."

Soweit ich sehen kann, sind Dev Express die einzigen, die derzeit einen vollständigen Stapel zum Erstellen und Anzeigen von Berichten für UWP bereitstellen, und ihre Preise scheinen auf der Premium-Seite zu liegen. Alle anderen einschließlich Telerik haben Lücken in ihren Werkzeugen, was bedeutet, dass Berichte für UWP nicht erstellt werden können. Ich bin bereit (hoffe), diesbezüglich korrigiert zu werden.

Für ein Berichtssystem denke ich, dass Telerik UI derzeit die beste Wahl ist. Ein chinesisches Sprichwort sagt: "Manche Leute spezialisieren sich auf einige Berufe, während andere auf andere Berufe." Telerik, DevExpress oder jemand anderes können gut berichten.

@hupo376787 Bitte überprüfen Sie Ihre Fakten besonders sorgfältig, bevor Sie andeuten, dass ein Beitrag falsch ist. Telerik Reporting verfügt über einen Berichtsdesigner für WPF und WinForms, jedoch nicht für UWP.

DevExpress verfügt auch über einen Berichtsdesigner für WinForms und WPF, jedoch nicht für UWP

Bitte überprüfen Sie daher Ihre Fakten, bevor Sie sich auf einen Fehler begeben, der für immer aufbewahrt und weit verbreitet wird. Hey, das klingt, als wäre es eines Tages ein altes Sprichwort

@hupo376787 Bitte überprüfen Sie Ihre Fakten besonders sorgfältig, bevor Sie andeuten, dass ein Beitrag falsch ist. Telerik Reporting verfügt über einen Berichtsdesigner für WPF und WinForms, jedoch nicht für UWP.

DevExpress verfügt auch über einen Berichtsdesigner für WinForms und WPF, jedoch nicht für UWP

Bitte überprüfen Sie daher Ihre Fakten, bevor Sie sich auf einen Fehler begeben, der für immer aufbewahrt und weit verbreitet wird. Hey, das klingt, als wäre es eines Tages ein altes Sprichwort

OK, ich denke, wir haben ein anderes Verständnis von Reporting. Ich meine https://www.telerik.com/universal-windows-platform-ui und https://www.devexpress.com/products/net/controls/win10apps/.

Ich habe mich geirrt, Dev Express bietet keine Berichterstellung für UWP. Es scheint, dass kein Drittanbieter-Tooling-Entwickler dies tut! Ich habe Dev Express über ihren Chat kontaktiert, um zu erfahren, ob sie eine Roadmap für die Bereitstellung von Berichten für UWP hätten.
Sie sagten,
"Die XtraReports Suite verwendet die von der System.Drawing-Assembly bereitgestellte Funktionalität, und die Sache, die uns daran hindert, dieselben Tools für universelle Fensteranwendungen zu implementieren, ist, dass diese Assembly dort nicht verfügbar ist (https://stackoverflow.com/questions .). /31545389/windows-universal-app-with-system-drawing-and-possible-alternative). Daher haben wir unsere Zukunftspläne in diesem Bereich noch nicht festgelegt."

@jevansaks , es scheint, dass es an Kommunikation zwischen dem Microsoft-UI-Team und diesen Drittanbieter-

Sie baten mich, ihr [email protected] mit unseren Reporting-Anforderungen zu kontaktieren. Es kann für das Win UI 3.0-Team hilfreich sein, sich mit ihnen in Verbindung zu setzen und zu sehen, ob sie ihnen bei der Implementierung helfen können. Ich sehe nicht, wie Sie ohne geeignete Reporting-Tools Geschäftsentwickler auf die universelle Plattform bringen.

https://www.devexpress.com/subscriptions/reporting/

Berichterstattung: Nur aus WinForms-Perspektive habe ich sowohl Telerik als auch DevExpress (sogar ihre neuesten Versionen) verwendet, und obwohl Telerik gut war, denke ich, dass DevExpress nicht nur einen besseren Gesamtdesigner und eine bessere Erfahrung hat, sondern auch viel subtilere Funktionen hat als erlaubte mir, komplexere Layouts zu erstellen als Telerik. Ich denke, die DevExpress-Rendering-Technologie ist fortschrittlicher.

Es kann für das Win UI 3.0-Team hilfreich sein, sich mit ihnen in Verbindung zu setzen und zu sehen, ob sie ihnen bei der Implementierung helfen können.

Danke für den Anruf. Wir werden sie auch ansprechen.

Danke für den Anruf. Wir werden sie auch ansprechen.

Es kann sich lohnen, mit allen zu sprechen und zu sehen, was die Blöcke sind? Telerik, Grapecity, DevExpress usw.

Danke für den Anruf. Wir werden sie auch ansprechen.

Es kann sich lohnen, mit allen zu sprechen und zu sehen, was die Blöcke sind? Telerik, Grapecity, DevExpress usw.

Das ist sicher unser Plan.

Wir sind ein bisschen anders als die meisten Entwickler, die für Windows erstellen. Wir entwickeln hauptsächlich Kiosk-Apps (Apps, die von anderen Benutzern als dem Besitzer des Computers ausgeführt werden sollen und normalerweise im Vollbildmodus ohne Zugriff auf das umfassendere System ausgeführt werden). Die Apps werden im Allgemeinen nach den spezifischen Anforderungen des Kunden erstellt, ohne die Absicht, sie über den Store oder Ähnliches zu verteilen.

Da die Apps im Vollbildmodus ausgeführt werden, haben die integrierten Steuerelemente nur einen sehr begrenzten Wert, um das Erscheinungsbild anderer Windows-Apps beizubehalten. Stattdessen neigen sie dazu, für jeden Kunden hochgradig gebrandet zu sein. Wir brauchen immer noch viele gemeinsame _Verhaltensweisen_ und Steuerelemente von Standard-Windows-Apps, aber wir nehmen normalerweise viele Anpassungen an den Steuerelementvorlagen jedes einzelnen vor oder überschreiben zumindest deren Kernstile. Für eine sehr lange Zeit haben wir viele Apps als WinForms-Backends mit eingebetteten Flash-Frontends für die Benutzeroberfläche entwickelt.

Im Großen und Ganzen integriert fast jede App, die wir schreiben, eine Art webbasiertes Backend mit einer Hardware (z Komponenten usw.), und die überwiegende Mehrheit dieser Komponenten wurde in der Vergangenheit mit Win32-SDKs und nicht mit UWP-SDKs geliefert.

Aus diesen beiden Gründen sind die meisten unserer historischen Apps WinForms-Apps und die meisten unserer modernen Apps WPF-Apps. Wir haben ein paar UWP-Apps entwickelt (hauptsächlich, um von den wirklich netten Funktionen des zugewiesenen Zugriffs/Kiosk-Modus von Windows zu profitieren), aber sie sind im Vergleich zu WPF normalerweise mühsam, und wir können normalerweise sowieso keine kompatiblen Hardware-SDKs bekommen .

Wir sind jedoch sehr fasziniert von XAML Islands, die es uns ermöglichen, Win32-kompatible Apps mit moderner Benutzeroberfläche zu schreiben (obwohl der Vorteil von UWP gegenüber WPF für uns nicht immer klar ist, insbesondere wenn wir keine Standardsteuerelemente oder Microsoft-spezifische verwenden Effekte wie Fluent usw.).

Um Ihre spezifischen Fragen zu beantworten:

Welche Vorlagen würden Sie am meisten interessieren?

C# mit .NET Core, Win32 mit WinUI 3.0 überlagert wäre schön.

Kennen Sie Xaml Islands für die Modernisierung von Desktop-Apps?

Ja, und ich war relativ zufrieden mit ihnen, als ich mit ihnen gespielt habe, obwohl wir wahrscheinlich kein _einzelnes_ Steuerelement verwenden werden, sondern eine Entscheidung für die gesamte benutzerdefinierte Benutzeroberfläche treffen.

Der Hauptgrund, warum ich mir dessen bewusst war, war, dass wir Lottie- Unterstützung für Win32-Apps bekommen würden.

Macht diese erweiterte Abwärtskompatibilität unter Windows 10 Xaml Islands für Sie nützlicher?

Nicht wirklich; Wir kontrollieren fast immer die Ziel-PCs und können sicherstellen, dass wir immer die neueste kompatible Version erhalten.

Wäre es hilfreich, wenn Visual Studio oder ein anderes Tool Namespaces automatisch für Sie aktualisiert?

Jawohl.

Wie wichtig ist Ihnen die vollständige Kompatibilität zwischen vorhandenen UWP-Xaml-Komponenten und WinUI 3.0-Apps?

Sehr minimal. Das Hauptproblem bei der Kompatibilität, das wir hätten, wären geänderte StaticResource-Schlüssel zum Gestalten von Kernelementen.

Erstellen oder verwenden Sie UWP-Xaml-Steuerelementbibliotheken oder WinRT-Komponenten, die Sie nicht einfach zusammen mit App-Code neu kompilieren und aktualisieren können?

Ja, wir haben in der Vergangenheit die Syncfusion UWP-Steuerungsbibliothek verwendet .

Was wäre Ihre bevorzugte Lösung für die Verwendung von UWP-Xaml-Komponenten mit WinUI 3?

Die bevorzugte Lösung wäre, mehr Standardsteuerelemente in WinUI selbst zur Verfügung zu haben, anstatt sich auf externe Quellen (z WinUI 3 sowieso zum größten Teil.

Was halten Sie von dem oben und in der Roadmap skizzierten Gesamtplan 3.0? Würde es Ihnen ermöglichen, WinUI für Ihre neuen und vorhandenen Windows-Apps zu verwenden?

Ich freue mich zu sehen, dass UWP-Steuerelemente deutlicher von der UWP-App und dem Sicherheitsmodell entkoppelt sind, das uns in der Vergangenheit aus Gründen der Hardwarekompatibilität gesperrt hat, insbesondere da WinUI im Freien entworfen und entwickelt wird.

Mit solch einer klaren Anleitung dazu, wie Microsoft uns empfiehlt, App-Benutzeroberflächen zu erstellen, würde ich erwarten, dass alle unsere Apps mit WinUI-Front-Ends enden, unabhängig davon, welches Back-End wir unterstützen können.

Für welche Art von Apps würden Sie WinUI 3.0 am liebsten verwenden? Erstellen einer neuen Win32-App und Verpacken mit MSIX? Hinzufügen neuer Ansichten zu einer WPF-App? Modernisierung einer C++-MFC-App mit Fluent UI?

Vor allem über den Zugriff auf aktiver gewartete Bibliotheken von Steuerelementen in meinen älteren Apps mit schönerer, offensichtlicherer Dokumentation (oder sogar Zugriff auf den zugrunde liegenden Code für das Standardsteuerelement) ist es viel einfacher herauszufinden, wann ich ein Standardsteuerelement anpassen kann und wenn ich mein eigenes Benutzersteuerelement rollen muss. Zum Beispiel hatte ich in einer kürzlich in WPF erstellten App ein paar Datumsauswahl; Es war extrem ärgerlich, dass diese Steuerung für die Berührung gut funktioniert und die Größe, Schriftart, Popup-Symbol usw. angepasst wird. Angesichts der obigen Roadmap wäre ich geneigt, WinUI für diese Art von App von _default_ in Zukunft zu verwenden, denn:

1. Ich kann ziemlich sicher sein, dass es eine native Datumsauswahl-Steuerung gibt, die zumindest mäßig berührungsfreundlich ist
2. Ich kann die nativen/out-of-the-box-Vorlagen usw. dieses Steuerelements überprüfen, um leicht zu sehen, was ich überschreiben muss, damit es den Designproofs für das Erscheinungsbild des Kunden entspricht (als grob repräsentatives Beispiel möchte ich vielleicht um herauszufinden, wie der Typ – Schriftgröße, Gewichtung, Familie – des Headers eines TextBox-Steuerelements unabhängig vom Eingabetext am saubersten gestaltet werden kann; verwendet die Standard-HeaderTemplate magische statische Ressourcen, die ich neu definieren kann, oder muss ich die Vorlage selbst überschreiben? Wenn ich die Vorlage überschreibe, wie sieht das Markup der Standardvorlage aus; tut/unterstützt sie alles, was ich nicht in Betracht gezogen hatte?).

Ich sehe, dass dies geschlossen wurde, aber es gibt ein paar Probleme, die von unseren Benutzern angesprochen werden, die meiner Meinung nach es wert wären, angesprochen zu werden. Sie sind Produktivitätsverbesserungen für Benutzer, die mit großen Datenmengen arbeiten.

Textfeld:
Wenn ein Benutzer ein Textfeld bearbeiten muss, muss er zuerst in das Textfeld klicken, um die Schaltfläche zum Löschen anzuzeigen, und dann auf die Schaltfläche zum Löschen klicken, um das Textfeld zu löschen. Dies ist bei der Arbeit mit großen Datenmengen sehr ineffizient. Es wäre gut, wenn der Text beim Klicken oder Tabulatoren in die TextBox hervorgehoben werden könnte, um überschrieben zu werden.

Rasteransicht/ Listenansicht:
Die Gridview und ListView scheinen es dem Benutzer nicht zu ermöglichen, effektiv durch die Sammlung zu navigieren.
Die ListView ermöglicht es Tab, zu Steuerelementen in derselben Zeile zu wechseln, aber es wird nicht Tab zur nächsten Reihe von Steuerelementen verwendet. Stattdessen verliert die ListView den Fokus und Tab wechselt zum nächsten Steuerelement in der visuellen Struktur.

Dies sind zwei Probleme, die von unseren Benutzern als sehr ärgerlich angesprochen wurden.

@Elmarcotoro

Ich würde empfehlen, dass Sie für jede der von Ihnen erwähnten Verbesserungen ein neues Problem erstellen. Das WinUI-Team führt dann eine Triage durch, um festzustellen, ob WinUI 3 vor der Implementierung veröffentlicht werden muss oder nicht.

Dieses Problem bestand in erster Linie, um Feedback zu den 2 "Allgemeinen Fragen" am Anfang des Beitrags zu erhalten.

Unterstützen Sie das native Blazor-Hostingmodell in WinUI. Dadurch könnte ein Blazor-Steuerelement direkt im Client/Server-Web oder direkt in WinUI verwendet werden. Die Blazor-Roadmap hat dieses Zukunftskonzept, ohne ein WebView-Steuerelement zu verwenden. Auf diese Weise wird die Benutzeroberfläche des Steuerelements nativ ausgeführt, während der .Net Standard-Teil des Codes ebenfalls nativ ausgeführt wird.

Unterstützen Sie das native Blazor-Hostingmodell in WinUI

Diskutiert auf der Blazor-Seite, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

Das ist sicher unser Plan.

@jevansaks Wäre toll, auch in die Schleife

Ich würde mir eine bessere Konsistenz von Tray-Menüs / Symbolmenüs mit WinUI 3.0 wünschen. Jede App hat einen anderen Abstand, und Win32-Apps folgen nicht konsistent dem Schriftart-Rendering / -Abstand / -Designs. Bitte beheben Sie dies bereits!

WinUi im Desktop für mich völlig nutzlos, da keine Windows-Verwaltungsmöglichkeit vorhanden ist: Fenster anzeigen/ausblenden, Fensterposition, Fenstergröße, andocken/abdocken ...

@alexandrevk es ist immer noch eine Vorschau. Haben Sie das Windowing-API-Design gesehen? https://github.com/microsoft/ProjectReunion/issues/157

Danke @dotMorten für den

@alexandrevk - wir stellen APIs für Reunion zusammen, mit denen Sie diese Art von Windowing-Vorgängen sowohl von Win32 als auch von UWP mit WinUI-Inhalten sowie bei Verwendung anderer Frameworks/Swapchain-Inhalte in Ihrem Fenster ausführen können. Einige dieser Windowing-Features können dann auch in die WinUI-Window-Klasse für einen einfacheren Zugriff abstrahiert werden, aber das ist weiter unten. Feature-Spezifikationen für den Windowing-Bereich sind in Vorbereitung, bleiben Sie dran.

Streng genommen als einzelner Benutzer (dh: Nicht-Unternehmen/Firma) und nur c++, auch wenn ich nur eine einsame Stimme bin, die ins Leere schreit, muss ich sagen, dass, solange eines dieser neuen UI-Systeme es ist gebunden an UWP und dieses schreckliche Verpackungssystem, in das sie eingebaut sind, dann wird es immer im Dunkeln bleiben, was auch immer Sie tun. (Aus Erfahrung mit WinRT habe ich WinUI noch nicht ausprobiert, aber es sieht für mich ziemlich gleich aus).
Sicherlich muss bekannt sein, dass wenig bis niemand UWP-Apps tatsächlich nutzt? (eigentlich von den meisten Afaik gehasst) Wenn es also "nativ" heißt, warum ist es dann nicht wirklich "nativ", dh: ein paar #includes, verlinke eine oder zwei .lib und baue deine App in STANDARD c++.
Auf Dinge wie Qt zurückgreifen zu müssen, wenn Cross-Plat keine Rolle spielt, nur um zu vermeiden, dass Win32 zum 1000. Mal verpackt wird, wird es ziemlich alt, um fair zu sein.
Jedenfalls nur meine 2 Cent, von jemandem, der die Sprache jeden Tag verwendet, aber wahrscheinlich hier keinen Platz zum Kommentieren hat.

@nl-n Sie sollten sich freuen zu wissen, dass einer der großen Deals mit WinUI darin besteht, dass es nicht als UWP-App ausgeführt werden muss. Tatsächlich ist dies seit der Vorschau 2 möglich.
_Derzeit_ muss es als msix verpackt werden, aber msix ist eigentlich eine ziemlich anständige Möglichkeit, Ihre Apps zu verteilen (und zu aktualisieren).

@dotMorten Das ist eines der großen Probleme: Seitenladen/Installation über den Store erforderlich. Ich kenne keine einzige Person, die den Store vor (oder kurz nach) der Installation von Windows nicht deaktiviert / entfernt, also wie sollen wir sie verteilen?.
Ich weiß, das ist etwas rhetorisch, aber es dient dem Zweck. Ich sollte nur in der Lage sein, das Build-Verzeichnis zu zippen und zu verteilen (oder ein Installationsprogramm, wenn dies gerechtfertigt ist).
Dann gibt es noch das Kompatibilitätsproblem, sehr viele Leute weigern sich immer noch, W10 zu installieren, also gibt es das auch...
Es ist jedoch gut zu hören, dass 3.0 in die Richtung geht, so sehr ich xaml hasse, es wäre eine willkommene Ergänzung.
Vielleicht könnten wir es bekommen, ohne den gesamten 50-GB-UWP-Workload auch in VS installieren zu müssen? 🙏 (übertreibe ich weiß, aber trotzdem)

Um @MarkIngramUK am Anfang dieses Threads zu zitieren:

Es ist 2019, ich möchte eine schnelle, native Benutzeroberfläche und ich möchte nicht ernsthaft darüber nachdenken müssen, eine Benutzeroberfläche mit CreateWindowExW , GDI usw.

was ich (lustigerweise) buchstäblich gerade tun muss, und ja, es ist genauso schmerzhaft, wie es sich anhört :)

@nl-n wer hat etwas über den Laden gesagt? MSIX unterscheidet sich nicht wirklich von der Installation von MSI. Es ist nur ein App-Installer. Doppelklicken Sie darauf, um es zu installieren. Kein Laden erforderlich. Garantiert auch eine 100% saubere Deinstallation (im Gegensatz zu MSI, das ein riesiges Durcheinander verursacht)

Ich kenne keine einzige Person, die den Laden nicht deaktiviert/abgestreift hat

Es ist jedoch nicht üblich.

wie sollen wir sie verteilen

Zuallererst müssen Sie die Benutzer informieren, um den Store nicht zu deaktivieren.)

Ich sollte nur in der Lage sein, das Build-Verzeichnis zu zippen und zu verteilen

MSIX kann ohne Store installiert werden. Bei den neuesten Windows-Versionen muss der Benutzer dafür nichts aktivieren. Natürlich, wenn das Paket zuvor mit einem vertrauenswürdigen Zertifikat signiert wurde. Aber ja, wenn der Benutzer den Store vom PC entfernt hat, kann er auch den MSIX / APPX AppInstaller davon entfernen. In diesem Fall wollen sie wahrscheinlich nicht alle Anwendungsvariabilitäten.

sehr viele Leute weigern sich immer noch, W10 zu installieren,

Es ist ihre Wahl. sagte Nuff.

gesamte 50-GB-UWP-Workload auch in VS

Ein einzelnes SDK ist etwa 3 GB groß. Es ist nicht erforderlich, jeden ab 10240 herunterzuladen.

@nl-n wer hat etwas über den Laden gesagt? MSIX unterscheidet sich nicht wirklich von der Installation von MSI. Es ist nur ein App-Installer. Doppelklicken Sie darauf, um es zu installieren. Kein Laden erforderlich. Garantiert auch eine 100% saubere Deinstallation (im Gegensatz zu MSI, das ein riesiges Durcheinander verursacht)

Das war aus der Beschreibung, die Visual Studio Ihnen gibt, "zum Seitenladen / Installieren über den Microsoft Store". , was so ziemlich ein Killer für alles ist, was direkt mit der Winapi arbeitet. Und sie müssen signiert werden, um überhaupt installierbar zu sein?...

Es könnte sich auch einfach um gekreuzte Drähte handeln, zu viele unterschiedliche Terminologien, und ich weiß nicht viel über UWP.

Es ist jedoch nicht üblich.

Häufiger als man denkt, und das aus gutem Grund 😄

Wie auch immer, es war nicht meine Absicht zu entgleisen, also werde ich vorerst wieder an meinem CreateWindowExW-Zeug schreiben 🤣