Vielen Dank, dass Sie sich das Feedback der Community angehört haben. Ich bin wirklich gespannt auf WinUI 3.0 (Win32 + WinUI + C++). Das fühlt sich an wie der Rahmen, auf den wir gewartet haben! RIP GDI

(Win32-App-Modell) + (WinUI 3.0-Benutzeroberfläche) + (.NET- oder C++-Sprache)

Dies wäre also im Grunde die UWP-Benutzeroberfläche, aber ohne den telefonähnlichen Lebenszyklus und die Sandbox? Das scheint für Desktop-Apps interessant zu sein – ich werde damit experimentieren.

Vielen Dank für das Update, und hoffentlich werden weitere Updates folgen, da der anfängliche Funktionssatz von WinUI 3.0 gesperrt ist und alle neuen Steuerelemente oder Steuerfunktionen vorgeschlagen wurden, die es in WinUI 3.0 schaffen könnten.

Oh und eine Dokumentation darüber, wie WinUI in Desktop funktioniert und sich von UWP, WPF und Win32 unterscheidet, wäre sehr nützlich, um der unzähligen Anzahl von Fragen zuvorzukommen, die kommen werden.

Vielleicht eine schöne Matrix dessen, was in welcher Kombination von Frameworks und APIs enthalten ist, zusammen mit den Architekturdiagrammen, die wir bei Build!

Ihr seid unglaublich, danke für alles!
Die xplat-Sektion hat mir den Tag versüßt, vor allem, dass Uno auf dem Radar ist.

Unser Fokus liegt immer noch auf Windows 10 und 8.1, aber wir hören das Feedback, dass einige von Ihnen noch Benutzer und Kunden auf Win7 haben, und wir werden den Markt und die Optionen im Laufe der Zeit bewerten.

Angenommen, diese Implantation des UI-Frameworks wurde im Hinblick auf die Portabilität entwickelt, zumindest so weit, dass der UI-Kern (Rendering / Eingabe) unter jedem Windows-Betriebssystem funktionieren kann, das .NET Core 3+ unterstützt, was für Einschränkungen bei Windows 7 sogar vorhanden wäre Sein? Es scheint, als würden die meisten Funktionen, die die Leute auf dem Desktop verwenden, einfach funktionieren und für spezielle / plattformspezifische, die dies nicht tun, halten Sie sie möglicherweise davon ab, Teil des Kern-UI-Systems zu sein, und halten Sie sie in plattformspezifischen Paketen wie (Win10, Win8.1, Win7-Nugets usw.).

Auch wenn es ein plattformübergreifendes XAML gäbe, das auf allen Geräten (Win32, Android, iOS und WASM) das gleiche Aussehen und Verhalten hätte, wie Sie es mit HTML tun können (aber leider nicht Xamarin), wäre mein Unternehmen vor Jahren darauf gesprungen.

Ich bin auch froh, dass Sie dies als "Marathon (auch tolles Bungie-Spiel)" betrachten. Je weniger Fragmentierung im XAML-Raum, desto besser für alle und zu viele Abkürzungen werden Sie wieder dort zurückbringen, wo Sie angefangen haben ;)

Dokumentation darüber, wie WinUI in Desktop funktioniert und sich von UWP, WPF und Win32 unterscheidet, wäre sehr nützlich

Wir arbeiten daran und werden mehr teilen, wenn sich dies entwickelt!

Angenommen, diese Implantation des UI-Frameworks wurde im Hinblick auf die Portabilität entwickelt, zumindest so weit, dass der UI-Kern (Rendering / Eingabe) unter jedem Windows-Betriebssystem funktionieren kann, das .NET Core 3+ unterstützt, was für Einschränkungen bei Windows 7 sogar vorhanden wäre Sein?

@zezba9000 WinUI verwendet nicht .NET, und Sie müssen nicht unbedingt .NET Core mit WinUI verwenden: Es ist ein natives Framework, das auf Betriebssystem-APIs basiert und auf neue Funktionen in Win8/Win10 angewiesen ist, die in nicht vorhanden waren Win7 – in einigen Fällen für Kernfunktionen, nicht nur für Add-On-Funktionen auf höherer Ebene wie bestimmte Steuerelemente.

Dokumentation darüber, wie WinUI in Desktop funktioniert und sich von UWP, WPF und Win32 unterscheidet, wäre sehr nützlich

Wir arbeiten daran und werden mehr teilen, wenn sich dies entwickelt!

Angenommen, diese Implantation des UI-Frameworks wurde im Hinblick auf die Portabilität entwickelt, zumindest so weit, dass der UI-Kern (Rendering / Eingabe) unter jedem Windows-Betriebssystem funktionieren kann, das .NET Core 3+ unterstützt, was für Einschränkungen bei Windows 7 sogar vorhanden wäre Sein?

@zezba9000 WinUI verwendet nicht .NET, und Sie müssen nicht unbedingt .NET Core mit WinUI verwenden: Es ist ein natives Framework, das auf Betriebssystem-APIs basiert und auf neue Funktionen in Win8/Win10 angewiesen ist, die in nicht vorhanden waren Win7 – in einigen Fällen für Kernfunktionen, nicht nur für Add-On-Funktionen auf höherer Ebene wie bestimmte Steuerelemente.

Für die Kompatibilität mit Windows 7 wäre es erforderlich, dass ein Drittanbieter einen eigenen kompatiblen Renderer für XAML sowie eine Art alternatives Shim für alle benötigten APIs auf Betriebssystemebene erstellt.

Im Moment gibt es keine Ahnung, ob dies möglich ist - die Hoffnung besteht darin, dass die WinUI-Bits, wenn sie aus dem Betriebssystem entfernt werden, so in das Open-Source-Projekt eingefügt werden, dass andere Plattformen eine Art Kompatibilitätskomponente bereitstellen können. Denken Sie an Xamarin, Uno oder .Net Core mit einem benutzerdefinierten Renderer.

Es ist ein natives Framework, das auf Betriebssystem-APIs basiert und auf neue Funktionen in Win8/Win10 angewiesen ist, die in Win7 nicht vorhanden waren – in einigen Fällen für Kernfunktionen

Meiner Meinung nach wäre das, was eine "Kernfunktion" ausmacht, nicht etwas, das neben dem Rendern und der Eingabe auf Betriebssystemspezifika angewiesen ist. Was in diesen Fällen Abstraktionsschichten wären, die jeder erweitern kann. Auf einer grundlegenden Ebene sollte man theoretisch in der Lage sein, die Benutzeroberfläche mit einem benutzerdefinierten Software-Renderer zu rendern und auf Wunsch Eingaben mit einem benutzerdefinierten XInput-Backend mit einem virtuellen Cursor durchzuführen. Wenn Sie diese Art von Modularität können, können Sie so ziemlich alles tun, und die Erweiterung der Plattformunterstützung wird extrem einfach (wie in Spielen). Sie verbringen etwas mehr Zeit in dieser Gegend und die Straße hinunter erfordert alles viel weniger Aufwand. Wenn WPF-XAML auf diese Weise entworfen worden wäre, hätte es einfach in UWP-Apps verwendet und verwendet werden können. Technische Schulden werden sonst nur zu einer Endlosschleife.

Dinge wie Tray-Icon-Unterstützung usw. könnten in einem Paket "WinUI Windows-Grundfunktionen (Win7-Win10)" enthalten sein. Dinge wie Push-Benachrichtigungen könnten in einem Paket "WinUI Windows Extended Features (Win8-Win10)" enthalten sein.

Hoffe das macht Sinn.

@mdtauk , @zezba9000 theoretisch ist alles möglich, und wir haben viel Erfahrung im Bereich Plattformabstraktion im Team. Wie bei allem kommt es nur auf die Kosten, den Zeitplan und den erwarteten Nutzen an 😊

Zusätzlich zu den Entwicklungs- und Testkosten (die sich in potenziell nicht offensichtliche Bereiche erstrecken würden, beispielsweise um sicherzustellen, dass alles mit alten assistiven Technologien funktioniert) müssen wir auch die Supportkosten über lange Zeiträume berücksichtigen.

Erwarten Sie ab 2020 neue Kunden für Win7? Feedback und konkrete Anwendungsfälle helfen uns dabei, Prioritäten zu setzen.

Zusätzlich zu den Entwicklungs- und Testkosten (die sich in potenziell nicht offensichtliche Bereiche erstrecken würden, beispielsweise um sicherzustellen, dass alles mit alten assistiven Technologien funktioniert) müssen wir auch die Supportkosten über lange Zeiträume berücksichtigen.

Erwarten Sie ab 2020 neue Kunden für Win7? Feedback und konkrete Anwendungsfälle helfen uns dabei, Prioritäten zu setzen.

@jesbis Ich sehe keinen großen Vorteil darin, Win7 für WinUI 3.0 Kompatibilität hinzuzufügen - Linux, Android, iOS, iPadOS und MacOS können jedoch für die Bereitstellung einer plattformübergreifenden Lösung von Vorteil sein, die nicht auf native UI-Frameworks angewiesen ist.

@mdtauk
@jesbis Ich sehe keinen großen Vorteil darin, Win7 für WinUI 3.0 Kompatibilität hinzuzufügen - Linux, Android, iOS, iPadOS und MacOS können jedoch für die Bereitstellung einer plattformübergreifenden Lösung von Vorteil sein.

Stimmen Sie dem zu. Ich würde nur Web-Assembly hinzufügen, für mich ist es noch wichtiger als Linux.

Erwarten Sie ab 2020 neue Kunden für Win7? Feedback und konkrete Anwendungsfälle helfen uns dabei, Prioritäten zu setzen.

Nein, mein Unternehmen nicht. Ich habe eher ein Designargument in einem Bereich angeführt, in dem ich gesehen habe, wie XAML in all seinen Iterationen (aus meiner Sicht) zu kämpfen hatte, aber ich verstehe völlig, warum MS dort keine Zeit verbringen möchte. Es wäre jedoch cool, wenn WinUI in der Lage wäre, diese Arbeit bei Bedarf zu erledigen (was mir aufgefallen ist), ohne in ein Kaninchenloch von Windows-Abhängigkeiten zu geraten, wie es jetzt bei WPF der Fall ist.

Um klar zu sagen, was mein Unternehmen gerne sehen würde, ist die Unterstützung von Android und WASM etwas offizieller als die von UNO (und vor 3 Jahren). Wir stellen Verwaltungssoftware her, die den Status einer Sammlung lokaler Computer und System-Setups regelt, die normalerweise einen großen Bedarf an Win32-APIs mit sich bringen (UWP würde für uns nie funktionieren, aber wir mögen die Benutzeroberfläche aufgrund von Kompilierzeitfehlern im Gegensatz zu HTML-Build-Systemen) und unsere Clients + wir brauchen Win32 + Android + Browser-UI-Erfahrungen, die eine einheitliche Erfahrung und Haptik haben. HTML ist nur ein großer Schwachpunkt, da es unnötige Abstraktion und Komplexität hinzufügt, die ansonsten nicht vorhanden sein müssen, da unsere primäre Codebasis in C# liegt.

Hoffe das ist ein besseres Feedback für dich.

Ja, WASM ist das größte Ziel, das wir uns im Vergleich zu jeder anderen Plattform wünschen. BEI WEITEM!!
Da es unser Android / iOS / Mobile-Problem sowie Webportal-Zeug löst.

Vielen Dank, dass Sie sich das Feedback angehört haben!

Desktop + WASM wird Gold!

Wow, danke für den Gruß, @jesbis! Völlig unerwartet und sehr geschätzt und respektiert. 👍

Die Diskussion um Windows 7 lenkt ein wenig ab, da der Aufwand (ganz zu schweigen von den Kosten) zu einer deutlichen Verzögerung von WinUI 3.0 führen würde. Windows 7 endet im Januar, und wir ermutigen alle Kunden, auf Windows 10 zu aktualisieren. Meine Kunden sind hier möglicherweise nicht mit anderen überein, aber selbst Windows 8.1 ist keine Plattform, die für uns von Interesse ist.

Ziemlich zufrieden mit dem Update. Die kommenden Ziele für WinUI sehen sehr hell und vielversprechend aus! Sogar die Xplat-Sektion war etwas, das ich nicht erwartet hatte, aber sehr willkommen ist. Ich freue mich darauf, die Verbesserungen sowie die Goodies für WinUI zu nutzen.

Vielen Dank an das Team für die Transparenz.

Ich möchte die Bedeutung von Branchensoftware erwähnen, um Menschen bei der Lösung verschiedener Probleme zu helfen.

Ich habe eine Weile mit dem Lightswitch-Tool gearbeitet und hatte einen deutlichen Gewinn an Bauzeit. Die schnelle Anwendungsentwicklung war für LOB-Anwendungen sehr vielversprechend. Aber mit den Patentkriegen in den USA wird sehr ernst genommen, es dauerte das Produkt zu beenden.

Wir wissen, dass wir INotifyDataErrorInfo für die nächste Lieferung haben. Aber es wäre wunderbar, wenn WinUI RAD-Ressourcen für zukünftige Lieferungen wie ab 3.x hätte.

Danke, Team, kann den Tag kaum erwarten, an dem Sie die Webassembly einzeichnen. es wird meinen Tag, mein Jahr und mein Jahrzehnt ausmachen und MS an die Spitze des Technologiestapels stellen. WinUI + Xamarin + WASM + .NET => pure Großartigkeit !!

@jesbis Danke für dieses Update. Gutes Arbeitsteam :+1:. Wenn Sie verstehen, dass es noch früh ist, wann glauben Sie, werden WinUI 3.0-Meilensteine erstellt und Probleme damit gekennzeichnet?

Wann, glauben Sie, werden wir einen WinUI 3.0-Meilenstein erstellt und Probleme damit gekennzeichnet?

@shaggygi Gute Frage! Ich habe es gerade erstellt:

WinUI 3.0-Meilenstein

Das ist toll Jungs!

Kurze Frage:
Und im Zeitrahmen, um dies zu erwarten, würde dies 2-3 Monate oder länger dauern, wenn 3.0 verfügbar ist?

Wenn Sie in Zukunft über Jahre sprechen (wie in "bis Ende des Jahres"), können Sie sich bitte über Kalenderjahre und [Microsoft]-Geschäftsjahre klar werden.
Es ist leicht, Verwirrung zu stiften, wenn dies nicht ausdrücklich erwähnt wird, und ich kenne Fälle, in denen dies dazu geführt hat, dass die Leute glauben, dass die Dinge 6 Monate früher kommen als beabsichtigt.

Ist das Verschieben von Windows.UI.Composition in Microsoft.UI.Composition näher an 2.2 oder 3.0?

@jtorjo dies ist 3.0 (mindestens). Wir hoffen, einen frühen Build in die erste Vorschau von 3.0 aufzunehmen, aber noch nicht zu 100 % garantiert.

Wenn Sie in Zukunft über Jahre sprechen (wie in "bis Ende des Jahres"), können Sie sich bitte über Kalenderjahre und [Microsoft]-Geschäftsjahre klar werden.

@mrlacey danke, das werde ich mir

@jesbis Das ist irgendwie traurig. Sie meinen also, dass es möglich ist, dass wir Microsoft.UI.Composition in 3.0 nicht haben werden?

@jtorjo

Wir hoffen, einen frühen Build in die erste Vorschau von 3.0 aufzunehmen , aber noch nicht zu 100 % garantiert

Es gibt oft viele Vorschauversionen. .NET Core 3 befindet sich beispielsweise in Vorschau 6.

Unser Plan ist es, die Kompositions-APIs in 3.0 aufzunehmen.

Der Xaml-Framework-Teil wird jedoch vor dem Kompositionsteil Open Source sein.

@jesbis Danke, hört sich gut an!

Fantastische Roadmap, tolle Arbeit!

Wie alle hier liebe ich die Transparenz und freue mich sehr auf WinUI 3.0. Für mich ist WinUI 3.0 das Spannendste seit der Einführung von WPF im Jahr 2006.

Ich habe auch noch Kunden, die Windows 7 verwenden, aber ich denke, der Windows 10-Support ist am wichtigsten und ich würde keine Zeit und Ressourcen für den Win7-Support aufwenden. Die meisten Unternehmen, bei denen ich arbeite, wechseln auf 10. Und ich denke, Ende 2020 wird mein Zahnarzt wahrscheinlich mein Zahnarzt sein, der einzige, den ich kenne, der noch Windows 7 verwendet. Und wenn er mich bittet, eine Windows-App für ihn zu schreiben, migriere ich seine PCs auf Windows 10. :-)

WASM-Unterstützung in der Zukunft wäre großartig.

Gestern auf einer Konferenz:

Eine kleine Geschichte, um @jesbis und dem Team zu zeigen, dass wir, die wir hier schreiben und mitmachen, nur die Spitze des aufgeregten Eisbergs sind. :-)

Erst gestern habe ich auf einer Entwicklerkonferenz in Deutschland mit einigen .NET-Entwicklern gechattet und ihnen von WinUI 3.0 erzählt, aber sie wussten nichts davon. Ich erzählte ihnen von der Roadmap und sie sagten:

"Wow, das ist beeindruckend".

Ein Mädchen der Gruppe fragte mich:

"Aber darfst du uns das alles erzählen?"

Ich sah sie und die anderen an und nutzte dann die Gelegenheit für eine rethorische Pause von

await Task.Delay(3000);

bevor ich sagte

"Zur Hölle ja! Das kannst du alles auf GitHub lesen".

Danke @jesbis und alle Beteiligten. Tolle Zeiten, um ein Windows-Entwickler zu sein ❤️

Ich hoffe, Erstanbieteranwendungen (wie Word?) können die Ebenen von WinUI nutzen, und Entwickler würden sich freuen, wenn "Hey, WinUI ist ein echtes Ding, das Geschäfte abwickeln kann, und kein Spielzeug".
Wenn sie es bereits verwenden, sagen Sie es laut.

Acryl für WPF, Win32 und WinUI Desktop.

Oh, und vielleicht überdenken Sie die Richtlinie für Acryl nur bei aktiven Fenstern.

Ja, wenn Sie mehr als 1 Monitor haben, wird es nur in einem Fenster gerendert. Zumindest bei mehreren Monitoren sollte es einwandfrei funktionieren....

Ich habe über die Auswirkungen auf die Entwicklungserfahrung nachgedacht, wenn zwei Sätze von UI-Steuerelementen in UWP-Apps verfügbar sind – wenn wir sowohl auf WinUI-Steuerelemente als auch auf Legacy-UI-Steuerelemente zugreifen können, wenn wir in C#-Code-Behind IntelliSense verwenden, da wir immer korrekt arbeiten müssen Wählen Sie den Namespace aus, aus dem das Steuerelement stammen soll, anstatt Alt + Eingabetaste zu gehen, um einfach using hinzuzufügen und fortzufahren. Kann man das irgendwie vermeiden?

Sobald WinUI3 für Entwickler verfügbar ist, sollten die Windows 10-SDKs in Betracht ziehen , den Namensraum für Projekte zu ändern, die mit einem unterstützten installierten SDK geöffnet werden. Versuchen Sie, die Leute von den OS-Namensräumen wegzubewegen.

Acryl für WPF, Win32 und WinUI Desktop.

Was ich zuerst sehen möchte, ist, dass MS Xaml Islands genug reift, so dass beispielsweise Acryl in der Titelleiste für Nicht-UWP-Projekte verwendet werden kann, die ihre Benutzeroberfläche auf WinUI basieren (siehe letzten Absatz dieses Beitrags ). @marb2000 ist wahrscheinlich die Person, die danach fragt.

@MartinZikmund Dieses Szenario wollen wir vermeiden. Wenn Sie WinUI 3 verwenden, sollten Sie nur Zugriff auf die Steuerelemente des Pakets haben. Die Idee ist, dass wir alles haben, was Sie brauchen, mit den neuesten und größten Änderungen.

@MartinZikmund
@LucasHaines

Ein Fix sollte sein, dass Sie Windows.UI.Xaml.* WinMD-Referenzen vom Build ausschließen können. Jetzt verweisen die Build-Ziele nur auf das Unified WinMD aka. Windows.winmd , fügen Sie eine Option in den Zielen hinzu, um auch auf einzelne WinMDs zu verweisen. Auf diese Weise können wir die Referenzen basierend auf der von uns erstellten App ein- oder ausschließen.

Ist dies der Fall, müssen Namespaces nicht geändert werden, da es sich wie ein .NET dll verhält, das mit Assembly-Umleitungen zu einer lokalen Version innerhalb des Pakets anstelle der vom System bereitgestellten arbeiten kann.

Ich weiß, dass diese Methode speziell für .NET Framework gedacht ist, aber für UAP sollte es eine Lösung für diese Art von Szenarien geben. Ich weiß, dass es FrameworkDependency auf dem msix/appx Manifest gibt. Vielleicht können wir damit die neue WinUI mit Windows.* Namespaces statt mit Microsoft.* -Namensräumen versorgen.

Auf der Entwicklerseite hätten wir weniger Mühe, unsere Apps zu aktualisieren, da wir nur die Referenz und nicht den Code ändern!

Ich würde es vorziehen, den Namensraum überhaupt nicht zu ändern!

Leistungen:

1. Sie müssen den Code nicht hin und her ändern.

2. Sobald der lokale WinUI-Code stabilisiert wurde, können Sie ihn wieder in die Windows-Plattform einbinden, sodass System-Apps und LOB-Apps die neuen Verbesserungen bei jeder neuen Windows-Version nutzen können.

3. Einerseits ist es ein hochstabiles Systemframework mit hoher Kompatibilität wie .NET Framework. Auf der anderen Seite ist es wie bei .NET Core, mit schnelleren Änderungen, mit allen Vorteilen von beiden und ohne die Probleme.

Ich habe gerade eine großartige Präsentation von Steve Sanderson über Blazor + (ohne HTML) UI gesehen, die in eine plattformübergreifende native App eingebettet ist. Ungefähr 52 Minuten im Video. Ein Muss für UWP-, WinUI- und c#-Fans. Ich bin ernsthaft beeindruckt von Blazer !!!

https://youtu.be/uW-Kk7Qpv5U

Eine Sache, die ich in diesen Diskussionen vergessen habe zu sagen, die ich für wichtig halte, ist...
Hat WinUI 3.0 selbst Leistungsverbesserungen? Ist die XAML-Rendering-Engine gerade entkoppelt oder ändert sie sich? Werden XAML-Steuerelemente hauptsächlich Composition verwenden und somit Off-Thread- und Dwm-gesteuert wie DirectUI?

Die Leistung einiger Steuerelemente und die RAM-Auslastung könnten viel besser sein, wie ListView/GridView = ItemsControl.

Sie sehen dies unter Windows selbst. Das Startmenü von Windows 8 (DirectUI) ist viel flüssiger als das XAML-Startmenü von Windows 10.
Versuchen Sie, eine GridView mit genügend Informationen zu laden, z. B. die Seite Groove-Alben, und die Dinge laufen nicht so gut. Dies ist etwas, das sich iOS und Android viel besser verhalten, ebenso wie Winforms, QT.
(WPF ist meiner Meinung nach noch schlimmer als UWP XAML).

Hat WinUI 3.0 selbst Leistungsverbesserungen? Ist die XAML-Rendering-Engine gerade entkoppelt oder ändert sie sich? Werden XAML-Steuerelemente hauptsächlich Composition verwenden und somit Off-Thread- und Dwm-gesteuert wie DirectUI?

In die Performance möchten wir definitiv weiter investieren, aber ich würde keine Verbesserungen für 3.0 erwarten. Die anfänglichen 3.0-Anstrengungen konzentrieren sich hauptsächlich auf die Entkopplung von Xaml, um es als NuGet-Paket und Open-Sourcing zu versenden.

WinUI 3.0 (wie heute UWP Xaml) basiert auf der Kompositionsebene und führt einen Großteil des Renderings und der Animation außerhalb des Threads über das DWM aus.

Dies ist etwas, das sich iOS und Android viel besser verhalten, ebenso wie Winforms, QT.
(WPF ist meiner Meinung nach noch schlimmer als UWP XAML).

Bei der Betrachtung dieser Szenarien gibt es oft einen Kompromiss zwischen Leistung und Flexibilität/Reichtum. Xaml-basierte Plattformen (einschließlich UWP und WPF) haben in der Regel größere, reichhaltigere UI-Objektbäume für jedes Steuerelement: Dies bietet viel Flexibilität beim Ändern des Stils und der UX jedes Steuerelements, während einige andere Plattformen in der Regel viel flachere Objektbäume haben die nicht so flexibel sind, aber manchmal schneller geladen werden können.

Dieser Kompromiss ist definitiv etwas, über das wir nachdenken und das wir bei möglichen zukünftigen Änderungen berücksichtigen werden. Die zusätzliche Flexibilität komplexer Xaml-Steuerelementvorlagen ist oft nicht erforderlich, sodass wir möglicherweise Steuerelemente vereinfachen können, um sie schneller zu laden, wenn Sie keine zusätzliche Flexibilität benötigen.

Ich hoffe, Microsoft kann eine neue comctl32.dll und comdlg32.dll bereitstellen, die auf WinUI 3.0 basieren.

Weil die meisten Win32-Apps über die moderne Benutzeroberfläche verfügen und es den Entwicklern hilft, ihre Apps an die moderne Benutzeroberfläche anzupassen.

Viele Win32-Entwickler müssen mehrere Windows-Versionen anpassen. Daher können sie WinUI heute nicht direkt verwenden. Es ist ausgezeichnet, wenn Microsoft eine Methode bereitstellen kann, mit der sie den Arbeitsaufwand bei der Modernisierung der Benutzeroberfläche ihrer Apps reduzieren können.

Außerdem hoffe ich, dass Microsoft XAML-Designer für C++-Win32-Apps bereitstellen kann, die WinUI verwenden.

Kenji Mouri

@MouriNaruto Sie können FileOpenPicker heute verwenden (ab Win32).

@MouriNaruto Sie können FileOpenPicker heute verwenden (ab Win32).

Ich weiß, aber ich hoffe, dass alle modernen gebräuchlichen Steuerelemente und Dialogfelder Win32 bringen.

@MouriNaruto

Technisch ist es möglich. Aber die Windows-Entwickler müssen nicht nur das genaue Verhalten der COMCTL und COMDLG Implementierungen neu erstellen, sondern auch die bekannten und unbekannten Fehler, die in der Codebasis existieren.

Kompatibilität ist unser frenemy !

Selbst wenn sie es tun, würde jede Software, die diese Bibliotheken verwendet, genug Zeit haben, um auf WinUI zu migrieren, wenn sie es fertigstellen! Die Ironie!! 🤨🤣

@MarkIngramDE

Zu Ihrer Information : FileOpenPicker ist kein natives WinRT-Dialog-/Steuerelement. Es ist im Wesentlichen ein Wrapper von ExplorerFrame der selbst in DirectUI (entwickelt vom ATG Team und basierend auf DirectX ) und COM !

Technisch ist es möglich. Aber die Windows-Entwickler müssen nicht nur das genaue Verhalten der COMCTL- und COMDLG-Implementierungen neu erstellen, sondern auch die bekannten und unbekannten Fehler, die in der Codebasis vorhanden sind.
Kompatibilität ist unser frenemy!
Selbst wenn sie es tun, würde jede Software, die diese Bibliotheken verwendet, genug Zeit haben, um auf WinUI zu migrieren, wenn sie es fertigstellen! Die Ironie!! 🤨🤣

Ich glaube nicht, dass es für viele Projekte einfach ist, auf WinUI zu migrieren, ohne dies aufgrund der Realität.

Sie haben gesagt: "Kompatibilität ist unser Frenemy!". Ja, das ist auch einer der Gründe für meine Vorschläge. Die Ironie!! 🤨🤣

Ich würde mich nur über eine XAML-WinUI-Version der allgemeinen Dialoge freuen, auch wenn WPF und WinForms sich für die Verwendung der neuen Versionen anmelden müssten.

Das WinUI 3 Target klingt sehr spannend und ich freue mich darauf. Ich habe einige Fragen zur Verteilung/Bereitstellung im Kontext einer klassischen Win32-Anwendung mit WinUI 3

1. Muss jede App ihre WinUI-Bibliothek mitbringen oder ist die gemeinsame Nutzung zwischen Apps möglich, möglicherweise sogar automatisch über Windows-Mechanismen
2. Wird es möglich sein, WinUI statisch zu verknüpfen?
3. Sagen wir, ich muss es neu verteilen, wie groß wird WinUI ungefähr in MB sein?

Muss jede App ihre WinUI-Bibliothek mitbringen oder ist die gemeinsame Nutzung zwischen Apps möglich, möglicherweise sogar automatisch über Windows-Mechanismen

Wir planen, WinUI 3 hauptsächlich über NuGet zu verteilen, das über Mechanismen zum automatischen Zwischenspeichern und Freigeben von Paketen verfügt. Weitere Informationen finden Sie hier:

https://docs.microsoft.com/nuget/what-is-nuget#what-else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

Wird es möglich sein, WinUI statisch zu verknüpfen?

Das haben wir derzeit nicht geplant - haben Sie ein Szenario im Sinn, in dem dies von Vorteil wäre?

Sagen wir, ich muss es neu verteilen, wie groß wird WinUI ungefähr in MB sein?

Wir arbeiten noch daran, wie das endgültige Abhängigkeitsdiagramm aussehen wird, aber für die UI-Teile wird es wahrscheinlich den relevanten vorhandenen system32-DLL-Größen (10 MBs) ähneln.

Wir planen, WinUI 3 hauptsächlich über NuGet zu verteilen, das über Mechanismen zum automatischen Zwischenspeichern und Freigeben von Paketen verfügt

Ich dachte, Nuget ist nur für die Entwicklung oder übersehe ich etwas? Soweit mir bekannt ist, müssen Nuget-basierte Pakete von jeder App einzeln bereitgestellt werden und können nicht geteilt werden. Aus diesem Grund gibt es dedizierte Installer für eine gemeinsame Dotnet-Core-Laufzeit, ansonsten wäre es nicht notwendig, wenn man bedenkt, dass Dotnet-Core-Pakete bereits auf nuget sind ...

Sie sollten keine Entwicklungstools oder SDKs installieren müssen, nur um die UI-Framework-Pakete freizugeben. WPF und WinForms für .NET Core hatten das gleiche Problem und investierten in den Aufbau eines freigegebenen Bundles, damit die Leute das SDK nicht auf Endbenutzercomputern installieren müssen Holen Sie sich in das WindowsDesktop-Bundle ein)

Insbesondere gibt es in VS bereits Build-Optionen für die Framework-abhängige Bereitstellung und WinUI sollte diese nutzen, um sicherzustellen, dass die Pakete gemeinsam genutzt werden. Natürlich müssen sie zuerst ein gemeinsam nutzbares Paket bereitstellen.

Für Apps, die vom Microsoft Store bereitgestellt werden, sollte der Inhalt des Releasepakets auch automatisch bei der Bereitstellung freigegeben werden.

Für Win32-Apps, die auf andere Weise bereitgestellt werden, steht es auf unserer Todo-Liste, um Optionen wie die von Ihnen erwähnten zu untersuchen 😊

Wird es möglich sein, WinUI statisch zu verknüpfen?

Das haben wir derzeit nicht geplant - haben Sie ein Szenario im Sinn, in dem dies von Vorteil wäre?

Ich denke, ich muss klarstellen: Wird es möglich sein, WinUI in einer statisch verknüpften EXE zu verwenden (die die VC-Runtime statisch verknüpft)? Ich gehe davon aus, dass das wegen C++/WinRT kein Problem sein sollte, aber ich wollte nur sicher gehen ...

Sagen wir, ich muss es neu verteilen, wie groß wird WinUI ungefähr in MB sein?

Wir arbeiten noch daran, wie das endgültige Abhängigkeitsdiagramm aussehen wird, aber für die UI-Teile wird es wahrscheinlich den relevanten vorhandenen system32-DLL-Größen (10 MBs) ähneln.

Danke für die Information.

Tolle Transparenz übrigens für so ein riesiges Unterfangen, gefällt mir sehr gut.

Ich denke, ich muss klarstellen: Wird es möglich sein, WinUI in einer statisch verknüpften EXE zu verwenden (die die VC-Runtime statisch verknüpft)? Ich gehe davon aus, dass das aufgrund von C++/WinRT kein Problem sein sollte, aber ich wollte nur sicher sein

Dies sollte (theoretisch) möglich sein, aber wie @jesbis sagte, arbeiten wir noch an der Geschichte, wie unverpackte Apps in das gemeinsame Framework gelangen werden. Möglicherweise benötigen wir ein Redist-Installationsprogramm, wie es .NET Core macht.

Die Diskussion um Windows 7 lenkt ein wenig ab, da der Aufwand (ganz zu schweigen von den Kosten) zu einer deutlichen Verzögerung von WinUI 3.0 führen würde. Windows 7 endet im Januar, und wir ermutigen alle Kunden, auf Windows 10 zu aktualisieren. Meine Kunden sind hier möglicherweise nicht mit anderen überein, aber selbst Windows 8.1 ist keine Plattform, die für uns von Interesse ist.

Du hast recht. Aber wir können meinen Kunden nicht kontrollieren und es gibt mehr als 60% des Systems win7 in China. Und wir können diesen Markt nicht aufgeben, also können wir keine Technologie einsetzen, die win7 nicht unterstützt.

Die Daten stammen von Baidu, siehe https://tongji.baidu.com/data/os

Aber wir können meinen Kunden nicht kontrollieren und es gibt mehr als 60% des Systems Win7 in China

TBH Ich würde einfach bei .NET Framework 4.8 + WPF bleiben, wenn Sie auf Win7 hängen bleiben.

Aber wir können meinen Kunden nicht kontrollieren und es gibt mehr als 60% des Systems Win7 in China

TBH Ich würde einfach bei .NET Framework 4.8 + WPF bleiben, wenn Sie auf Win7 hängen bleiben.

Aber das Win7 Sp1 kann .NET Framework 4.8 installieren und das Win7 ohne sp1 kann es nicht installieren.

.NET Framework-Systemanforderungen |

Wenn Sie noch nicht einmal SP1 haben, ist das Lebensende bereits 6 Jahre überschritten.

Der Support für Windows 7 RTM ohne Service Packs endete am 9. April 2013.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Wenn Sie Unterstützung für Windows 7 wünschen, sollten Sie eine Technologie verwenden, die bereits Windows 7 unterstützt, und nicht erwarten, dass Microsoft dieses Problem für Sie löst.

@MarkIngramUK Es ist nicht so, dass Microsoft dieses Problem für mich gelöst hat, aber ich kann meine Kunden, die win7 ohne sp1 verwenden, nicht unterstützen. Ich kann unsere Kunden nicht kontrollieren, um irgendein System zu verwenden, aber diejenigen, die win7 ohne sp1 verwenden, werden unsere Anwendung aufgeben und das bedeutet, dass wir diesen Markt verloren haben. Aber meine Konkurrenten, die die neue Technologie nicht verwenden, können win7 ohne sp1 unterstützen und meine Konkurrenten werden diesen Markt gewinnen.

Traurig, aber wahr, zu viele Kunden kümmern sich nicht darum, welche Technologie wir verwenden, aber sie kümmern sich darum, dass die Anwendung auf allen ihren Geräten gut läuft.

Dies ist der Status Quo meiner Branche, und die obigen Schlussfolgerungen sind möglicherweise nicht für andere Branchen geeignet.

@lindexi wie gesagt, Sie können nicht erwarten, dass neue Technologien auf ein Betriebssystem portiert werden, das bereits 6 Jahre nach dem Ende des

@lindexi Ich denke, wenn der Kunde keine unterstützte Technologie verwenden möchte und etwas veraltetes bevorzugt, kann er vernünftigerweise keine moderne Benutzeroberfläche erwarten. Diese beiden Anforderungen schließen sich gegenseitig aus...

@MarkIngramUK Traurig. Ich denke, wenn ich die neue Technologie von heute nutzen kann, ist diese neue Technologie zu einer alten Technologie geworden.

@lindexi das ist buchstäblich das Gegenteil von dem, was passiert. Man kann neue Technologie nicht als „alte Technologie“ bezeichnen, nur weil sie nicht auf ein altes Betriebssystem portiert wird. Wenn Sie Win7 (kein SP1) unterstützen möchten, verwenden Sie WinForms oder MFC oder ähnliches.

@MartinZikmund Du hast recht. Tatsächlich verstehen fast keine unserer Benutzer Computertechnologie, selbst Win7 und Win10 können es nicht sagen. Es ist ihnen egal, welche Technologie wir verwenden.

@jesbis Ich würde gerne meine Hände mit der neuen WinUI mit C++ schmutzig machen. Ich habe in der Vergangenheit mein Bestes versucht, indem ich UWP und C++/Cx verwendet habe, aber abgesehen von der PhotoEditor-App und einigen Beispielen haben Sie sich immer am Kopf gekratzt und versucht, eine gute Dokumentation zu finden, z das. Das war einer der Gründe, warum ich für die UWP- und Qt-Entwicklung unter Windows wieder auf C# umgestiegen bin. Bitte zeigen Sie C++ mehr Liebe.

Bei meinen Kunden habe ich einen USB-Stick (PenDrive) mit dem Windows 10 Media verwendet und diesen einfach kostenlos von Windows 7 auf das neueste Windows 10 aktualisiert. Sie profitieren von einem modernen Betriebssystem mit Antivirus, Windows-Updates, Edge WebBrowser und unterstützen GUI-Technologien von älteren wie WinForms, WPF bis hin zu neueren einschließlich UWP und darüber hinaus (WinUI). Außerdem habe ich Windows anstelle von Herunterfahren in den Ruhezustand versetzt und den Benutzern beigebracht, einfach den Netzschalter zu drücken, um mit der Arbeit mit dem PC zu beginnen, und den Netzschalter zu drücken, wenn der PC fertig ist.
Außerdem habe ich eine ISO im Netzwerk installiert, um Maschinen einfach zu installieren / zu aktualisieren.

Und sie haben den Vorteil, dass Candy Crush auch auf ihren Computern vorinstalliert ist!

Meinung

Ich dachte, die Steuerimplementierungen von WPF können in WinUI für die Unterstützung der alten Windows-Version zusammengeführt werden. (Zum Beispiel Windows 7.) Aber es ist zu schwer für Microsoft, es wahr zu machen wegen der Büropolitik, lol.

Antworten

@lindexi
Ich weiß, dass es heute in China viele Benutzer veralteter Windows-Versionen gibt. Aber ich denke, es ist heute notwendig, Windows NT 5.x-Benutzer im Stich zu lassen, und ich weiß, dass es schwer ist.

@MartinZikmund

Ich denke, wenn der Kunde keine unterstützte Technologie verwenden möchte und etwas veraltetes bevorzugt, kann er vernünftigerweise keine moderne Benutzeroberfläche erwarten. Diese beiden Anforderungen schließen sich gegenseitig aus...

In China sind sowohl eine moderne Benutzeroberfläche als auch eine alte Plattformunterstützung erforderlich, wenn Sie nicht möchten, dass Ihre Arbeit für Minderheiten bereitgestellt wird. Einer meiner Freunde, ein chinesischer Entwickler, portiert Blink und V8 auf Windows XP, ohne dass Updates installiert sind. Viele Entwickler verwenden es, um ihre modernen App-Erfahrungen zu implementieren. In China entspricht die Mindestvoraussetzung für die Betriebssystemversion einer Version ohne installierte Updates . Wenn Sie beispielsweise wissen, dass die Betriebssystemversion einer App aus China Windows 7 ist, können Sie die App unter "Windows 7 RTM" oder "6.1.7600.16385 (win7_rtm.090713-1255)" verwenden. Auch in der Android-Welt unterstützen viele Apps heute noch Android 4.4.

Aus diesem Grund können die meisten Apps, die von nicht-chinesischen Entwicklern erstellt wurden, in China nicht die Mehrheitswahl sein.

PS Wir können das neueste Visual Studio 2019 verwenden, um Apps für Windows XP RTM zu erstellen, ohne dass Updates installiert sind , mit dem neuesten Windows 10 SDK und dem neuesten C++17-Standard oder C++20 jetzt ausprobieren. Wegen VC-LTL (https://github.com/Chuyu-Team/VC-LTL) und YY-Thunks (https://github.com/Chuyu-Team/YY-Thunks).

Hinweis zu meiner Person

Die meiste Zeit verwende ich den neuesten stabilen Windows-Build. (Ich verwende heute 10.0.18362. Ich verwende 19H1 und 19H2.) Aber meine Win32-Projekte, die für Windows Vista RTM ohne installierte Updates entwickelt wurden , und meine UWP-Projekte, die für Windows 10, Version 1703, ohne installierte Updates oder höher entwickelt wurden, weil die Bedingung Die XAML-Unterstützung wird in RS2 eingeführt. (Ich liebe bedingtes XAML. Warum ist es unter Windows 10 Build 14393 nicht vorhanden?)

Kenji Mouri

Bitte erwägen Sie, alle WinUI 3.0-Steuerelementklassen aufzuheben!

Nach meinem Verständnis hat Microsoft beschlossen, alle UWP-Steuerelementklassen zu versiegeln, da JavaScript (das keine Vererbung kennt) Probleme bei der Verwendung mit geerbten Klassen verursachte. Da JS/HTML nun veraltet ist, besteht für das neue UI-Framework keine Notwendigkeit mehr, alle Klassen zu versiegeln. Das Aufheben des Selaing würde es viel einfacher machen, UWP-Steuerelemente anzupassen, wie es in WPF immer möglich war. Beim Schreiben von benutzerdefinierten Virtualisierungslisten-Steuerelementen oder -Panels würde es auch sehr hilfreich sein, eine nicht versiegelte Virtualisierungsbasisklasse zum Vererben zu haben. Weder C# noch C++/CX oder C++/WinRT haben Probleme mit der Vererbung. Es war nur der Fehler namens JS/HTML, der uns dies aufzwang.

Entfernen Sie daher diese unnötige Einschränkung beim Erstellen von WinUI 3.0.

@gisfromscratch danke für das Feedback! Wir wollen auf jeden Fall die C++-Entwicklung unterstützen (insbesondere mit C++/WinRT).

Was würde die Verwendung von C++ erleichtern? Haben Sie C++/WinRT anstelle von CX ausprobiert?

Würden weitere Beispiel-Apps helfen?

Sie haben erwähnt, dass es schwierig war, eine Dokumentation zum Binden zu finden: Gab es andere spezifische Funktionen, die einer besseren Dokumentation bedürfen?

Bitte erwägen Sie, alle WinUI 3.0-Steuerelementklassen aufzuheben!

@lukasf das werden wir wahrscheinlich tun 🙂 In #780 läuft eine diesbezügliche Diskussion

@jesbis Ich muss meine Hände mit C++/WinRT viel mehr schmutzig machen. Ich bin gerade der C++/WinRT-Beispielanwendung Photo Editor gefolgt. Aber wenn Sie die bereitgestellten Links wie die Datenbindung eingehend durchlesen, landen Sie in vielen C#-Schnipseln und nur einigen Randnotizen wie "Für C++/WinRT ist jede Laufzeitklasse, die Sie in Ihrer Anwendung deklarieren, die von einer Basisklasse abgeleitet ist bekannt als zusammensetzbare Klasse. Und es gibt Einschränkungen bei zusammensetzbaren Klassen …". Diese Seite zielt auf 95 % C# und nur 5 % C++ ab.

@gisfromscratch danke! Wir werden dies bei der Aktualisierung der Dokumentation für WinUI 3 im Hinterkopf behalten.

Wenn es hilft, verlinkt die von Ihnen erwähnte Datenbindungsseite auch auf einige separate Seiten, die sich speziell auf die Datenbindung mit C++/WinRT beziehen, z.

XAML-Steuerelemente;

Steuerelemente für XAML-Elemente;

Es gibt auch eine Reihe anderer C++/WinRT-spezifischer Themen in diesem Abschnitt.

Danke für deine tollen Jobs! Sehr froh zu sehen, dass Xaml Island aus WinUi 3.0 entfernt wurde.
Übrigens: Ich frage mich nur, ob sich die Low-Level-Implementierung der Sprachprojektion in WinUi 3.0 von der WinRT-Komponente unterscheidet. Die Implementierung der Sprachprojektion der WinRT-Komponente scheint im .NET UWP-Projekt sowohl in der Kompilierzeit als auch in der Laufzeit einen großen Leistungseinbruch zu haben. Da WinUi 3.0 vollständig von UWP entkoppelt ist, hoffe ich, dass es einige Verbesserungen bei der Sprachinterop-Implementierung geben kann.

@zenjia XAML Islands wird nicht aus WinUI 3 entfernt. WinUI 3 enthält die APIs, die es WPF/WinForms/MFC-Apps ermöglichen, WinUI 3-Steuerelemente zu hosten.

Ich habe versucht, den Fortschritt in WinUI zu verfolgen. Ich habe in der Vergangenheit versucht, UWP-Apps mit C# zu schreiben, stellte jedoch fest, dass es ein harter Kampf war. Aber ich bin gespannt, es nach Winui 3.0 erneut zu versuchen.

Ich habe Fragen zur Winui-Roadmap. Hier sind vier. Tut mir leid, wenn sie woanders behandelt wurden. Ich habe die Antworten trotz viel Suchens nicht gefunden... lass es mich wissen, wenn es ein besseres Forum gibt, um diese Art von Fragen zu stellen.

• Werden die .net-Wrapper für die nativen Steuerelemente auch Open-Source sein? Es ist nicht klar, ob dies das Github-Repro ist, das für die .Net- Seite von winui verantwortlich ist, wenn man bedenkt, dass der einzige c#-Code, den ich zu finden scheine, für automatisierte Tests gilt. Ich suche nach Dingen wie Microsoft.UI.Xaml.UIElement, kann diesen Code aber nirgendwo finden.

• Werden das UWP-Appmodel und das Win32-Appmodel bei der Veröffentlichung von winui 3.0 dieselbe .Net Core-Laufzeit ausführen? Ich habe nie ganz herausgefunden, welche Version von .Net Core von UWP-Anwendungen verwendet wird. Ich kann mir vorstellen, dass es etwas ist, das in Windows selbst integriert ist und dass die Windows 10-SDKs es VS 2019 ermöglichen, auf die richtige Version des .Net-Kerns abzuzielen, die in UWP verfügbar ist.

• Eine Frage zu den Xaml-Inseln. Besteht die Möglichkeit, dass WPF und UWP den gleichen Luftraum teilen? Ich freue mich nicht darauf, mich mit Luftraumproblemen zu befassen, wie wir es zwischen Winforms und WPF getan haben. Angesichts der Tatsache, dass WPF und UWP beide auf Direct-X basieren, wäre es großartig, wenn sie Pixel miteinander teilen könnten. Wenn ich beispielsweise ein Backstage-Menü auf einem Menüband (in WPF) hätte, das eine UWP-Xaml-Insel überlagern muss, wäre es wunderbar, wenn dies nahtlos passieren könnte. Es scheint nicht so, als ob ich für so etwas durch Tonnen von Reifen springen sollte. ... Ich erinnere mich, dass in den frühen Tagen von WPF versucht wurde, Luftraumprobleme für Clientanwendungen zu lösen, die das Winforms-Steuerelement "WebBrowser" verwenden wollten. Sie haben eine Funktion des Webbrowsers namens "WebBrowser.CompositionMode" getestet, die es dem WebBrowser ermöglichen sollte, mit WPF gut zu spielen. ... Aber ich denke, diese Strategie wurde schließlich aufgegeben. Vielleicht könnte die Interoperabilität zwischen UWP und WPF so nahtlos sein, dass sie sogar Pixel miteinander teilen könnten (im Gegensatz zu Winforms und WPF). Ein potenzieller Vorteil davon wäre, dass WPF die Funktionalität eines UWP-Steuerelements verbessern könnte. WPF könnte beispielsweise eine Xaml-Insel mit zusätzlichen visuellen Elementen auf eine Weise überlagern, die einer Adorner-Ebene entspricht. Das könnte zur Not praktisch werden.

• Besteht die Möglichkeit, dass eine WPF-App mit Xaml-Inseln (sagen wir 50% WPF und 50% WINUI) eines Tages nativ auf ARM64 kompiliert wird? Das Targeting von ARM ist mit Anwendungen möglich, die zu 100 % UWP sind, und es wäre schön, wenn WPF-Abhängigkeiten uns nicht zwingen würden, unser natives ARM64-Targeting aufzugeben. (Die Alternative wäre, die App in der x86-Emulation auszuführen - aber das ist langsamer und begrenzt den verfügbaren Speicher, der verwendet werden kann).

Hoffentlich sind diese Fragen alle relevant für die Roadmap von winui. Jeder Rat wäre dankbar.

Werden die .net-Wrapper für die nativen Steuerelemente auch Open-Source sein? Es ist nicht klar, ob dies das Github-Repro ist, das für die .Net-Seite von winui verantwortlich ist, wenn man bedenkt, dass der einzige c#-Code, den ich zu finden scheine, für automatisierte Tests gedacht ist. Ich suche nach Dingen wie Microsoft.UI.Xaml.UIElement, kann diesen Code aber nirgendwo finden.

UIElement ist nicht in WinUI 2 enthalten und befindet sich daher derzeit nicht im Repository. Es wird in WinUI 3 sein, das noch nicht veröffentlicht oder Open Source ist, aber wir arbeiten daran!

Sie können Beispiele im Repo anderer nativer Steuerelemente sehen, die .NET über WinRT-Projektionen ausgesetzt sind, zB die hier dokumentierten WinUI 2.2-Steuerelemente. Sie benötigen meistens keine bereits existierenden Wrapper-Dateien pro Sprache, weshalb Sie keine .cs-Dateien im Repository finden.

@marb2000 könnte die Inseln/Desktop-Fragen am besten kommentieren.

F: _Werden WinUI 3 UWP und Desktop dieselbe .NET-Laufzeit verwenden?_
A: Ja, das ist der Plan. UWP und Desktop verwenden .NET Core 3. Verwaltete WinRT-Bibliotheken verwenden .NET Core 3 anstelle von .NET Native.

F: _Werden WPF und UWP denselben Luftraum teilen?_
A: Obwohl WPF und WinUI (und XAML UWP) ähnlich erscheinen, sind sie es nicht. WPF verwendet DirectX9 und WinUI/XAML UWP verwendet die Windows.UI.Composition für die Kompositions-, Rendering- und Animationsanforderungen von XAML (neben einer modernen Version von DirectX11). Dies führt leider dazu, dass der Interop sehr kompliziert ist. Ihr Vorschlag zu WPF-Adornern ist interessant. Theoretisch kann der Benutzer ein Popup erstellen, um den WinUI/XAML-Inhalt über den WPF-Inhalt zu platzieren. Oder es kann der visuellen WPF-Struktur mitteilen, dass ein Re-Layout erforderlich ist, jedoch alles basierend auf HWnds.
@dbeavon Dies ist ein guter Vorschlag, können Sie dafür eine Funktionsanfrage erstellen?

F: _Wird eine WPF-App mit Xaml Islands auf ARM64 kompiliert?_
A: Wenn .NET Core 3 für Windows ARM64 sicher unterstützt. Heute unterstützt es ARM32 in Windows. Unter Linux wird jedoch ARM64 unterstützt. Ich denke, es ist auf der .NET Core-Roadmap, ARM64 auch in Windows zu unterstützen. Obwohl AFAIN, gibt es noch kein Datum. @richlander , irgendwelche Neuigkeiten?

@marb2000

F: Werden WPF und UWP denselben Luftraum teilen?

Kann UWP Windows.UI.Composition verwenden, um eine Ebene zu erstellen, die das Rendern von einer DirectX-Bitmap abrufen kann? Und dann rendert das WPF die Fenster auf diese Ebene wie win2d. Vielleicht kann es sich den gleichen Luftraum teilen. Aber es ist schwierig, WPF so zu gestalten, dass es auf eine Ebene gerendert wird.

@linindexi Ich denke, das könnte der Himmel sein :D

Kann UWP Windows.UI.Composition verwenden, um eine Ebene zu erstellen, die das Rendern von einer DirectX-Bitmap abrufen kann?

UWP Xaml bietet eine Reihe von Möglichkeiten, DirectX-Bitmaps oder Swapchains in Xaml zu rendern und sie mit Windows.UI.Composition zusammenzusetzen, sodass sie denselben Luftraum teilen, einschließlich SurfaceImageSource , VirtualSurfaceImageSource und SwapChainPanel - weitere Informationen finden Sie hier:

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

Sie können auch ein Windows.UI.Composition-Visual in eine UWP-Xaml-UI-Struktur einfügen und DirectX-Inhalte darauf zeichnen, z. B. mit ICompositorInterop , ICompositionDrawingSurfaceInterop und ICompositionGraphicsDeviceInterop wie hier beschrieben:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

Diese Ansätze sollten mit WinUI ähnlich funktionieren.

Eine UWP-Desktop-App kann auf eine WPF/WinForm-DLL verweisen und ein WPF/WinFrom-Fenster öffnen? Dies würde es mir ermöglichen, schrittweise zu migrieren.

@marb2000 -- .NET Core für Windows ARM64 ist auf unserer Roadmap. Ich arbeite gerade an einem Plan dafür.

Wird es mit WinUI 3.0 möglich sein, win2d darüber zu kompilieren?
(also von UWP entkoppeln)
Wenn ja, wäre das wahnsinnig toll!

Wir arbeiten noch an Details zur DirectX-Integration, aber hoffentlich wird es möglich sein, Win2D zu aktualisieren, um WinUI-Basisklassen anstelle von UWP-Xaml-Basisklassen zu verwenden.

Daumen drücken :D

Entschuldigung, wenn dies nicht zum Thema gehört: Fehlerberichte zu UWP - füge ich ein Problem auf https://github.com/microsoft/microsoft-ui-xaml/ oder anderswo hinzu?

Entschuldigung, wenn dies nicht zum Thema gehört: Fehlerberichte zu UWP - füge ich ein Problem auf https://github.com/microsoft/microsoft-ui-xaml/ oder anderswo hinzu?

@jtorjo tolle Frage! Dieses Repo ist der beste Ort, um alle Probleme im Zusammenhang mit:

• die UWP-UI-Framework-APIs (z. B. Windows.UI.Xaml)
• Fließendes Design
• WinUI

Im Allgemeinen sollte sich am Ende der meisten Dokumentationsseiten auf docs.microsoft.com ein Link "Feedback zu diesem Produkt senden"

Für die meisten Aspekte von UWP, abgesehen von den oben genannten, besteht die Möglichkeit, Fehler in der Kategorie Entwicklerplattform im Feedback-Hub mit einer Reihe relevanter Unterkategorien zu melden.

Wird WinUI 3 das UWP SemanticZoom-Steuerelement enthalten? Ich denke, es ist die coolste Steuerung von allen.

@jesbis Danke! Habe gerade eine Diskussion über System.IO gepostet

Selbst Microsoft stellt die Unterstützung von Windows 7 für Office nicht ein, warum sollte WinUI 3 tun? Ich meine, fast alle seriösen Softwares haben Windows 7-Unterstützung (Photoshop, Office, Visual Studio 2019, VSCode, ...) Wenn WinUI Windows 7 nicht unterstützt ...

Selbst Microsoft stellt die Unterstützung von Windows 7 für Office nicht ein, warum sollte WinUI 3 tun? Ich meine, fast alle seriösen Softwares haben Windows 7-Unterstützung (Photoshop, Office, Visual Studio 2019, VSCode, ...) Wenn WinUI Windows 7 nicht unterstützt ...

Office wird den Support wahrscheinlich bald einstellen, da Microsofts Support für Windows 7 sehr bald endet. Es basiert jedoch auf einer Codebasis, die bereits Windows 7 unterstützt hat.

WinUI wurde auf Windows 10 aufgebaut und müsste daher auf Windows 7 zurückportiert werden. Der Aufwand, dies zu tun, macht keinen Sinn, wenn das Betriebssystem das Ende des Lebenszyklus erreicht, und die Benutzer müssen daher auf Windows 10 aktualisieren.

F: Werden WinUI 3 UWP und Desktop dieselbe .NET-Laufzeit verwenden?
A: Ja, das ist der Plan. UWP und Desktop verwenden .NET Core 3. Verwaltete WinRT-Bibliotheken verwenden .NET Core 3 anstelle von .NET Native.
F: Werden WPF und UWP denselben Luftraum teilen?
A: Obwohl WPF und WinUI (und XAML UWP) ähnlich erscheinen, sind sie es nicht. WPF verwendet DirectX9 und WinUI/XAML UWP verwendet die Windows.UI.Composition für die Kompositions-, Rendering- und Animationsanforderungen von XAML (neben einer modernen Version von DirectX11). Dies führt leider dazu, dass der Interop sehr kompliziert ist. Ihr Vorschlag zu WPF-Adornern ist interessant. Theoretisch kann der Benutzer ein Popup erstellen, um den WinUI/XAML-Inhalt über den WPF-Inhalt zu platzieren. Oder es kann der visuellen WPF-Struktur mitteilen, dass ein Re-Layout erforderlich ist, jedoch alles basierend auf HWnds.
@dbeavon Dies ist ein guter Vorschlag, können Sie dafür eine Funktionsanfrage erstellen?
F: Wird eine WPF-App mit Xaml Islands zu ARM64 kompiliert?
A: Wenn .NET Core 3 für Windows ARM64 sicher unterstützt. Heute unterstützt es ARM32 in Windows. Unter Linux wird jedoch ARM64 unterstützt. Ich denke, es ist auf der .NET Core-Roadmap, ARM64 auch in Windows zu unterstützen. Obwohl AFAIN, gibt es noch kein Datum. @richlander , irgendwelche Neuigkeiten?

Werden wir also die UWP-Sandbox los? Was wiederum bedeutet, dass UWP in seiner jetzigen Form auch wegfällt und damit die geschützte Sandbox des App Stores, wie wir sie kennen?

Werden wir also die UWP-Sandbox los? Was wiederum bedeutet, dass UWP in seiner jetzigen Form auch wegfällt und damit die geschützte Sandbox des App Stores, wie wir sie kennen?

Die UWP-Sandbox loszuwerden wäre wahnsinnig toll!

Das bedeutet definitiv nicht, dass UWP verschwindet. Die universelle Windows-Plattform ist die einzige Möglichkeit, das gesamte Spektrum von Windows-Geräten (PC, Xbox, HoloLens usw.) nativ zu erstellen, und hier konzentriert sich Windows auf seine Investitionen in native Plattformen. RE: Sandboxing im Besonderen: Appcontainer-Isolation bietet weiterhin viele wichtige Vorteile für Apps und Benutzer von UWP- und Desktop-Apps.

Die wichtigsten Änderungen sind:

• Wir erweitern den Umfang der UX-Plattform (dh WinUI), damit sie auch mit einem Desktop-App-Modell (win32) verwendet werden kann
• Wir entkoppeln WinUI von Windows, damit wir es häufiger aktualisieren, neue Funktionen abwärtskompatibel machen und es einfacher als Open Source verwenden können

Das bedeutet, dass Sie bei neuen Apps zwischen UWP- und Desktop-App-Modellen wählen können, je nachdem, was für Ihre App sinnvoll ist, und wenn Sie vorhandene Desktop-Apps (z. B. WPF, WinForms, MFC) haben, können Sie diese schrittweise mit modernen WinUI-Funktionalität mit Xaml Islands.

Werden wir also die UWP-Sandbox los? Was wiederum bedeutet, dass UWP in seiner jetzigen Form auch wegfällt und damit die geschützte Sandbox des App Stores, wie wir sie kennen?

UWP ist eine der Optionen zum Erstellen einer WinUI 3.0-App. Durch die Verwendung des UWP kann Ihre App auf Xbox, Hololens usw. ausgeführt werden.

Sie können aber auch eine Win32-App mit WinUI 3.0 erstellen und auf UWP-APIs zugreifen – aber wo Ihre App ausgeführt werden kann, wird es eingeschränkter sein.

@mdtauk @jesbis Ich bin total für UWP, aber zu diesem Zeitpunkt:

1. Kompilierungszeiten sind wahnsinnig langsam! (ziemlich viel, 6-mal langsamer als WPF - ich verwende die Zielversion Build 1809 - Build 17783)
2. Ich weiß, dass die StorageFolder-Dateiaufzählungs-API nicht Teil von UWP ist, aber das ist wahnsinnig langsam. Die UWP-Sandbox (zumindest auf dem Windows-Desktop) tut mehr weh, als dass sie hilft.
3. Sicher, asynchrone Programmierung macht Spaß, aber wenn in UWP eine Ausnahme auftritt, wird sie irgendwie vom UWP-Code gefressen und später im Debugger unterbrochen, wobei der gesamte Stapelkontext verloren geht. Manchmal habe ich den Stapelkontext innerhalb der ausgelösten Ausnahme selbst, aber nicht immer.
4. Profiling von UWP-Code ist nahezu unmöglich. Das Ereignis dotTrace bricht sofort ab, wenn es versucht wird.

(Ich habe über einen Monat gebraucht, um meinen Code von WPF auf UWP zu portieren, da ich wahnsinnig win2d brauche, also gibt es für mich keine Möglichkeit, UWP zu vermeiden.)

@mdtauk @jesbis Ich bin total für UWP, aber zu diesem Zeitpunkt:

1. Kompilierungszeiten sind wahnsinnig langsam! (ziemlich viel, 6-mal langsamer als WPF - ich verwende die Zielversion Build 1809 - Build 17783)
2. Ich weiß, dass die StorageFolder-Dateiaufzählungs-API nicht Teil von UWP ist, aber das ist wahnsinnig langsam. Die UWP-Sandbox (zumindest auf dem Windows-Desktop) tut mehr weh, als dass sie hilft.
3. Sicher, asynchrone Programmierung macht Spaß, aber wenn in UWP eine Ausnahme auftritt, wird sie irgendwie vom UWP-Code gefressen und später im Debugger unterbrochen, wobei der gesamte Stapelkontext verloren geht. Manchmal habe ich den Stapelkontext innerhalb der ausgelösten Ausnahme selbst, aber nicht immer.
4. Profiling von UWP-Code ist nahezu unmöglich. Das Ereignis dotTrace bricht sofort ab, wenn es versucht wird.

(Ich habe über einen Monat gebraucht, um meinen Code von WPF auf UWP zu portieren, da ich wahnsinnig win2d brauche, also gibt es für mich keine Möglichkeit, UWP zu vermeiden.)

Es wäre nützlich, wenn dies in diesem Thread Nr. 1517 gepostet würde und Sie hoffentlich einen Namen von jemandem aus dem SDK-Team aufnehmen können

@jtorjo

Kompilierungszeiten sind wahnsinnig langsam! (ziemlich viel, 6 mal langsamer als WPF

Verwenden Sie C++/WinRT? Wenn ja, verwenden Sie vorkompilierte Header?

@mdtauk hat gerade dort gepostet

@MarkIngramUK Es ist c#-Code

Abschluss – bitte richten Sie Roadmap und Alpha-Feedback an: #1531

Im Moment gibt es keine Ahnung, ob dies möglich ist - die Hoffnung besteht darin, dass die WinUI-Bits, wenn sie aus dem Betriebssystem entfernt werden, so in das Open-Source-Projekt eingefügt werden, dass andere Plattformen eine Art Kompatibilitätskomponente bereitstellen können. Denken Sie an Xamarin, Uno oder .Net Core mit einem benutzerdefinierten Renderer.

Steht das wirklich auf der Roadmap oder war das nur eine Vermutung?

@mdtauk , @zezba9000 theoretisch ist alles möglich, und wir haben viel Erfahrung im Bereich Plattformabstraktion im Team. Wie bei allem kommt es nur auf die Kosten, den Zeitplan und den erwarteten Nutzen an 😊

Es wäre vielleicht riesig, es auf eine Weise zu abstrahieren, die es einem Dritten ermöglicht, es auf Android oder iOS zum Laufen zu bringen. Ich bin sicher, die Community kann dies tun. Ich würde auf jeden Fall dazu beitragen.

@andreinitescu Entschuldigung für das Gerede und die Beschwerden, aber nur meine Gedanken von dem, was ich verstehe: Während ich WinUI 3 verwenden werde, um WPF für Windows / nur Win32 zu ersetzen ... Weil WinUI unter Windows eine Windows-nur Rendering-API und keinen Agnostiker verwendet Erstens scheint WinUI sich auf Dritte zu verlassen, um WinUI auf anderen Plattformen neu zu implementieren / zu fragmentieren (z von Anfang an entworfen). Anstatt ein tragbares wie Skia zu verwenden oder ein MS-Gerät zu erstellen. Verstehe auch nicht, dass die 1% der Leute, die C# nicht mit WinUI verwenden, unterstützt werden müssen, was C# in gewisser Weise zu einem zweitklassigen Ziel macht und was noch wichtiger ist, dass die Entwicklungszeit viel länger dauert. So wie Android Java + Post-AOT für viele Kernanwendungen verwendet, sollte Windows C# + Prä-AOT verwenden. Weil es Zeit spart. 70% der Fehler, die C++ verwenden, verwenden immerhin freigegebene PTRs.

Der Mangel an Kommunikation zwischen Gruppen in einem Unternehmen für langfristige Anwendungsfälle, wenn es immer mehr zu einem Problem wird, wenn sie ihr Android-Betriebssystem für mobile Plattformen veröffentlichen (die ich verwenden möchte) und mehr Leute darauf abzielen möchten mit MS-Tools... fühlen Sie sich in gewisser Weise wieder wie eine WinPhone7-ähnliche Situation. Der Begriff Windows sollte nicht mehr so ​​stark an den WinNT-Kernel gebunden sein. Ein Ökosystem ist mehr als eine einzelne Plattform oder das Framework eines Unternehmens, auf dem es aufbaut.

Schade, dass MS nicht tun kann/will, was Apple vor fast 20 Jahren mit der Umstellung von OS9 auf OSX getan hat. Insofern reißen Sie das Pflaster ab, indem Sie zu einem UNIX / LINUX-Kernel wechseln, ABER einen Emulator / Simulator für die nächsten 5-10 Jahre in das Betriebssystem integriert haben, während die Leute Software und Entwicklungstools migrieren, um nativ zu laufen. (Denk was du willst, aber ich kann träumen)