Microsoft-ui-xaml: 👩‍💻📞 WinUI Community Call (19. Februar 2020)

Ich habe eine Frage zur Entwicklung von Windows 10X. Um dafür zu entwickeln benötige ich den Emulator, wann wird es Unterstützung für AMD-Prozessoren (nested virtualization) geben? Können wir auf die Version von Windows 10 2003 zählen?

Mehr im Zusammenhang mit WinUI, basierend auf #1958, was ist die Zukunft von Live Tiles?

Die AMD Ryzen-Unterstützung hindert mich daran, den Emulator auszuführen, daher ist es gut zu hören, wann dies behoben wird.

@jp- weber @mdtauk

Dies ist der offizielle Wortlaut (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):

AMD-Prozessoren werden derzeit nicht unterstützt. Um Windows 10X im Emulator ausführen zu können, ist eine verschachtelte Virtualisierung erforderlich, und Windows unterstützt dies noch nicht auf AMD-Prozessoren. Bleiben Sie dran!

Wenn Sie weitere Informationen wünschen, wenden Sie sich wahrscheinlich an

Danke @Felix-Dev - das ist richtig, die Dokumentation ist der beste Ort, um den neuesten Status des 10X-Emulators zu erfahren, und diese E-Mail-Adresse ist der beste Kontakt für andere 10X-Fragen, die nicht spezifisch für WinUI sind.

Fair genug, muss warten, bis Microsoft bereit ist, darüber zu sprechen.

Bei Windows 10X werden Win32-Apps in einem VEIL-Container ausgeführt. Was ist mit WinUI 3.0-Nicht-UWP-Apps?

Werden sie wie native UWP-Apps auf 10X ausgeführt?

@mdtauk Da WinUI Desktop-Apps keine nativen UWP-Apps sind, glaube ich nicht, dass sie im UWP-Container ausgeführt werden. Ich glaube, sie werden in dem erwähnten Win32-Container ausgeführt, da sie (alle) die Fähigkeiten von Win32-Apps haben.

Ich bin auch daran interessiert, was der Plan für die zukünftige Isolierung von WinUI-Apps ist. Aus Unternehmenssicht benötigen wir Isolation/Sandboxing und Capability Control (kein Benutzer-Opt-in). Also, das hier als Thema für Miguel herausstellen..

@mdtauk Da WinUI Desktop-Apps keine nativen UWP-Apps sind, glaube ich nicht, dass sie im UWP-Container ausgeführt werden. Ich glaube, sie werden in dem erwähnten Win32-Container ausgeführt, da sie (alle) die Fähigkeiten von Win32-Apps haben.

Dies ist ein wenig enttäuschend. Win32-Apps scheinen ein anderes Fensterverhalten zu zeigen und verdunkeln den Bildschirm, wenn sie sich im Vordergrund befinden. Das Umschalten verhält sich also auch anders.

Wenn Sie eine Xaml-Benutzeroberfläche verwenden, hoffen Sie, dass eine WinUI-Desktop-App zumindest oberflächlich für den Benutzer das Beste aus beiden Welten ist

@mdtauk Da das aktuelle 10X-Emulator-Image, das uns veröffentlicht wurde, noch sehr früh ist, bin ich mir ziemlich sicher, dass die Probleme / das Verhalten, das Sie bemerkt haben (ich habe es in meinen Tests auch gemacht), bis zur Veröffentlichung behoben / geändert werden (dh ich habe auch Win32-Apps, die nur kann gerade nicht geladen werden).

Das heißt, ich freue mich über eine Korrektur im WinUI Desktop-App-Container auf 10X. Meine derzeitige Denkweise basiert auf dem, was wir bisher über WinUI Desktop (Win32-App-Modell), die 10X-Präsentation How Windows 10X runs UWP and Win32 apps und Desktop-Bridge-Test-Apps erfahren haben. Leider können meine XAML Island-Test-Apps derzeit nicht auf dem Emulator geladen werden (stecken in der App Launch Initialized Phase), sodass ich nicht überprüfen kann, welcher Container sie verwenden werden. Ich wäre überrascht, wenn es nicht der Win32-Container wäre, da es sich immer noch um Win32-Apps handelt. All dies lässt mich glauben, dass WinUI Desktop-Apps im Win32-Container auf 10X ausgeführt werden.

Es ist sicherlich eine gute Frage, das Team zu fragen!

@Felix-Dev gemäß dem gleichen Video, das Sie erwähnt haben (Wie Windows 10X UWP- und Win32-Apps ausführt) um 20:18 Uhr sagt, dass Hybrid-Apps (Win32 / UWP) (noch?) verwendet XAML Island ist eine Hybrid-App.

F1) Wann wird SwapchainPanel in WinUI verfügbar sein? Dies ist für das, was ich und viele andere tun, unbedingt erforderlich.

F2) Da SharpDX von seinem Entwickler nicht mehr unterstützt wird, wird Microsoft die Kompatibilität zwischen SharpDX und den Hardware-Rendering-Oberflächen von WinUI verbessern? Sieht MS überhaupt eine Geschichte für Hardware-Rendering mit C# ohne SharpDX? Und Unity ist mir egal, ich meine für die uneingeschränkte, freie Grafikentwicklung, für die Erstellung unserer eigenen Grafiktools, Engines und Nicht-Unity-Spiele in C#. Und ich meine auch nicht Win2d, ich benötige volle Hardware-Rendering-Fähigkeit (DirectX).

F3) Anwendungen können TaskBar- und TitleBar-Popups nicht deaktivieren, wenn die Maus an den oberen und unteren Bildschirmrand bewegt wird. Dies ist ein Deal-Breaker für viele Spiele (und vielleicht einige Apps), die den Bildschirmrand in ihrer eigenen Benutzeroberfläche für Dinge wie Kameraschwenk oder Popups verwenden. Wann wird dies behoben (dies kann ein Windows-Problem sein, aber es muss von einer API gesteuert werden, daher ist es für WinUI relevant).

F4) Können wir WinUI dazu bringen, das CoreWindow (IFrameworkView)-App-Modell einzuschließen, wenn wir Xaml umgehen und direkt in eine fenstergebundene Swapchain rendern möchten.

Es mag etwas seltsam klingen, dass WinUI eine Nicht-Xaml-Oberfläche bereitstellt. Aber ich denke, CoreWindow gehört mit XamlWindow (in UWP Window genannt) in dieselbe Bibliothek, die ebenfalls von UWP getrennt ist, um es in .net 5 verfügbar zu machen. Derzeit gibt es kein modernes C++-Anwendungsmodell außerhalb von UWP – Spieleentwickler müssen Legacy-C-Code (Win32) verwenden, um Anwendungsschichten für Spiele oder Grafik-Apps zu schreiben. Auch gibt es in .net Core kein modernes Desktop-Anwendungsmodell. Die Lösung von UWP für CoreWindow ist effektiv und komfortabel zu verwenden. Es muss nur außerhalb von UWP existieren (sowohl für C++/non-uwp als auch für .net 5). Ein weiterer Vorteil des Herauslösens von CoreWindow aus UWP besteht darin, dass es eine Möglichkeit bietet, Code direkt von UWP auf .net 5 (und C++, falls es jemals ein modernes Anwendungsmodell ohne Uwp erhält) zu portieren.

Spieleentwickler können UWP nicht verwenden, bis das Fensterverhalten geändert und die Verteilungsgeschichte aussortiert wurde. Es ist so lange her, dass es so aussieht, als würde Microsoft das Problem nicht einmal verstehen. Wir müssen also versuchen, diese APIs außerhalb von UWP zu ziehen. Wenn UWP behoben wäre, müssten wir das nicht.

Und weiterer Kommentar aus Ausgabe 1215

Wenn Sie Win32 Window durch CoreWindow für nicht enthaltene/Nicht-Xaml-Szenarien ersetzen und CoreWindow auch für .Net 5 Non-UWP bereitstellen, können wir ein einheitliches App-/Fenstermodell für Windows für Nicht-Xaml-Arbeiten haben. Das ist sinnvoller, als an Win32 FOR EVER festzuhalten oder neue App-Modelle zu erfinden.

Warum sollten wir die Anwendungsschicht neu schreiben müssen, nur weil wir zwischen enthaltener und nicht enthaltener Ausführung wechseln möchten (zum Beispiel zwischen UWP und Win32) - das ist ein typisches Problem, mit dem Spieleentwickler heute konfrontiert sind, sie können sich nicht auf UWP festlegen, weil brauchen Win32-Verteilungsfreiheit. Daher sind sie gezwungen, HWnd- oder .Net Framework-App-Modelle zu verwenden. Wenn das UWP-App/Windows-Modell für nicht-uwp-enthaltene Apps verfügbar gemacht würde, kein Problem, wir könnten den gleichen Code für die Anwendungsschicht schreiben und sowohl für den MS Store als auch für andere Stores aus derselben Codebasis kompilieren.

@leoniDEV Vieles davon ist noch Spekulation, was genau mit "hybriden Apps" gemeint ist. Sehen Sie sich beispielsweise diesen Twitter-Thread an, in dem behauptet wird, dass XAML Island-Apps nicht in diese Kategorie gehören (Matteo Pagani arbeitet bei Microsoft als Windows AppConsult Engineer ). Ein MS-Mitarbeiter in der UWP-Community sagte, dass die Unterstützung für UWP-Apps, die einen Win32-Full-Trust-Prozess ausführen, eines Tages nicht unterstützt wird, sondern später hinzugefügt werden soll.

@Gavin-Williams Es wird zwei Varianten von WinUI geben: WinUI UWP und WinUI Desktop. Mit WinUI UWP können Sie vollständige UWP-Apps erstellen, die im UWP-Container unter Windows 10X ausgeführt werden. Dann gibt es WinUI Desktop, das es Win32-Apps ermöglicht, auch vollen Zugriff auf die UWP-UI-APIs (XAML, Komposition, Eingabe, ... - mit Ausnahme einiger APIs wie CoreWindow ) zu haben. Diese Arten von Apps müssen sich nicht mit der UWP-Sandbox oder anderen Designeinschränkungen der UWP auseinandersetzen. Da es sich jedoch nicht um UWP-Apps handelt, kann Ihre WinUI-Desktop-App nicht auf die breite Palette von Windows 10-Gerätekategorien abzielen, die eine UWP-App kann.
Sehen Sie sich das folgende Bild aus der WinUI-Roadmap für einen guten Überblick an:

WinUI wurde von Grund auf in C++ geschrieben, sodass es in einem nicht verwalteten App-Kontext verwendet werden kann.

Wie ich oben betont habe, basiert mein Schreiben von I believe they will run in the mentioned Win32 container ausschließlich auf meinem aktuellen Verständnis von WinUI Desktop, den 10X-Video- und Desktop-Bridge-Test-Apps, die ich auf 10X ausgeführt habe. Ich habe kein Insiderwissen. Das WinUI-Team wird uns sicherlich mitteilen, was der Plan mit WinUI Desktop-Apps und dem verwendeten 10X-Container ist, und ich freue mich, hier korrigiert zu werden und zu erfahren, dass WinUI Desktop-Apps im UWP-Container auf 10X laufen werden.

Ich würde gerne mehr über Gedanken darüber erfahren, ob Sie möglicherweise andere Programmiersprachen wie Java, Python, JavaScript usw. verwenden können, wenn Sie Apps mit WinUI / Microsoft UI erstellen.

Ich weiß, dass es ein Projekt namens Xlang (cross-lang) gibt - das im Wesentlichen so aussieht, wie .NET hätte sein sollen, ein besseres COM.

Was hat das mit WinUI zu tun?

xlang ist im Wesentlichen eine plattformübergreifende Open-Source-Version der Windows-Runtime (WinRT), obwohl sie nicht vollständig kompatibel sein sollte. Der Zweck von WinRT ist das, was Sie gesagt haben, die Interoperabilität zwischen Sprachen, und es basiert auf COM. Die APIs von WinUI basieren auf WinRT, wodurch sowohl C++ als auch C# unterstützt werden. Es gibt andere Sprachen mit verschiedenen Unterstützungsstufen für WinRT, darunter Python , Rust (an dieser habe ich persönlich gearbeitet) und JavaScript , aber soweit ich weiß, unterstützt keine von ihnen (noch) WinUI - die Unterstützung von WinUI ist besonders schwierig da seine Kompositions- und XAML-APIs stark von einem Typsystemfeature abhängen, das als zusammensetzbare Typen bezeichnet wird (im Wesentlichen eine Form der Implementierungsvererbung), die andere WinRT- und UWP-APIs nicht verwenden und deren Zuordnung zu den Typsystemen anderer Sprachen schwierig sein kann.
Kenny Kerr, der Schöpfer von C++/WinRT, arbeitet derzeit an einer neuen Rust-WinRT-Projektion .

Ich habe in letzter Zeit viel darüber nachgedacht, wie Rust Composable Types (und damit WinUI) am besten unterstützen könnte. Es ist sicherlich möglich, aber ich bin mir noch nicht sicher, wie natürlich ich es für Entwickler anfühlen kann. Grundsätzlich sollte jede Sprache in der Lage sein, WinRT zu unterstützen, wenn jemand die Arbeit an der Erstellung einer Projektion investiert, aber je nach Design der Sprache kann es manchmal schwierig sein, WinRT-Typsystemkonstrukte auf eine Weise dem Typsystem der Sprache zuzuordnen das fühlt sich natürlich an.

xlang sieht für mich tot aus. C++/WinRT war nie wirklich fertig - es blieb mit Fehlern und einer sehr seltsamen Verwendungsgeschichte zurück, was es für den durchschnittlichen Entwickler unerwünscht macht. Ich habe viele, viele Stunden gekämpft, um C++/WinRT zum Laufen zu bringen, und habe es nicht geschafft, das zu tun, was ich in 30 Minuten mit C++/CX getan habe. Und C++/CX war bei weitem einfacher zu verwenden. Wenn Microsoft möchte, dass diese sprachenübergreifenden Tools vom Durchschnittsmenschen verwendet werden können, müssen sie ein Team von Leuten für das Problem einsetzen und es nicht Kenny Kerr überlassen, die ganze Arbeit selbst zu erledigen. Er hat tolle Ideen. Aber diese Tools brauchen eine breite Anziehungskraft, und ich denke, er braucht Hilfe, um diese Produkte zur Reife zu bringen und alles zu geben, was sie sein können.

UWP und sein Nachfolger WinUI sind derzeit noch nicht für LOB-Anwendungen geeignet

Es gibt mehrere Probleme, mit denen wir konfrontiert sind

• Schwache Leistung. Beispielsweise ist die WinUI-Abhängigkeitseigenschaft 50-mal langsamer als https://github.com/microsoft/microsoft-ui-xaml/issues/1633 .
• Schlechte Kompilierungsleistung. Mehrfach langsamer als wpf
• dotnet-nativ
• Viele Breaking Changes zwischen den Releases.
• Sandboxing- und Berechtigungsmodell
• Begrenzte Anpassungsmöglichkeiten für Drittanbieter im Vergleich zu wpf

Glauben Sie, dass WinUI diese Einschränkungen überwinden und das nächste LOB-fähige Framework für die nächsten 10 Jahre werden kann? Oder es ist an der Zeit, zur Elektronenblazor-App zu wechseln)

Ich habe ein paar Probleme mit dem aktuellen Status von WinUI.

C++/WinRT ist immer noch eine sehr schlechte Entwicklererfahrung im Vergleich zu C++/CX-Tools und der allgemeinen Entwicklererfahrung. Wenn von uns erwartet wird, dass wir mit in C++ geschriebenen WinUI-Komponenten arbeiten, ist eine mindestens 1:1-Abdeckung dessen zu erwarten, wozu C++/CX-Tools in der Lage sind.

Standard C++17 zu sein, nützt mir nichts, wenn meine Produktivität im Vergleich zu C++/CX leidet und es doppelt so lange dauert, eine UWP-Komponente oder eine XAML-basierte Benutzeroberfläche zu schreiben.

Was zu meiner zweiten Frage führt, der Hauptgrund für die Auseinandersetzung mit C++ auf UWP/WinUI ist, dass Microsoft den Ball bei jeder Art von DirectX-Bindungen zu .NET-Sprachen fallen gelassen hat. Wird WinUI jemals XNA wie Ersatz oder WPF 3D Scenegraph unterstützen? Anscheinend haben wir hier nur Funkstille und sind gezwungen, in Community-Projekte wie MonoGame oder ausgewachsene Engines wie Unity zu gehen.

Wann wird Win2D endlich Teil von WinUI? Derzeit scheint es sich im Wartungsmodus mit ungewisser Zukunft zu befinden.

Derzeit wird es sehr schwierig, den UWP-Traum noch zu verkaufen, da die Anzahl der Zuhörer um meine Seifenkiste immer weniger wird.

Wann werden die Elemente der Windows 10X-Benutzeroberfläche auf dem Desktop von Windows 10 Einzug halten?

@carmellolb 2022-2025?

Bearbeiten: MS wird dies wahrscheinlich löschen, da es einen Zeitplan für die Produktlieferung vorschlägt, der nicht existiert und daher irreführend ist ;)

@Felix-Dev "WinUI Desktop .. ermöglicht Win32-Apps vollen Zugriff auf die UWP-UI-APIs .. mit Ausnahme einiger APIs wie CoreWindow.

Ausschließen von CoreWindow? OMG – Das ist die erste und wichtigste API, die aus UWP herausgezogen werden sollte. Es ist die grundlegendste API, die die grundlegende Fensterfunktionalität bereitstellt. Es muss universell sein, innerhalb und außerhalb des UWP-Containers. Bis es herausgebracht wird, können wir keine gemeinsame Codebasis für die Anwendungsschicht haben, und wir bleiben bei altem Win32-C-Code in C++ oder was auch immer der .net-Kern (wieder eine andere Window-Klasse?) für C# bereitstellen wird.

Bitte an Microsoft – So wie Sie XamlWindow sowohl in als auch außerhalb von UWP bereitstellen, stellen Sie bitte auch CoreWindow in und außerhalb von UWP bereit.

Über den Anruf: Warum haben Sie Teams verlassen? YouTube hat beim letzten Mal nicht so gut geklappt.

@Gavin-Williams

Von https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216:

Unser Ansatz besteht darin, dass WinUI 3 bei der Ausführung in UWP CoreWindow und bei der Ausführung in Desktop (Win32) Win32 Window (HWind) verwendet.

WinUI 3 in UWP-Apps kann AppWindow-APIs verwenden. Für Desktop wird etwas Ähnliches benötigt. Wir entwickeln dies noch, daher habe ich noch keine weiteren Details.

Das Team sagte auch, dass es APIs wie CoreApplicationViewTitleBar.ExtendViewIntoTitleBar auch für WinUI Desktop

@jesbis Frage zu WinUI Desktop: In der Ausgabe https://github.com/microsoft/microsoft-ui-xaml/issues/1939 wurde darauf hingewiesen, dass die Aktivierung von Toastbenachrichtigungen für MSIX-verpackte Desktop-Apps auf (zumindest) nicht funktioniert. 1909 wie in den Dokumenten erwähnt :

Senden Sie für Desktop Bridge-Apps einfach Toastbenachrichtigungen wie eine UWP-App. Wenn der Benutzer auf Ihren Toast klickt, wird Ihre App über die Befehlszeile mit den Startargumenten gestartet, die Sie im Toast angegeben haben.

Während ich abwarten muss, ob der genannte Fix auf betroffene Betriebssystemversionen für Desktop-Bridge- Apps zurückportiert wird, lautet meine Frage: Werden WinUI-Desktop-Apps die oben zitierte vorkonfigurierte Toast-Aktivierungsfunktion bereitstellen (also ohne zu verwenden ein COM-Aktivator) auf allen WinUI-Zielversionen von Windows 10? (Oder ein ähnliches Toast-Aktivierungskonzept.)

@Felix-Dev Aus der Dokumentation geht hervor, dass XAML Island nicht unbedingt eine Hybrid-App impliziert. Sie könnten die UWP-XAML-Hosting-API direkt von Ihrer Win32-App aus aufrufen, auf Kosten des Verlusts einiger Funktionen wie der Verwendung benutzerdefinierter Steuerelemente, wenn ich das verstehe richtig die docs (und der hinweis in den docs):

Hosten eines standardmäßigen UWP-Steuerelements in einer WPF-App mithilfe von XAML Islands

Erforderliche Komponenten

Das Projekt und der Quellcode für Ihre App. Die Verwendung des WindowsXamlHost-Steuerelements zum Hosten von standardmäßigen UWP-Steuerelementen von Erstanbietern wird in Apps unterstützt, die auf .NET Framework oder .NET Core 3 abzielen.

Ein UWP-App-Projekt, das eine Stammanwendungsklasse definiert, die von XamlApplication abgeleitet wird . Ihr WPF- oder Windows Forms-Projekt muss Zugriff auf eine Instanz der Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication-Klasse haben, die vom Windows Community Toolkit bereitgestellt wird. Dieses Objekt fungiert als Stammmetadatenanbieter zum Laden von Metadaten für benutzerdefinierte UWP-XAML-Typen in Assemblys im aktuellen Verzeichnis Ihrer Anwendung.

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

Ich habe viele, viele Stunden gekämpft, um C++/WinRT zum Laufen zu bringen, und habe es nicht geschafft, das zu tun, was ich in 30 Minuten mit C++/CX getan habe

Wenn von uns erwartet wird, dass wir mit in C++ geschriebenen WinUI-Komponenten arbeiten, ist eine mindestens 1:1-Abdeckung dessen zu erwarten, wozu C++/CX-Tools in der Lage sind.

@Gavin-Williams, @pjmlp haben Sie Probleme im cppwinrt-Repository für die gefundenen Probleme geöffnet? Oder handelt es sich um WinUI-spezifische Probleme, für die Sie in diesem Repository Probleme öffnen könnten? Wir arbeiten aktiv an der C++/WinRT-Unterstützung, daher wäre es großartig, Details darüber zu erfahren, was bei Ihnen nicht gut funktioniert. Wir verwenden es auch selbst - neue WinUI-Features sind alle in C++/WinRT, ebenso wie unsere Apps, die es verwenden (zB Taschenrechner ).

Über den Anruf: Warum haben Sie Teams verlassen? YouTube hat beim letzten Mal nicht so gut geklappt.

Wenn Sie die Audioprobleme meinen: Wir glauben, dass wir letzten Monat ein defektes Kabel hatten und hoffen, dass es morgen besser sein sollte. YouTube schien für die meisten Menschen zugänglicher zu sein, und das Channel9-Studio bietet viel bessere Audio- und Videofunktionen als der Konferenzraum, den wir für Teams verwendeten.

RE: CoreWindow, Win32-Unterstützung, Container - über unsere aktuelle Ausrichtung sprechen wir morgen beim Community-Call mit @marb2000 :)

Wir werden auch versuchen, auf die anderen bisherigen Fragen einzugehen (zB aktueller Status zur SwapChainPanel-Timeline, Win2D/DirectX, Inseln, etc.) - danke für die Kommentare & Fragen bisher!

@jesbis Vielen Dank, dass Sie sich bei uns

Es gibt keine Probleme zu öffnen, da der C++/WinRT-Entwicklungsansatz völlig hinter der von C++/CX gebotenen Produktivität zurückbleibt.

Mit C++/CX dachte ich zunächst, dass Microsoft Visual C++ endlich richtig verkauft, 25 Jahre später hatte Visual C++ die RAD-Erfahrung von C++ Builder aufgegriffen.

Stattdessen gibt mir C++/WinRT eine Rückkehr zu den ATL/WTL-Tagen, in denen ich MIDL-Boilerplate schreiben muss, obwohl MIDL 3.0 irgendwie schöner ist als die ursprüngliche MIDL, UWP-Bindungs-Boilerplate, für die C++/CX handhabt, manuell schreiben muss mich.

Nicht dass C++/CX perfekt ist, die Art und Weise, wie es Ereignishandler behandelt, scheitert immer noch an C#/VB.NET oder C++ Builder.

UWP ist sowieso an Windows gebunden, daher ist eine reine C++-Bindung nicht etwas, das mich in C++/Winrt kauft, sondern in der Lage zu sein, genau das gleiche wie in C# oder VB.NET zu tun, ohne mit Code umgehen zu müssen, der sich immer noch so anfühlt ATL/WTL.

Und wie bereits erwähnt, beschäftige ich mich nur mit C++, weil die Appelle, DirectX als eine Reihe von UWP-Laufzeitkomponenten bereitzustellen, immer wieder ignoriert werden.

Ich glaube also nicht, dass das Öffnen von Problemen bei cppwinrt die Möglichkeit verbessert, C++/Winrt in Blend und Visual Studio so einfach zu verwenden wie C++/CX, idealerweise so einfach wie C# und VB.NET, da ich erwarte, dass das cppwinrt-Team dies ändert Problem in das Visual Studio-Team, und traditionell (MFC/ATL/WTL) war es dem C++-Tooling-Team nie wichtig, die gleichen High-Level-Tools wie die .NET-Sprachen bereitzustellen, obwohl andere Unternehmen dies mit C++ (Qt, Embarcadero).

@pjmlp danke für die Details - ich

Ich bin auch daran interessiert, was der Plan für die zukünftige Isolierung von WinUI-Apps ist. Aus Unternehmenssicht benötigen wir Isolation/Sandboxing und Capability Control (kein Benutzer-Opt-in). Also, das hier als Thema für Miguel herausstellen..

@infoequipt könnten Sie AppContainer- Support?

UWP und sein Nachfolger WinUI sind derzeit noch nicht für LOB-Anwendungen geeignet

• Viele Breaking Changes zwischen den Releases.

@Xarlot, welche Breaking Changes haben dir Probleme

@Gavin-Williams Da SharpDX veraltet ist, sollten Sie sich Vortice.Windows ansehen, was eine großartige Alternative dafür ist. @Aminator verwendet es derzeit in seiner eigenen vollständig UWP/C#/XAML DX12-Spiele-Engine und -Editor, DX12GameEngine .
Hoffentlich entspricht das Ihren Anforderungen in Ihren Apps! 😄

Zu den Fragen für den Anruf habe ich eine, die ein kleines Detail ist, aber wenn wir schon dabei sind: könnten wir den Wechsel zu WinUI 3 nutzen, um auch einige kleine ältere UI-Fehler zu beheben, die als "breaking changes" angesehen werden könnten, wie die StackPanel wendet die Eigenschaft Spacing falsch auf minimierte Elemente an?

Dh. Wenn Sie einige minimierte Elemente in einem StackPanel , wird weiterhin der Abstand zwischen ihnen angewendet, sodass Sie gezwungen sind, auf manuelles Auffüllen/Rand zwischen Elementen zurückzugreifen, wenn Sie einige Ihrer Elemente haben, die programmgesteuert angezeigt/ausgeblendet werden können. Ich habe diesen speziellen Fehler in einer PR für WrapPanel im Windows Community Toolkit ( #2838 ) StackPanel ein bekanntes Problem, das von einigen anderen MS-Ingenieuren erkannt wurde sowie. 🤔

Mach weiter so mit der tollen Arbeit! 🚀

@leoniDEV Danke für den Hinweis. Mal sehen, ob wir morgen ein paar konkrete Antworten bekommen 🙂

@jesbis Zwei weitere Fragen zu WinUI Desktop (zusammenhängend):

1. Verfügen WinUI Desktop-Apps über einen integrierten Wechsel zwischen Multi-Instanz (Win32-Standard) und Einzel-Instanz (UWP-Standard)? Wenn wir jetzt möchten, dass eine Win32-App eine einzelne Instanz ist, müssen wir dieses Verhalten selbst implementieren. Dies erfordert möglicherweise nicht nur eine App-Sperre (wie ein Mutex, um zu überprüfen, ob eine Instanz bereits ausgeführt wird), sondern auch eine Win32-API wie SendMessage , um Operationen von einer zweiten App-Instanz an die primäre App-Instanz weiterzugeben (siehe Frage 2). Es wäre großartig, wenn wir die Option erhalten könnten, das Einzelinstanzverhalten von UWP-Apps für WinUI-Desktop-Apps zu verwenden.

1. Können WinUI Desktop-Apps die UWP Jumplist API verwenden? Derzeit können Desktop-Bridge-Apps sie nicht effektiv nutzen, da die App anscheinend nicht aktiviert werden kann (siehe Windows Terminal-Ausgabe https://github.com/microsoft/terminal/issues/576 für einen kurzen Überblick über die Probleme). Ich möchte die volle Unterstützung dieser API für WinUI-Desktop-Apps, da sie viel einfacher zu handhaben sind als die Win32/WPF-APIs. Zum Beispiel können Jumplist-Aufgabensymbole einfach mit den URI-Schemata ms-appx:/// oder ms-appdata:/// , anstatt eine .exe oder .dll mit den Bildern erstellen zu müssen und dann den Pfad zu dieser Binärdatei festzulegen und auch ein Offset in die Datei für das spezifische Symbol .

   Die Dokumente fassen die Vorteile der UWP Jumplist API zusammen:

   Alternativ können Sie stattdessen die UWP Windows.UI.StartScreen.JumpList-APIs verwenden, mit denen Sie Zeichenfolgen- und Bildassets mithilfe des paketbezogenen ms-resource-URI-Schemas (das auch Sprache, DPI und hohen Kontrast unterstützt) referenzieren können.

Das Single-Instance-Verhalten von UWP-Apps erleichtert möglicherweise auch die Arbeit mit Jumplists erheblich. Wenn Sie eine Jumplist-Aufgabe haben, die auf der aktuell laufenden App-Instanz ausgeführt werden soll, wird in WPF/Win32 eine zweite App-Instanz gestartet, die dann beispielsweise die SendMessage Win32-API verwenden muss, um die angeforderte Operation zu senden zur primären App-Instanz. Unter Verwendung des Einzelinstanzverhaltens auf UWP ruft die laufende App

@pjmlp Eine andere Sache, die von Interesse sein könnte, wenn Sie sie noch nicht gesehen haben, ist diese Sitzung von Kenny Kerr und Scott Jones von der letzten Build-Konferenz, insbesondere die letzten ~11 Minuten, in denen über einige prototypische Verbesserungen an Bindungen und etwas C++ gesprochen wird technische Spezifikationen für das Hinzufügen von Reflection- und Metaklassen-Unterstützung, die die aktuellen IDL- und Metadaten-Codegen-Anforderungen vollständig entfernen könnten:

https://youtu.be/X41j_gzSwOY?t=2659

Wenn wir Zeit haben, können wir morgen auch ein bisschen darüber reden.

Danke @jesbis , das Gespräch ist mir bekannt. Das ist, wie ich sehe, noch zu weit in der Zukunft.

Im Moment sieht es wahrscheinlicher aus, dass ich meinen vorhandenen DirectX-Code auf so etwas wie die Vortice-Bibliothek portieren werde, auf die @Sergio0694 hingewiesen hat, als darauf zu warten, dass solche Tools Früchte tragen.

Ich bewundere Ihre Bemühungen, aber hier aus den Gräben, nach Silverlight, XNA, WinRT, UAP, UWP, WinUI, .NET Framework, WCF, EF6, werden wir irgendwann müde, immer wieder neu zu schreiben.

WinUI sollte in jeder Hinsicht besser sein als WPF, und wenn wir aus Gründen gezwungen sind, C++ zu verwenden, sollten seine Tools auf dem gleichen Niveau sein, das .NET-Entwickler lieben, um es tatsächlich wert zu sein, über WPF hinauszugehen oder ein darauf hinzuweisen, dass Unternehmen nicht mit Apps im Electron-Stil arbeiten möchten.

Wie @Sergio0694 bereits gefragt, wird WinUi 3.0 nicht nur zum Wechseln von Namespaces verwendet, sondern enthält auch andere Breaking Changes, die erforderlich sind, um Fehler wie falsch angewendete Leerzeichen zu beheben?

Wenn ja, besteht die Möglichkeit, die Eigenschaft NavigationView.IsBackButtonVisible in BackButtonVisibility umzubenennen, da Name und Typ derzeit nicht wirklich übereinstimmen (IsBackButtonVisible ist eine NavigationViewBackButtonVisible-Enumeration, kein Bool). Auch das wurde hier besprochen.

@chingucoding Ich erinnere mich, dass das Team sagte, dass für WinUI 3.0 selbst grundlegende Änderungen minimal sein sollten, um die Portierung vorhandener (UWP) Apps so einfach wie möglich zu machen. Ich vermute, dass diese Änderungen, wenn sie genehmigt werden, in nachfolgenden Versionen von WinUI 3.x/4/5/.... implementiert werden.

F: Wird WinUI 3.x AcrylicBrush mit HostBackdrop ? Es ist derzeit bekannt, dass es in der Alpha defekt ist, aber ich bin gespannt, ob es auf der Roadmap steht, die vor der Veröffentlichung behoben werden soll.

F: Wird WinUI Desktop es Entwicklern von Desktop-Apps ermöglichen, _endlich_ AcrylicBrush mit HostBackdrop ? Wir haben zuvor das Kompositionsattribut WCA_ACCENT_POLICY mit ACCENT_ENABLE_ACRYLICBLURBEHIND aber Microsoft hat dies in 19H1+ kritisch gebrochen und unsere App leidet seitdem. (Es betraf auch Dinge wie den Emoji Picker, aber Microsoft hat diese Komponenten gewartet, um stattdessen eine Nicht-Acryl-Methode zu verwenden.)

Über WebView2:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"Entwicklervorschau ist für Win32 C++ unter Windows 10, Windows 8.1, Windows 8 und Windows 7 verfügbar. In Zukunft planen wir, WebView2 auf .NET und XAML zu unterstützen."

Meine Frage ist.. Ist geplant, dass die .NET-Version des WebView2 SDK für Win8.1, 8 und 7 gilt?
Ich habe Bedenken, dass WebView2 auf .NET teilweise nur über WinUI3 unterstützt wird. Nach meinem Verständnis gilt die WinUI3-WinForms-App-Unterstützung nur für .NET Core-basiert und nur für Win10.
Lassen Sie mich meine Situation erklären. Mein Kunde hat viele WinForm-Desktop-Apps, die das IE BrowserControl verwenden. Aber der IE ist veraltet und möchte auf moderne Browser migrieren. Und diese App SOLLTE Win7, 8, 8.1 unterstützen. (Gib mir nicht die Schuld für die Unterstützung alter Betriebssysteme)

Wenn möglich:

• Win32 ETA auf einem Vorschau-Build für WinUI 3.0

• Wenn der Quellcode nicht bereit zum Teilen ist, wäre es vielleicht cool, eine bereits kompilierte Demo-exe einiger UI-Elemente, die wir herunterladen und mit denen wir spielen könnten, herauszugeben, um sie anderen Mitarbeitern vorzuführen.

• Unterstützt WinUI 3.0 benutzerdefinierte Shader-Effekte wie WPF/Silverlight? Wenn nicht, gibt es Überlegungen, sie später hinzuzufügen? Ist die von WinUI verwendete Rendering-Schicht dazu überhaupt in der Lage?

@leoniDEV Ich habe ein XAML Island-Projekt erstellt, wie Sie es hervorgehoben haben (also kein separates UWP-Projekt). Es enthält ein einzelnes UWP-Posteingangssteuerelement (eine Schaltfläche) und funktioniert auf 10X einwandfrei. Keine Überraschung für die Container-Geschichte ... sie läuft wie erwartet im Win32-Container.

Es scheint also zumindest im Moment noch keine vollständige Unterstützung für XAML Island-Apps zu geben, die ein separates UWP-Projekt verbrauchen.

Ich überlege, v-next einer Legacy-WPF-App zu tun. Ich kann wahrscheinlich .NET Core WPF verwenden, möchte aber unbedingt WinUI verwenden. Ich habe Probleme mit Bibliotheken wie Prism, die immer noch von Windows.UI.Xaml abgeleitet sind (im Gegensatz zu Microsoft.UI.Xaml). Es fühlt sich an, als ob diese Art von Problemen grundlegend sind. Gibt es bereits eine solide PnP-Anleitung für WinUI oder ist es zu früh?

Ist es möglich, jemanden aus dem Shell-Team oder dem Inbox-Apps-Team dazu zu bringen, darüber zu sprechen, warum das Startmenü und der Datei-Explorer unter Windows 10x webbasiert sind, anstatt WinUI zu verwenden?

Alles, was ich brauche, ist eine nahtlose Portierung von unserer aktuellen UWP-App (mit Desktop-Erweiterung) auf eine WinUI-Desktop-App (ohne Desktop-Erweiterung). Wird dies möglich sein? Was sind die Fallstricke in diesem Szenario?

Wenn sich dies als schwierig erweist, wird es in Zukunft möglich sein, UWP (für Apps, die auf dem Desktop ausgeführt werden) zu verbessern, um Apps immer im Hintergrund auszuführen und ihnen zu erlauben, alle Win32-APIs über P/Invoke aufzurufen und DLLs zuzulassen, die geladen werden andere DLLs ohne LoadPackagedLibrary (aber mit LoadLibrary).

Wie wahrscheinlich ist es, dass WinUI 3.0 startbereit ist, wenn die ersten Windows 10X-Geräte starten? Ich interessiere mich für den Sprung in die Windows-Entwicklungswelt und versuche zu entscheiden, welcher Ansatz derzeit am sinnvollsten ist.

Vielen Dank an alle für die Fragen und fürs Zuschauen, wenn Sie es schaffen! Die Aufzeichnung ist live unter dem gleichen Link.

Es gab viele Fragen, die wir nicht beantwortet haben - ich werde versuchen, sie zusammenzufassen und bald einige Antworten hier zu posten.

Gute Show Jungs, danke für die Beantwortung meiner Frage und für die Präsentation von Miguel.

Ich füge noch ein paar Fragen hinzu, in der Hoffnung, dass sie beantwortet werden.

1. Herkömmliche Win32-Apps zeichnen in WM_PAINT auf den Bildschirm. XAML-Apps sind im beibehaltenen Modus. Wir zeichnen VIEL zu viele Dinge auf den Bildschirm, um einzelne Objekte/Steuerelemente zu erstellen. Wird es immer noch ein WM_PAINT-Äquivalent geben, mit dem ich in das Fenster zeichnen kann, jedoch mit modernerer API? Win2D oder eine andere Sofortmodus-API?

2. Die Barrierefreiheit wird in Win32 (COM-APIs) anders gehandhabt als beispielsweise in WPF (Automation Peers). Wenn ich eine Win32 + WinUI-Anwendung schreibe, kann ich dann die Barrierefreiheitsstruktur einfacher erweitern oder steuern? Oder bleibe ich bei den alten COM-APIs? Wie würde ich meinen benutzerdefinierten gezeichneten Inhalt mit barrierefreien Steuerelementen in der Barrierefreiheitsstruktur kombinieren?

3. Heute drucken wir, indem wir in einen Drucker DC zeichnen. Gibt es einen neuen Druck mit Win32+WinUI?

4. Ich bin immer noch etwas ratlos bezüglich der Beziehung zwischen einem HWND, einem CoreWindow und was auch immer für WinUI als nächstes kommt. Wird es HWNDs noch geben oder werden wir CreateWindow-Aufrufe durch etwas anderes ersetzen? Ich gehe davon aus ... aber wenn dies der Fall ist, gehe ich davon aus, dass es immer noch ein zugrunde liegendes HWND geben muss, für Fälle, in denen wir eines an externe Komponenten übergeben müssen (z. B. das übergeordnete HWND).

5. Wird die Verwendung von WebView2 in einer Win32+WinUI-App die Luftraumprobleme haben, auf die wir bei der eingebetteten IE-Steuerung stoßen?

Fange an, einige Fragen nachzuholen:

Ist WinUI nur UWP-Entwicklung, aber eine modernere Spezifikation? Ich sehe Unterhaltungen über WinUI und bin mir nicht 100% sicher, ob sie über UWP Dev, bestimmte Bibliotheken in UWP Dev oder etwas ganz anderes sprechen

WinUI ist speziell die UI-Schicht und enthält keine anderen Aspekte der UWP-App-Plattform wie das App-Modell für Suspend/Resume, Hintergrundaufgaben usw.

Für UWP-Apps kann es insbesondere Windows.UI.Xaml , Windows.UI.Composition und Teile von Windows.UI.Input ersetzen.

Werden WinUI-Apps einen integrierten Wechsel zwischen Multi-Instanz (Win32-Standard) und Einzel-Instanz (UWP-Standard) haben?

@Felix-Dev, wir haben die Idee einer besseren Einzelinstanz-Unterstützung für Win32-Apps noch nicht untersucht - wenn Sie einen Vorschlag haben, können Sie in diesem Repo gerne ein Problem dafür erstellen!

Wird WinUI 3.x AcrylicBrush mit HostBackdrop unterstützen? Es ist derzeit bekannt, dass es in der Alpha defekt ist, aber ich bin gespannt, ob es auf der Roadmap steht, die vor der Veröffentlichung behoben werden soll. Wird WinUI Desktop es Entwicklern von Desktop-Apps ermöglichen, AcrylicBrush endlich mit HostBackdrop zu verwenden?

@riverar das ist leider nicht im Plan für WinUI 3.0 RTM. Es gibt Herausforderungen bei der Unterstützung dieser in einer UI-Plattform, die vom Betriebssystem entkoppelt ist, aber wir planen, dies nach 3.0 erneut zu überprüfen.

Über WebView2: Meine Frage ist.. Ist geplant, dass die .NET-Version von WebView2 SDK für Win8.1, 8 und 7 gilt?
Ich habe Bedenken, dass WebView2 auf .NET teilweise nur über WinUI3 unterstützt wird.

@pnp0a03 das WinUI-Xaml-Steuerelement wird nur in WinUI 3 unterstützt, aber es gibt eine Entwicklervorschau des WebView 2-Kern-SDKs für Windows 7, 8 und 8.1 für Win32-Apps:

https://docs.microsoft.com/microsoft-edge/hosting/webview2

Ich habe Probleme mit Bibliotheken wie Prism, die immer noch von Windows.UI.Xaml abgeleitet sind (im Gegensatz zu Microsoft.UI.Xaml). Es fühlt sich an, als ob diese Art von Problemen grundlegend sind. Gibt es bereits eine solide PnP-Anleitung für WinUI oder ist es zu früh?

@GraniteStateHacker Es ist ein bisschen zu früh, denke ich - WinUI 3 ist noch zu neu, um viel Ökosystem-Unterstützung zu haben (es ist nur in der Alpha- Phase ), aber

Ist WinUI nur für Store-Apps geeignet?

Nein - Sie können es auf verschiedene Weise verwenden, zum Beispiel:

• Integrieren Sie es in eine vorhandene Win32-App (WPF, WinForms, MFC usw.) mithilfe von Xaml Islands
• Erstellen Sie ein MSIX-Installationsprogramm und stellen Sie es nach Belieben bereit
• Erstellen Sie eine entpackte App und verteilen Sie sie über xcopy oder auf andere Weise (noch nicht für WinUI 3 unterstützt, aber für RTM geplant)

Wie wahrscheinlich ist es, dass WinUI 3.0 startbereit ist, wenn die ersten Windows 10X-Geräte starten? Ich interessiere mich für den Sprung in die Windows-Entwicklungswelt und versuche zu entscheiden, welcher Ansatz derzeit am sinnvollsten ist.

@dwalleck WinUI 3 hat bereits eine Alpha-Version und sollte eine funktionale Vorschau um den Zeitrahmen der Build- Konferenz haben, und beide zielen auf Ende 2020 ab. Wenn Sie mit UWP Xaml und/oder WinUI beginnen, sollten Sie auf einem guten Weg für die 10X-Entwicklung sein .

Herkömmliche Win32-Apps zeichnen in WM_PAINT auf den Bildschirm. XAML-Apps sind im beibehaltenen Modus. Wir zeichnen VIEL zu viele Dinge auf den Bildschirm, um einzelne Objekte/Steuerelemente zu erstellen. Wird es immer noch ein WM_PAINT-Äquivalent geben, mit dem ich in das Fenster zeichnen kann, jedoch mit modernerer API? Win2D oder eine andere Sofortmodus-API?

@jschroedl Xaml-Elementbäume und -Pinsel sind im beibehaltenen Modus, aber Sie können eine oder mehrere von mehreren Optionen verwenden, um leichtere Rendering-Primitive einzuschließen:

• Kompositionsebene Visuals
• Kompositionsebene Formen, die das Zeichnen sehr leistungsstarker beibehaltener Geometrien ermöglichen - werden auch für Dinge wie das WinUI AnimatedVisualPlayer Steuerelement verwendet, das Lottie-Formen/Animationen abspielen kann
• DirectX-Interop mit Xaml mithilfe von SwapChainPanel, SurfaceImageSource oder VirtualSurfaceImageSource (je nachdem, ob Sie eine Swap-Chain oder ein virtualisiertes/nicht virtualisiertes
• Win2D, das die obige DirectX-Interop für Sie abstrahiert (mit Direct2D, DirectWrite) und eine .NET-API bereitstellt

Die Barrierefreiheit wird in Win32 (COM-APIs) anders gehandhabt als beispielsweise in WPF (Automation Peers). Wenn ich eine Win32 + WinUI-Anwendung schreibe, kann ich dann die Barrierefreiheitsstruktur einfacher erweitern oder steuern? Oder bleibe ich bei den alten COM-APIs? Wie würde ich meinen benutzerdefinierten gezeichneten Inhalt mit barrierefreien Steuerelementen in der Barrierefreiheitsstruktur kombinieren?

Tolle Frage! Paging @marb2000 , um sicherzustellen, dass dies abgedeckt ist, und die neuesten Updates

Heute drucken wir, indem wir in einen Drucker DC zeichnen. Gibt es einen neuen Druck mit Win32+WinUI?

Die Hauptdruckfunktionalität für WinUI-Inhalte sollte über eine WinUI-Version der WinRT PrintDocument API erfolgen.

Ich bin immer noch etwas ratlos bezüglich der Beziehung zwischen einem HWND, einem CoreWindow und was auch immer für WinUI als nächstes kommt. Wird es HWNDs noch geben oder werden wir CreateWindow-Aufrufe durch etwas anderes ersetzen? Ich gehe davon aus ... aber wenn dies der Fall ist, gehe ich davon aus, dass es immer noch eine zugrunde liegende HWND geben muss, für Fälle, in denen wir eine an externe Komponenten übergeben müssen (z. B. die übergeordnete HWND).

WinUI ersetzt nicht hwnds, aber das Ziel besteht darin, ihre Verwendung für gängige Anwendungsfälle zu abstrahieren, indem eine Xaml-API bereitgestellt wird - ähnlich der Funktionsweise von WPF. Die Xaml-API wird tatsächlich weiterhin hwnds/CoreWindows als zugrunde liegendes Implementierungsdetail verwenden, und wir werden wahrscheinlich "Hintertür"/"Escape-Hatch"-APIs haben, um bei Bedarf direkten Zugriff auf hwnds zu erhalten. Wir sollten in einigen Wochen einen Vorschlagsentwurf haben, der dies klarer macht.

@jesbis Danke für deine Antwort, aber mein Anliegen wurde leider nicht gelöst.
Derzeit wird die WebView2 SDK Win32 "C++" (Vorschau)-Version von dieser Site veröffentlicht. Es unterstützt Win7, 8 und 8.1.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
Meine Frage bezieht sich auf die .NET-Version. Derzeit wird die .NET-Version nur von WinUI 3 unterstützt. Aber wie Sie wissen, können wir WinUI 3 nicht auf Win7, 8 und 8.1 verwenden ( ist das richtig? ).
Daher habe ich meine Frage wie folgt gepostet.

Meine Frage ist.. Ist geplant, dass die .NET-Version des WebView2 SDK für Win8.1, 8 und 7 gilt?

@jesbis Danke für die Beantwortung meiner Fragen, obwohl es sich demotivierend angefühlt hat.

Versuche hier konstruktiv zu sein.

Das Beste, was Microsoft in Bezug auf C++/WinRT-Tools anbieten kann, ist also, auf einige in der Luft befindliche Vorschläge hinzuweisen, die mit etwas Glück, wenn überhaupt, auf ISO irgendwo zwischen C++23 oder C++26 landen könnten. Und warten Sie dann, bis das Visual Studio-Team schließlich C++/CX darüber neu erstellt, was in etwa 6 Jahren liegt.

Wenn ich großartige C++-UI-Tools haben möchte, ist es definitiv nicht WinUI, sondern Qt oder C++ Builder mit dem zusätzlichen Vorteil der Plattformportabilität.

Nachdem Sie sich also die Präsentation angesehen haben und immer noch Narben von XNA tragen (in C++ mit DirectXTK neu schreiben), WinRT 8.0, WinRT UAP 8.1, UWP W10, C++ Direct2D anstelle von System. Zeichnen (bis Win2D kam, jetzt stagniert), ist WinUI definitiv etwas, das ich auf Eis legen werde.

In Zukunft werde ich meinen Kunden raten, WPF bei der Verwendung von .NET, Qt bei Verwendung von C++ zu verwenden oder sich auf PWAs zu konzentrieren, wenn dies mit Webtechnologien machbar ist.

Die WinUI 3.0-Roadmap weckt keine Zuversicht, dass ein weiterer Neustart bevorsteht, wenn der Verkauf von UWP auf dem Desktop-Markt weiterhin scheitert.

In gewisser Weise möchte ich darauf hinweisen, dass das Management von Microsoft darüber nachdenken sollte, wie wir uns die Idee der Einführung von WinUI verkaufen können, nachdem wir seit der Veröffentlichung von Windows 8 so oft gescheitert sind.

@pjmlp Allgemeines C++/WinRT-Feedback ist wahrscheinlich am besten an das cppwinrt-Repository gerichtet. ISO-Standard-Updates brauchen Zeit, aber ich hoffe, es wird weniger als der von Ihnen erwähnte Zeitrahmen sein - Reflexionsunterstützung hat oberste Priorität und sie haben es gerade auf der C++-Konferenz in Prag letzte Woche diskutiert.

DirectXTK befindet sich noch in der Entwicklung und wird regelmäßig aktualisiert.

In Bezug auf Xaml-Framework-APIs ist WinUI der Weg nach vorne und hat eine ziemlich ununterbrochene Kompatibilitätslinie zurück zu Windows 8 - wir verbringen viel Zeit damit, ein hohes Maß an Kompatibilität aufrechtzuerhalten 🙂 Es gibt einige Änderungen (aufgrund der Shell-Integration, VS-Projektstruktur usw.), aber zum größten Teil könnten Sie Windows 8 Xaml wahrscheinlich auf eine aktuelle Windows 10-App portieren, neu kompilieren und auf dem neuesten Insider-Flug ausführen und es würde funktionieren.

Zu den übergeordneten Vorteilen von WinUI gehören die Beseitigung der Barrieren zwischen UWP WinRT-APIs und win32-APIs, die Unterstützung von .NET 5, die sofortige Unterstützung neuer Funktionen auf einem Downlevel, die Beseitigung vieler bedingter OS-Versionsprüfungen, die Aktivierung von OSS-Beiträgen und Aktivieren inkrementeller Updates für vorhandene Win32-Apps mithilfe von Xaml-Inseln.

@pnp0a03 Es gibt Bemühungen, auch .NET-Elemente auf den Markt zu bringen. Konkrete Termine kann ich nicht nennen, aber wir wissen um die Nachfrage und arbeiten an den Details.

@jschroedl wir wollen Luftraumprobleme beseitigen, wir versuchen einen Renderingplan auszuarbeiten, der uns dabei hilft.

@jesbis Wie bereits erwähnt, glaube ich nicht, dass sich über cppwinrt beschweren wird ISO.

In Bezug auf DirectXTK gab ich ein weiteres Beispiel dafür, wie Microsoft uns gezwungen hat, unseren C#-Code mit weniger leistungsfähigen Tools in C++ umzuschreiben, indem wir XNA fallen lassen und DirectXTK als "Alternative" bereitstellen.

Zum Glück ist es der Open-Source-Community gelungen, MonoGame zu entwickeln und die Arbeit zu leisten, die Microsoft mit XNA nicht verfolgt hat.

Ich habe es während der Präsentation und in einigen Kommentaren hier gesehen, wie großartig C++ ist und Spaß macht, wie WinDev (noch einmal seit Longhorns Übernahme) C++ zuerst verkauft, .NET später.

Wenn ich großartige C++-Tools haben möchte, sind Qt und C++ Builder meine bevorzugten Umgebungen, nicht Visual C++.

Sie sollten das Management wirklich bitten, Ihrem Team zu erlauben, einen Blick darauf zu werfen, was heute im Wettbewerb möglich ist, anstatt zu erwarten, dass einige Metaklassen und Reflexionsideen bei ISO akzeptiert werden.

Wir müssen uns nicht nur um die APIs und Bibliotheken von Drittanbietern kümmern, die nicht von .NET Framework in .NET Core übertragen werden, sondern wir müssen uns auch mit allen Migrationsproblemen von WPF/UWP in WinUI und dem "einfach schreiben" befassen es in C++/WinRT, es ist cool und es wird in ein paar Jahren besser"-Mentalität.

Das Microsoft-Management muss sich wirklich Gedanken machen, wie man dieses Rewrite an verbrannte .NET-Entwickler verkauft, sonst werden wir uns nicht von Stacks entfernen, die bereits ihren Job machen.

@pjmlp Apropos DirectX, ich arbeite in meiner Freizeit aktiv an einem portablen und agnostischen C# -Grafik- , Audio- und Eingabe-Framework, das in der Lage sein wird, D3D12/11 usw. in einer WinUI-Ansicht auszuführen .... unter anderem.

Es unterstützt einen viel moderneren und leistungsorientierten Ansatz des Renderns im Vergleich zu etwas wie XNA. Es ist noch nicht einsatzbereit, aber es ist etwas, was viele Leute wollten, einschließlich mir ... also mache ich es. D3D12 und Vulkan werden die ersten unterstützten Ziele sein. Sie können Shader auch in C# anstelle von HLSL oder GLSL usw. schreiben.

Wenn es einsatzbereit ist, werde ich mehr teilen, aber da es sich um ein Framework und nicht um ein riesiges SDK oder eine Spiele-Engine handelt, wird es sehr portabel und leichtgewichtig, aber dennoch leistungsstark und einfach zu bedienen sein. Perfekt zum Rendern von 3D-Inhalten in WinUI, WPF oder einer nativen C#-Win32- oder WinRT-App.

https://github.com/reignstudios/Orbital-Framework

@zezba9000 Vielen Dank für die Informationen, viele beeindruckende

Ich denke, was den Managed Support für DirectX angeht, können wir uns nur auf Community-Bemühungen wie Ihre verlassen.

Zumindest kann jedes dieser Projekte mit meiner Befürwortung rechnen, als Marketing, um anderen zu zeigen, dass es nicht nur "C++ oder die High Road" sein muss, wie WinDev es gerne vorantreibt. Hier könnten sie eine Lektion von OpenGL ES/Metal mit Swift oder OpenGL ES/Vulkan mit Java/Kotlin nehmen. Anscheinend war die Verwendung verwalteter Sprachen für die 3D-Programmierung kein Problem für mobile Plattformen, um Windows zu gewinnen (leider war WP eine großartige Erfahrung).

Viel Glück für Ihre Bemühungen, das Schreiben von Shadern in C# sieht wirklich ansprechend aus und ich kannte CS2X nicht.

@pjmlp Ya der CS2X-Teil ermöglicht das Schreiben von agnostischen GPU-Shadern in C# (was cool ist, da Sie Ihre Shader theoretisch Unit-Tests durchführen können). Für Ziele, die eine C#-Untermenge verwenden können, ermöglicht CS2X mir/anderen, auf Plattformen außerhalb der Unterstützung von aktuellen .NET-Laufzeiten mit einer sehr schlanken Laufzeit abzuzielen, da CS2X eine C#-Untermenge in eine C89-Laufzeit kompilieren kann ... und weil das Orbital-Framework kann auf die CS2X => C89-Laufzeit abzielen, diese wiederum kann auch auf diese Plattformen abzielen.

Großes Projekt, aber es ist mir wichtig und ich setze mich dafür ein, es zu verwirklichen.

Wird es möglich sein, HwndHost mit WinUI 2.4 zu verwenden?
Ich habe es mit der Vorabversion versucht und das hat nicht funktioniert.
Wird es auch mit WinUI3 mit all diesen neuen geplanten Windowing (XAML Window) und Application (XAML Application) möglich sein und wenn ja, wann können wir die erste Vorschau erwarten, um dies zu sehen.
Wenn es in WinUI3 möglich sein wird, wird diese Funktionalität zu den neuen Versionen von WinUI 2 hinzugefügt, oder WinUI 2 funktioniert nur in Uwp-Apps.
Im Moment haben wir zum Beispiel eine WPF-App, die viel C++-Code über HwndHost verwendet, und da wir planen, alles auf WinUI zu verschieben, ist dieser Teil für uns sehr wichtig, um uns für WinUI oder etwas anderes zu entscheiden. Auch WinUI 2 sieht für uns gut aus, XAML-Teil ist so einfach zu übertragen, Composition Api funktioniert großartig, Uwp Community Toolkit funktioniert großartig, nur können wir HwndHost und c++ Win32-Code nicht verwenden. Also und wann wird WinUI3 dies lösen? Auch ich mag x:Bind sehr, aber dies ist sogar für die WinUI3-Version gefährdet.

@zezba9000

Apropos DirectX, ich arbeite in meiner Freizeit aktiv an einem portablen und agnostischen C#-Grafik-, Audio- und Eingabeframework, das in der Lage sein wird, D3D12/11 usw. in einer WinUI-Ansicht auszuführen .... unter anderem.

Viel Glück dabei! Es ist ein wahnsinniger Arbeitsaufwand!

Wird es möglich sein, HwndHost mit WinUI 2.4 zu verwenden?
Ich habe es mit der Vorabversion versucht und das hat nicht funktioniert.
Wird es auch mit WinUI3 mit all diesen neuen geplanten Windowing (XAML Window) und Application (XAML Application) möglich sein und wenn ja, wann können wir die erste Vorschau erwarten, um dies zu sehen.
Wenn es in WinUI3 möglich sein wird, wird diese Funktionalität zu den neuen Versionen von WinUI 2 hinzugefügt, oder WinUI 2 funktioniert nur in Uwp-Apps.
Im Moment haben wir zum Beispiel eine WPF-App, die viel C++-Code über HwndHost verwendet, und da wir planen, alles auf WinUI zu verschieben, ist dieser Teil für uns sehr wichtig, um uns für WinUI oder etwas anderes zu entscheiden.

Es gibt ein offenes Problem für eine Möglichkeit, die Benutzeroberfläche von user32/comctl oder WPF in WinUI XAML zu hosten: https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Es sieht so aus, als ob es erst nach 3.0 erstellt wird, wenn es erstellt wird.

Ich poste das auf #1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833 aber ich werde kopieren
es auch hier: Im Moment haben wir eine WPF-App, die viel C++-Code verwendet
HwndHost-Steuerelement. Wir planen, die Wpf-App auf WinUI zu verschieben und Xaml . zu verschieben
funktioniert ohne Probleme super, aber was ist mit HwndHost, wird das sein?
möglich mit WinUI3. In unserem Fall machen wir Interoperabilität mit
DirectShow über HwndHost und derzeit in WinUI 2 ist dies nicht
möglich. Was ist ein realistisches Datum für die Verwendung von HwndHost in WinUI3? Ist auch
dieses neue Xaml-Fenster und die neue Anwendung, wie spätestens im Februar besprochen
WinUI Community-Anruf, könnte helfen oder nicht?

El dom., 23. Februar de 2020 a la(s) 13:42, Max Strini (
[email protected]) schreiben:

Wird es möglich sein, HwndHost mit WinUI 2.4 zu verwenden?
Ich habe es mit der Vorabversion versucht und das hat nicht funktioniert.
Wird es auch mit WinUI3 möglich sein mit all dem neuen geplanten
Windowing (XAML Window) und Application (XAML Application) und wenn ja wann
Wir können erwarten, dass die erste Vorschau dies sieht.
Wenn es in WinUI3 möglich sein wird, wird diese Funktionalität tatsächlich
zu den neuen Versionen von WinUI 2 hinzugefügt werden, oder WinUI 2 funktioniert nur in Uwp-Apps.
Im Moment haben wir zum Beispiel eine WPF-App, die viel C++-Code verwendet
HwndHost, und da wir planen, alles auf WinUI zu verschieben, dieser Teil
Es ist sehr wichtig für uns, uns für WinUI oder etwas anderes zu entscheiden.

Es gibt ein Problem mit der Möglichkeit, die Benutzeroberfläche von user32/comctl oder WPF darin zu hosten
WinUI-XAML: #1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Es sieht so aus, als ob es erst nach 3.0 erstellt wird, wenn es erstellt wird.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWJ63LNcom
oder abmelden
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

--
Mario Rancic
Softwareentwickler
Microsoft Certified Professional

Wirklich guter WinUI-Community-Anruf letzte Woche! Der Inhalt war sehr interessant und detailliert/technisch genug, um viele Einblicke zu geben. Die Roadmap-/Entwicklungsstatus-Updates sind auch für Benutzer von WinUI und unseren eigenen Entwicklungs-Roadmaps äußerst wertvoll. Ich freue mich auf den nächsten Anruf!

Über HwndHost in WinUI 3.
HwndHost ermöglicht das Hosten von Win32-Inhalten innerhalb von WPF. Leider gibt es in WinUI 3.0 keinen Plan, dies zu unterstützen, auch nicht in WinUI 3.0 Desktop oder WinUI Islands. Haben Sie in @mariorancic01 die UWP MediaPlayer-APIs anstelle von DirectShow evaluiert?

Nun, die Uwp-Kamera sieht besser aus, aber wir sind uns nicht sicher, ob wir sie in unserem Szenario verwenden können.
Wir verwenden Kamera als virtuelle Kamera mit DirectShow und wir brauchen sie Show
Video, um sich den Kamerastream für ein Foto zu schnappen und auch mit PjSip im
zur gleichen Zeit, bevor wir es einfach mit DirectShow machen konnten. Können wir dieses Uwp verwenden?
MediaPlayer mit PjSip.

El Mié., 26. Februar de 2020 a la(s) 23:47, Miguel Ramos (
[email protected]) schreiben:

Über HwndHost in WinUI 3.
HwndHost ermöglicht das Hosten von Win32-Inhalten innerhalb von WPF. Leider da
ist in WinUI 3.0 nicht geplant, dies zu unterstützen, auch nicht in WinUI 3.0 Desktop oder
WinUI-Inseln. Über das Szenario @mariorancic01
https://github.com/mariorancic01 beschrieben, hast du UWP bewertet
MediaPlayer-APIs statt DirectShow?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVHW15KDNC2WMment59
oder abmelden
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

--
Mario Rancic
Softwareentwickler
Microsoft Certified Professional

Ich habe eine Frage zum Windows Store für Unternehmen, das sieht sehr cool und sehr nützlich für LOB-Apps aus, aber ich habe gelesen, dass dies möglicherweise aufgegeben wird. Kann jemand etwas zu den Plänen dazu sagen.

@marionrancic01 Es ist nicht wirklich notwendig, da Sie jetzt UWP-Apps über das MSIX-Paket verteilen können.

traurig, wie @mariorancic01 finde ich auch den Windows Store for Business nützlich 😞

@leoniDEV Ich bin ehrlich neugierig, warum Sie Windows Store for Business benötigen, wenn Sie einfach als msix veröffentlichen können, wie @kmgallahan sagte

@kmgallahan @jtorjo Ich nehme an, sie suchen nach einem privaten Anwendungskatalog. MSIX bietet das meiner Meinung nach nicht? Es sei denn, Sie erstellen eine Website, auf der Sie die von Ihrem Unternehmen bereitgestellten MSIX auflisten, oder verwenden ein Verwaltungstool, um Ihren Benutzern Dinge bereitzustellen?
In ähnlicher Weise bieten die alten MSI-Installationsprogramme keine Möglichkeit, auch Apps zu entdecken.

Die Veröffentlichung im Windows Store ist kein Kinderspiel – es ist viel komplexer als Sie denken. Als erstes müssen Sie auf ein Zertifikat von MS warten - dasjenige, das Sie zum Veröffentlichen verwenden werden (ich erinnere mich gerade nicht an die genauen Schritte). Dann müssen Sie sicherstellen, dass Ihre App keine Store-Anforderungen verletzt. Dann kann es Tage dauern, bis jedes von Ihnen vorgenommene Update akzeptiert (oder abgelehnt) wird, und Sie würden sich auf den Algorithmus des Stores verlassen, damit die Leute Ihre App finden.

Aber wenn Sie sich selbst bereitstellen, wird es etwas schwierig sein, es einzurichten (ich wüsste es), aber wenn das erledigt ist, wird es kinderleicht sein. Aber ja, Sie sind dafür verantwortlich, Ihre App der Welt zu zeigen.

Als jemand, der mehrere Apps im Microsoft Store hat, einschließlich des Stores für Unternehmen, kann ich Ihnen sagen, dass die Veröffentlichung im Microsoft Store in den letzten Monaten viel besser geworden ist. Die Zertifizierung für regelmäßige Updates erfolgt manchmal innerhalb weniger Stunden. Die Store-Richtlinien sind auch ziemlich einfach zu erfüllen.
Auf der anderen Seite kann es kompliziert sein, eine eigenständige msix zu stören. Im Gegensatz zum Store, der Pakete für Sie signiert, müssen Sie Ihre App, wenn Sie Ihre App außerhalb des Stores vertreiben, selbst signieren.

@jtorjo Sie benötigen keine Zertifikate.

Um es klar zu sagen, es gibt Probleme mit dem Store und das Entwickler-Dashboard geht von Zeit zu Zeit aus, aber mein Punkt oben war, dass es ziemlich praktisch ist, den Store für Business-Apps zu haben.

Als jemand, der mehrere Apps im Microsoft Store hat, einschließlich des Stores für Unternehmen, kann ich Ihnen sagen, dass die Veröffentlichung im Microsoft Store in den letzten Monaten viel besser geworden ist. Die Zertifizierung für regelmäßige Updates erfolgt manchmal innerhalb weniger Stunden. Die Store-Richtlinien sind auch ziemlich einfach zu erfüllen.

@yaichenbaum Das ist auf jeden Fall gut zu wissen. Als ich veröffentlichte (vor 2 Jahren oder so), war es viel schwieriger. Ja, Sie müssen es selbst unterschreiben - tatsächlich kaufen Sie ein Zertifikat und unterschreiben es als Teil des "Publish"-Prozesses. Sobald Sie es eingerichtet haben, können Sie es also vergessen.

@riverar Als ich veröffentlichte (vor etwa 2 Jahren), erinnere ich mich, dass Sie einen Namen reservieren müssen und dann auf etwas warten müssen, mit dem MS Ihre App signiert (was ich mit einem Zertifikat meinte - > eine, die MS für Sie ausstellt).