Können wir über die Unterstützung von Nullable-Datentypen in Steuerelementen und Standardwerten sprechen? Als Beispiel gibt es DatePicker das DateTimeOffset zurückgibt, und CalendarDatePicker das DateTimeOffset? zurückgibt.

• Warum ist eines davon nullable, während das andere nicht ist? Liegt das daran, dass DatePicker mit früheren APIs im Windows 8-Zeitrahmen entwickelt wurde?
• Sollten wir in Betracht ziehen, eine Konfigurationseigenschaft hinzuzufügen, um null in Steuerelementen zuzulassen/nicht zuzulassen?
• Sollte eine DefaultValue Eigenschaft für neue Steuerelemente wie NumberBox in Betracht gezogen werden, sollte NaN als Standard beibehalten werden oder sollten wir zu einem nullable Double mit dem Standard null wechseln?
• Gibt es WinRT/OS-XAML-Einschränkungen beim Zurückgeben und Unterstützen von NULL-Werten, die verhindern würden, dass die Value Eigenschaft von NumberBox NULL-fähig wird? Wenn ja, wie wurde CalendarDatePicker implementiert?
• Dies steht in direktem Zusammenhang mit den NumberBox-Diskussionen in #1721 und #1708

Wie sieht außerdem der Fahrplan zur Behebung der offenen Probleme auf der NumberBox aus, die nicht von WinUI 3.0 abhängen? Es wäre großartig, dieses Steuerelement um WinUI 2.4 herum zu verwenden, anstatt länger warten zu müssen. Es ist meiner Meinung nach noch nicht vollständig gebacken und es ist mir unangenehm, dies in Produktions-Apps zu integrieren.

Eine weitere interessante Idee, über die ich mich gewundert habe: Wie sieht die Microsoft-Richtlinie zu Breaking Changes jetzt aus, da WinUI 3.0 Open Source wird?

In der Vergangenheit hat Microsoft praktisch nie bahnbrechende Änderungen vorgenommen. Dies ist im Allgemeinen eine gute Sache, bis sich das ganze Durcheinander nach ein paar (oder 10) Jahren aufgebaut hat. Es ist auch nicht der Standard für Open-Source-Projekte. Zum Beispiel sollte ListBox schließlich für ListView und MessageDialog für ContentDialog usw. auslaufen. Ich bin mir sicher, dass es auch viele nettere kleine Aufräumarbeiten in der API gibt.

Ich weiß, dass Unternehmen Veränderungen hassen – aus gutem Grund. Es MUSS auch ein relativ einfacher (funktionell gleichwertiger) Drop-In-Ersatz verfügbar sein, um die Portierung auf neue APIs unkompliziert zu machen. Dies müsste von Fall zu Fall bewertet und ein Urteil gefällt werden.

Ich frage mich, ob wir Hauptversionen (z. B. WinUI 4.0) so einrichten könnten, dass sie bahnbrechende Änderungen ermöglichen. So kann das Projekt weiter wachsen, ohne mit allen Fehlern der Vergangenheit leben zu müssen. Im Wesentlichen hat sich Microsoft bereits dazu entschieden, dies mit .NET 5 zu tun, indem es auf .NET Core basiert und das vollständige .NET Framework fallen lässt.

Dies könnte gut zu dokumentieren sein, sobald es besprochen wurde.

Basierend auf den Fortschritten seit dem letzten Aufruf, wann denkt das Team realistischerweise, dass WinUI 3 zur Veröffentlichung bereit sein wird:

• Build 2020 (April-Mai)
• Entzünden 2020 (Okt-Nov)
• ~2021

Wie stark ist Ihre Arbeit außerdem davon abhängig, dass das .NET-Team eine neue AOT-Lösung und .NET 5 zusammenstellt?

Gibt es schließlich Druck auf der Windows-Seite, es für die Veröffentlichung von Windows10X bereit zu halten und/oder davor, dass Entwickler spezialisierte Apps erstellen?

Wird/sollte es ein Tool geben, um WinUI 2.X-Projekte einfach in WinUI 3.0 zu konvertieren (da dies manuell für große Projekte viel Arbeit bedeuten kann)?

Der Elefant im Raum - WinRT (#1856)

Der Elefant im Raum - WinRT (#1856)

Ein nicht-Sandbox-App-Modell kommt – das auf die gleiche Weise wie WPF (einschließlich Win32-APIs) ausgeführt wird, jedoch mit Zugriff auf moderne WinRT-APIs und Open-Source-Benutzeroberfläche und -Steuerelementen mit dem neuen XAML, das auf Direct X 12 ausgeführt wird.

Ein nicht-Sandbox-App-Modell kommt – das auf die gleiche Weise wie WPF (einschließlich Win32-APIs) ausgeführt wird, jedoch mit Zugriff auf moderne WinRT-APIs und Open-Source-Benutzeroberfläche und -Steuerelementen mit dem neuen XAML, das auf Direct X 12 ausgeführt wird.

Beeindruckend. Wow wow!!!!

Das ist unglaublich! Haben wir dafür eine ETA, wird das im Call besprochen?

Es ist wahnsinnig toll!

Ein nicht-Sandbox-App-Modell kommt – das auf die gleiche Weise wie WPF (einschließlich Win32-APIs) ausgeführt wird, jedoch mit Zugriff auf moderne WinRT-APIs und Open-Source-Benutzeroberfläche und -Steuerelementen mit dem neuen XAML, das auf Direct X 12 ausgeführt wird.

Beeindruckend. Wow wow!!!!

Das ist unglaublich! Haben wir dafür eine ETA, wird das im Call besprochen?

Es ist wahnsinnig toll!

Es war das Erste, was wir über WinUI erfuhren. ETA ist für dieses Jahr, ich vermute, ein definitives Datum wird bei //Build/ bekannt gegeben - aber fragen Sie gerne während des Anrufs.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo Siehe die WinUI-Roadmap . Weitere Informationen (z. B. VS-Projektvorlagen) finden Sie auch unter https://github.com/microsoft/microsoft-ui-xaml/issues/1045 .

@mdtauk @Felix-Dev Ich werde diese Dokumente noch einmal lesen. Ich erinnere mich, dass ich das schon einmal gefragt habe - solange ich win2d problemlos von meiner (nicht-Sandbox-) App aus verwenden kann, werde ich mehr als glücklich sein!

@jesbis Entschuldigung für die Noob-Frage - wie kann ich an dem Anruf teilnehmen?

Wir richten die Informationen für den morgigen Anruf später heute ein - ich werde die Wegbeschreibung in ein paar Stunden posten.

Die Verzögerung liegt daran, dass wir zum ersten Mal ein neues Sendesystem verwenden - danach sollte es hoffentlich reibungsloser gehen und früher fertig sein 🙂

Ich hatte gerade einen interessanten Gedanken (für mich jedenfalls).

Beim Blick auf den heutigen Livestream der ASP.NET Community Standup sah ich im Wesentlichen 4 MS-Entwickler, die einen Livecoding-Stream machten, obwohl es eher eine technische Demo war. Ich schalte auch gelegentlich

Mein Gedanke war also - nachdem WinUI 3 veröffentlicht wurde und die Codebasis (oder das meiste davon) vollständig Open Source ist, würden irgendwelche Teammitglieder bereit sein, gelegentlich einen Teil ihrer Arbeit an WinUI live zu streamen?

Es wäre eine gute Gelegenheit, die Bekanntheit von WinUI zu erhöhen, den Leuten zu helfen, die Codebasis beiläufig zu erkunden, und ab und zu könnten Fragen gestellt werden. ~ Ich würde nicht empfehlen, die ganze Zeit über Chat-Engagement zu betreiben, da dies super kontraproduktiv wäre, aber vielleicht ab und zu eine Frage und Antwort.

Ich habe keine Ahnung, welche MS-Richtlinien für solche Dinge gelten, insbesondere während des Arbeitstages. Wäre interessant eure Gedanken zu hören.

Hier ist der YouTube-Live-Event-Link für morgen!

https://youtu.be/MXTVqgB4rW0

Danke für alle Kommentare und Fragen bisher! Wir werden versuchen, alles zu erreichen oder den Überblick zu behalten, wenn wir keine Zeit haben.

Steht in der Anleitung etwas über Leistung / fps der Benutzeroberfläche? Einer der größten Kritikpunkte, die ich mit dem modernen Windows 10 habe, ist, dass Sie auf einem Computer wie dem Surface Book eine schreckliche Leistung auf Displays mit hohen DPI-Werten erzielen, die noch schlimmer wird, wenn Sie Transparenz und zusätzliche Monitore kombinieren. Es mag unerreichbar sein, aber gibt es hier irgendwelche Überlegungen darüber, wie flüssig und gut es funktioniert, insbesondere unter diesen Bedingungen?

Bitte erwägen Sie, die Priorität von randlosen/transparenten Fenstern zu erhöhen (a la https://github.com/microsoft/microsoft-ui-xaml/issues/1247). Dies ist ein WinUI-Adoptionsblocker für Apps wie unsere .

cc: @crutkas

Bitte erwägen Sie, die Priorität von randlosen/transparenten Fenstern zu erhöhen (a la #1247). Dies ist ein WinUI-Adoptionsblocker für Apps wie unsere .

cc: @crutkas

Dies würde wahrscheinlich erfordern, dass dem WinUI-Xaml ein Top Level Window-Element mit Eigenschaften ähnlich wie WPF hinzugefügt wird. #1323

Es wäre schön, mehr über die 'Zukunft des Windowing' für WinUI zu erfahren - es gibt viele verwandte Anfragen, die zumindest gerne diskutiert / angesprochen werden könnten.

Wurden wahrscheinlich schon mal gefragt.

Für mich war es immer eine Frage der Wiederverwendbarkeit des Codes.
Dies führt zu zwei Fragen:

1. Kommt bald Unterstützung für .NET Core 3 und C# 8.0?
2. Werden wir weitere Schritte des UWP/WinUI-Teams sehen, um die Entwicklung von Uno-Plattform-Apps zu vereinfachen?

Ein anderer, wann werden wir die fehlenden Bits von WPF sehen, die in UWP unterstützt werden?

Wurden wahrscheinlich schon mal gefragt.

Für mich war es immer eine Frage der Wiederverwendbarkeit des Codes.
Dies führt zu zwei Fragen:

1. Kommt bald Unterstützung für .NET Core 3 und C# 8.0?
2. Werden wir weitere Schritte des UWP/WinUI-Teams sehen, um die Entwicklung von Uno-Plattform-Apps zu vereinfachen?

Ein anderer, wann werden wir die fehlenden Bits von WPF sehen, die in UWP unterstützt werden?

.NET Core-Code sollte auf beiden funktionieren, sodass eine WPF-App nur UI-Xaml und UI-Code ändern muss.

UWP-Apps sollten mit einer Namensraumänderung für WinUI 3.0 problemlos funktionieren - das Ausbrechen der Sandbox kann mehr Arbeit erfordern, die Details sind noch unbekannt.

Fehlende WPF-Bits wurden nicht bestätigt, aber ich habe ein Problem damit gemacht. #719

@weitzhandler

Obwohl es nicht offiziell unterstützt wird und nicht alle C# 8-Features funktionieren, können Sie den Großteil von C# 8 bereits mit WinUI/UWP verwenden. Siehe hier .

Ich mache das und habe keine Probleme. "Standardschnittstellenmitglieder und Indizes und Bereiche" scheinen die einzigen fehlenden Bits zu sein, obwohl ich nicht alles ausprobiert habe.

Ich möchte nur ergänzen, was kmgallahan über die Verwendung von C# 8 gesagt hat. Ich habe viele der neuen Funktionen verwendet, wollte aber unbedingt Default Interface Members, die noch nicht implementiert sind.

Danke Leute.
Wenn ich noch hinzufügen darf, ist der alte csproj-Typ auch irgendwie nervig.

@jesbis

Ich habe dieses Problem gerade in der Galerie für XAML-Steuerelemente geöffnet. Es könnte etwas sein, das Sie während des Anrufs besprechen können, wenn Sie möchten.

Danke, wir versuchen alle Fragen zu beantworten!

Steht in der Anleitung etwas über Leistung / fps der Benutzeroberfläche?

@ryvanvel wir haben hier einige Leistungshinweise:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

Und einige andere Blog-Posts und Videos, die helfen könnten, zB:

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

Dieser Fehler trat, soweit ich mich erinnern kann, bei Windows 10 auf, ich hoffe, er wird früher behoben: https://github.com/microsoft/microsoft-ui-xaml/issues/597

Leider kann ich nicht rechtzeitig einschalten, wird es eine Aufnahme geben?

Edit: die Aufzeichnung des Anrufs findet ihr hier: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis hier :

Hier ist der YouTube-Live-Event-Link für morgen!
https://youtu.be/MXTVqgB4rW0

Wenn du dem YT-Link folgst, sieht es so aus, als würde er erst am Ende dieser Stunde beginnen, eine Stunde später als zur regulären Zeit, ist das wahr?

@weitzhandler Die Startzeit steht ganz oben im Beitrag. Dies ist auch nur der 3. Anruf, also ist "regulär" eine Strecke.

@weitzhandler Ich bin mir ziemlich sicher, dass alle drei Anrufe bisher um 9 Uhr pazifischer Zeit beginnen sollten.

Danke euch beiden und sorry für die Mühe. Seh dich später.

Ich war gespannt, ob das mit Chromium betriebene WebView2 auch ein Ereignis wie WebResourceRequested aus dem aktuellen WebView bereitstellen wird, damit Entwickler einzelne Webanfragen herausfiltern können. Ich verlasse mich in einer meiner Apps sehr auf dieses spezielle Feature und habe mich gefragt, ob es das mit der neuen Steuerung noch geben würde und genauso funktioniert.

Danke Jungs für all die harte Arbeit! 😄🚀

Wird es ein Tool zum Generieren von PDFs geben? Win2D hat bereits viele erstaunliche Tools, die Möglichkeit, PDFs aus CanvasRenderTarget zu generieren, wird eine großartige Ergänzung sein.

habe es nicht verstanden - wie installiere ich das vsix? wo herunterladen?

Vielleicht liegt es nur an mir, aber ich war enttäuscht von dem heutigen Anruf. Bitte fügen Sie mehr technische Personen hinzu. PM sollte die Diskussion fokussiert und planmäßig halten, aber die Antworten an Experten delegieren (wie es gegen Ende mehr getan wurde).

Ich vermute, dass alle an diesem Anruf Entwickler sind, und wir müssen die Details kennen und besprechen. PMs konzentrieren sich auf sehr grundlegende Themen und können nicht ins Detail gehen. Zum Beispiel sind die Diskussionen zu Beginn des Anrufs über Dokumentation/WebView/ProgressRing vom Konzept her nett, aber so sehr einfach, dass es für uns nicht nützlich ist, denke ich. Wir verwenden XAML seit Jahren/Jahrzehnten und Sie sprechen vor einem Fachpublikum (es ist wichtig, Präsentationen an das Publikum anzupassen).

@SavoySchuler Sie haben im Wesentlichen gesagt, dass Sie uns sagen, wie wir die Kontrollen verwenden, unser Unternehmen und unsere Apps

1. Funktionen -- In diesem Fall ist das, was Sie gesagt haben, weitgehend richtig
2. Fehler/Probleme -- In diesem Fall brauchen Sie die Community nicht, um Ihnen Beispiele zur Priorisierung zu geben. Bei der Lieferung eines Produkts steht Qualität an erster Stelle. Wir erzählen Ihnen die Fehler und Sie sagen, na ja, das ist schön zu haben. Beweisen Sie, dass Sie es reparieren müssen. Es ist ein Fehler. Vielleicht haben Sie nie Apps an Verbraucher geliefert? Jede Kleinigkeit, die ÜBERHAUPT falsch ist, beeinflusst Ihr Image und Ihre Wahrnehmung, die der wertvollste Teil eines Unternehmens ist. Die App-Branche ist sehr wettbewerbsintensiv.

Sobald Fehler von der Community gemeldet wurden, sollten Sie planen, dass sie behoben werden. Stoppen Sie den Versand unvollständiger Kontrollen ohne Pläne, sie zu beheben. Das kommt einem sehr bekannt vor – so ist es mit UWP vor Jahren passiert.

In dem Anruf habe ich zweimal Windowing angesprochen und es wurde Folgendes erwähnt:

• daran wird tatsächlich für WinUI 3 gearbeitet (obwohl das Problem eingefroren wurde https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• das Feature-Tracking-Projekt (gestern aktualisiert) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) verfolgt nur WinUI 2-Zeug???

Können wir hier Klarheit schaffen? Gibt es einen anderen Ort, um das WinUI 3-Backlog anzuzeigen? Für Planungszwecke ist es äußerst wichtig, dass wir wissen, was kommt und was nicht. Vielen Dank!

@SavoySchuler @jesbis und dem Rest des lieben WinUI-Teams, ich möchte mich persönlich für Ihre großartige Arbeit und Ihren massiven Einsatz bedanken und Ihnen sagen, wie dankbar ich dafür bin, WinUI so großartig zu machen und alle meine Fragen zu beantworten.

Herzlichen Dank an alle, die mitmachen konnten!

Und noch einmal Entschuldigung für die Audio- und Teams-Probleme - wir glauben, dass wir ein Hardwareproblem identifiziert haben und hoffentlich alles für nächsten Monat behoben haben.

Die Aufnahme ist jetzt auch live für alle, die es nicht geschafft haben.

Wir gehen die Fragen durch und werden versuchen, alles zu finden, was wir in diesem Thread übersehen haben.

Einige Fragen zum Aufholen:

Wird es ein Tool zum Generieren von PDFs geben?

@MuziburRahman

Wir werden für WinUI 3.0 RTM keine Zeit haben, dazu zu kommen, aber wir verfolgen dies im Backlog mit #672 - Sie können gerne einen Kommentar zu diesem Problem hinzufügen, wie Sie es verwenden würden!

Wie installiere ich den vsix? wo herunterladen?

@hannespreishuber

Die WinUI 2.x-Nutzungsanweisungen für Produktions-Apps finden Sie hier: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

Die WinUI 3.0 Alpha-Anweisungen zum Installieren und Ausprobieren des vsix finden Sie hier:
https://aka.ms/winui/alpha

Vielleicht liegt es nur an mir, aber ich war enttäuscht von dem heutigen Anruf. Bitte fügen Sie mehr technische Personen hinzu. PM sollte die Diskussion fokussiert halten [...] Wir verwenden XAML seit Jahren/Jahrzehnten und Sie sprechen vor einem Fachpublikum (es ist wichtig, Präsentationen an das Publikum anzupassen).

@robloo danke für das Feedback dazu. Wir können mehr Entwickler einbeziehen und mehr Deep-Dives zu bestimmten Themen für zukünftige Anrufe machen, wenn das für alle von Interesse ist - das wollten wir beim ersten Anruf nicht versuchen, da es schon eine Weile her ist und wir wollten einen allgemeinen Fang machen- hoch.

Wir haben in der Vergangenheit auch Feedback bekommen, dass wir manchmal zu technisch und zu tiefgreifend werden, weil ein Großteil des Publikums mit WinUI noch nicht so gut vertraut ist – also versuchen wir auch, dieses Feedback auszugleichen.

Außerdem, wenn es hilft zu beachten: Viele unserer PMs in den Entwicklerplattform-Teams sind super technisch und haben Erfahrung mit dem Schreiben von Produktionscode für große Plattformen und echte Apps. Einige von ihnen waren zuvor Vollzeitentwickler bei Microsoft und anderen Unternehmen. Wir schreiben auch immer noch die ganze Zeit Code als PMs, es ist nur nicht unser einziger Fokus 🙂

Abschließend noch zu Bugs und Qualität: Qualität ist uns sehr wichtig und wir verbringen viel Zeit mit Bugs, Tests und Qualitätsinfrastruktur. Sie können das Verhältnis von Qualitätskorrekturen zu neuen Funktionen im Commit-Log für WinUI 2 sehen, und sobald es Open Source ist, können Sie dasselbe für WinUI 3 sehen. Allerdings ist keine große Codebasis fehlerfrei und wir müssen immer geschäftliche Prioritäten abwägen.

Wenn die Kontrollen unvollständig erscheinen, stellen Sie bitte offene Fragen für sie.

In dem Anruf habe ich zweimal Windowing angesprochen und es wurde Folgendes erwähnt:
Daran wird derzeit für WinUI 3 gearbeitet (obwohl das Problem eingefroren wurde #1247)
das Feature-Tracking-Projekt (gestern aktualisiert) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) verfolgt nur WinUI 2-Zeug???
Können wir hier Klarheit schaffen? Gibt es einen anderen Ort, um das WinUI 3-Backlog anzuzeigen? Für Planungszwecke ist es äußerst wichtig, dass wir wissen, was kommt und was nicht. Vielen Dank!

@riverar, dass das Projektboard derzeit für WinUI 2 ist, da es derzeit der einzige Code im Repository ist.

Wir verwenden das Label needs-winui-3 für Probleme, die auf WinUI 3 warten müssen, bevor sie ordnungsgemäß behoben werden können, aber wir haben noch kein öffentliches Tracking für unsere WinUI 3-Arbeit.

Wir werden weiterhin Funktionsvorschläge für wichtige Elemente veröffentlichen – wie die Chromium WebView-Spezifikation im separaten Specs-Repo:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

und sobald wir in der Lage sind, WinUI 3 Xaml als Open-Source zu öffnen, können wir damit beginnen, das Tracking auf GitHub zu verschieben, aber der Großteil unseres täglichen Workitem-Trackings wird aus verschiedenen Gründen realistischerweise während der Entwicklung von 3.0 intern bleiben (wir haben viele privater Betriebssystemabhängigkeiten zu entwirren, enge Zusammenarbeit mit anderen Entwicklerteams von Betriebssystemkomponenten usw.)

Ich kann jedoch sagen, dass die meisten dieser mit Tags versehenen Funktionsvorschläge für die erste Version 3.0 nicht berücksichtigt werden - unsere Hauptschwerpunkte sind:

• WinUI vom Betriebssystem entkoppelt und separat geliefert bekommen
• Open-Sourcing des Xaml-Frameworks
• Erstellen einer guten WinUI-Desktop-App-Entwicklungserfahrung (Win32-Nutzung, Paketierung, Windowing usw.)
• Aktivieren von Windows 10X
• Aktivieren von .NET Core/5 + WinUI-Apps

und wir wollen das nicht verzögern oder destabilisieren, indem wir gleichzeitig eine Menge zusätzlicher neuer Features entwickeln.

Wenn wir in großen Bereichen wie Desktop-/Fensterunterstützung konkrete Fortschritte machen, werden wir Vorschläge und Aktualisierungen zum Repository veröffentlichen.

und sobald wir in der Lage sind, WinUI 3 Xaml als Open-Source zu öffnen, können wir damit beginnen, das Tracking auf GitHub zu verschieben, aber der Großteil unseres täglichen Workitem-Trackings wird aus verschiedenen Gründen realistischerweise während der Entwicklung von 3.0 intern bleiben (wir haben viele privater Betriebssystemabhängigkeiten zu entwirren, enge Zusammenarbeit mit anderen Entwicklerteams von Betriebssystemkomponenten usw.)

Wäre es möglich, diese internen Arbeitsaufgaben öffentlich aufzulisten, auch wenn sie als leere Einträge mit einem generischen Namen wie Internal Issue erscheinen ? Wenn Sie sehen, dass sich diese von To Do zu In Progress und zu Complete bewegen, würde dies auf einen gewissen Fortschritt für das gesamte Projekt hindeuten.

Ich kann jedoch sagen, dass die meisten dieser mit Tags versehenen Funktionsvorschläge für die erste Version 3.0 nicht berücksichtigt werden - unsere Hauptschwerpunkte sind:

• WinUI vom Betriebssystem entkoppelt und separat geliefert bekommen
• Open-Sourcing des Xaml-Frameworks

Dies ist natürlich der Kern des Bestrebens, aber es kann möglich sein, verschiedene Probleme oder Probleme mit der aktuellen Implementierung zu lösen, da sie aus dem Betriebssystemcode herausgelöst wird.

• Erstellen einer guten WinUI-Desktop-App-Entwicklungserfahrung (Win32-Nutzung, Paketierung, Windowing usw.)
• Aktivieren von Windows 10X

Dies ist unerlässlich, um das Richtige zu tun, und erfordert, dass beide Dinge in die Hände von Benutzern und Entwicklern gelegt werden, die offen für Feedback sind. Es wird auch schwierig sein, weil die App-Laufzeit und das App-Modal nicht im Besitz dieses WinUI-Teams sind und daher die Möglichkeit geschaffen werden muss, Feedback an die Verantwortlichen zu filtern.

• Aktivieren von .NET Core/5 + WinUI-Apps

Die aktuelle native Unterstützung kommt in Form von C++-Code und Win32-APIs – aber bedeutet dies, dass alle C#-Entwickler auf .NET abzielen müssen? Erlaubt das App-Modell ohne Sandbox die C#-Codierung ohne .NET?

und wir wollen das nicht verzögern oder destabilisieren, indem wir gleichzeitig eine Menge zusätzlicher neuer Features entwickeln.

Wenn wir in großen Bereichen wie Desktop-/Fensterunterstützung konkrete Fortschritte machen, werden wir Vorschläge und Aktualisierungen zum Repository veröffentlichen.

Ohne CoreWindow (das in Zukunft nur UWP sein wird) - Windowing ist eines der Dinge, die vom ersten Tag an vorhanden sein müssen. WPF hat ein Window-Objekt in XAML, das die Steuerelemente, das visuelle Styling, die Transparenz usw. behandelt. Es behandelt die Größenänderung, Minimierung usw. Ältere Win32-Frameworks erfordern manuelles Malen von Oberflächen, die für XAML-Benutzeroberflächen nicht relevant sind – wie wird diese Lücke überbrückt? ?

Dies ist, bevor wir überhaupt zu Dual-Screening-Geräten kommen und wie sich ein Nicht-UWP-App-Modell und ein Windowing-Setup daran anpassen würden.

Wäre es möglich, diese internen Arbeitsaufgaben öffentlich aufzulisten, auch wenn sie als leere Einträge mit einem generischen Namen wie Internes Problem erscheinen?

Unser Ziel ist es auf jeden Fall, unsere Prozesse (inklusive Issue Tracking) zusätzlich zum Code auf Open Source umzustellen.

Zu Beginn haben wir einen WinUI 3.0-Meilenstein für das High-Level-Tracking und während wir WinUI 3-Xaml-Code zu Open Source migrieren, werden wir in diesem Meilenstein auch mehr "Feature-Level"-Probleme öffnen.

Dies umfasst jedoch nicht sofort alle unsere täglichen Entwicklungsaufgaben in WinUI 3.0 – als Referenz verfolgen wir derzeit Tausende von Tagen an verwandter Entwicklungsarbeit für 2020 und sind einfach noch nicht bereit, alle zu verschieben unser supergranulares Tracking zu GitHub heute. Wir werden jedoch im Laufe der Zeit dazu kommen, wie wir es bei WinUI 2 getan haben.

Wir beginnen also mit Problemen auf Funktionsebene (wie bisher begonnen - zB WebView) und werden unsere Prozesse im Laufe der Zeit vollständig auf GitHub migrieren.

Die aktuelle native Unterstützung kommt in Form von C++-Code und Win32-APIs – aber bedeutet dies, dass alle C#-Entwickler auf .NET abzielen müssen? Wird das App-Modell ohne Sandbox die C#-Codierung ohne .NET ermöglichen?

Fragen Sie nach .NET Native oder gar nicht nach .NET? Technisch denke ich, dass die C#-Spezifikation als Sprache nicht von .NET abhängt, aber wir haben derzeit keine Pläne für eine Übertragung auf C++ oder ähnliches.

Ohne CoreWindow (das in Zukunft nur UWP sein wird) - Windowing ist eines der Dinge, die vom ersten Tag an vorhanden sein müssen. WPF hat ein Window-Objekt in XAML, das die Steuerelemente, das visuelle Styling, die Transparenz usw. behandelt. Es behandelt die Größenänderung, Minimierung usw. Ältere Win32-Frameworks erfordern manuelles Malen von Oberflächen, die für XAML-Benutzeroberflächen nicht relevant sind – wie wird diese Lücke überbrückt? ?

@marb2000 arbeitet daran und wird je nach Verfügbarkeit weitere Informationen teilen können.

Dies ist, bevor wir überhaupt zu Dual-Screening-Geräten kommen und wie sich ein Nicht-UWP-App-Modell und ein Windowing-Setup daran anpassen würden.

Um es klar zu sagen, WinUI 3 wird nicht den gesamten Win32-Desktop auf andere Plattformen wie HoloLens bringen: universelle Apps und APIs werden immer noch der richtige Weg sein, wenn Sie auf mehrere Geräte abzielen.

Zu früh gepostet. Vollständiger Kommentar:

@robloo - Ich möchte zunächst vielen Ihrer

Charta und Ressourcen

Ich weiß, dass es nie populär sein wird, ein Thema wie dieses zu behandeln, aber ich glaube an Transparenz und möchte mit Ihnen als Community offen über die Herausforderungen sprechen, denen wir gegenüberstehen, damit Sie Teil der Diskussion sein können und uns bei der Entscheidung helfen, wie wir sie lösen . Diese besondere Herausforderung konzentriert sich auf die Teilung von Zeit und Ressourcenressourcen. Es gibt drei Hauptinitiativen, auf die unser Team aufgeteilt ist:

1. Weiterentwicklung von WinUI 2
2. Bereitstellung von WinUI 3
3. Open-Sourcing-WinUI 3

Wie Sie wissen, sind wir fest auf 2 und 3 eingestellt, weil A) dies gekoppelte Ziele sind und B) Open Sourcing WinUI bedeutet, dass jeder aufhören kann, von den endlichen Ressourcen unseres Teams blockiert zu werden, da WinUI endlich die Möglichkeit hat, Community-Pull-Requests anzunehmen.

Wenn wir bei den Zielen 2 und 3 zu weit vordringen, bis WinUI 2 die Community-Mitglieder unterversorgt, können wir dieses Gespräch führen und sind offen dafür, neue Prioritäten zu setzen. Wisse nur, dass die Behebung aller Fehler in unserem Backlog die Markteinführung von WinUI 3 um ~6 Monate verzögern würde. Sollten wir stattdessen 2 und 3 priorisieren, was nicht nur WinUI Open Source ist, sondern seine Relevanz auf unsere massive Basis von Win32-Entwicklern ausdehnt, können wir unseren Rückstand von Fehlern _und_ Funktionsanfragen mit der Kraft der Open-Source-Community und unseres Teams bereinigen ungeteilte Aufmerksamkeit, die uns unterstützt. Zu diesem Zweck ist unser derzeitiger Grundgedanke, dass dieser Plan diese Plattform nicht nur schneller, sondern auch umfassender voranbringen würde. Als ich Sie bat, uns bei der Priorisierung von Fehlern zu helfen, lautete die Frage nicht: "Sind sie wichtig genug, damit unser Team sie angehen kann?" aber stattdessen "ist dies wichtig als frühere Open-Sourcing-WinUI?" Beim Status quo haben wir eine Untergruppe von Entwicklern, die daran arbeiten, Priorität 1 voranzutreiben, und Sie können ihren Einfluss in unserer Commit-Historie und aktiven Problemen sehen, aber sie müssen trotzdem Prioritäten innerhalb dieses Ziels setzen. Diese Vorstellung von "Sag uns, wie wichtig das für dich ist" hilft uns, Bedürfnisse zu filtern (z. B. mein Produkt ist blockiert und ich kann WinUI 3 nicht erwarten) vs. Feinheiten (z. B. habe ich diesen technischen Fehler bemerkt, aber keine vorhandene Entwicklung). ist darauf blockiert, damit es auf WinUI 3 warten kann.

Die andere Sache, die ich klar sagen möchte, ist, dass die ganze Arbeit, die in die Einreichung von WinUI 2-Fehlern, das Ausfüllen von Funktionsanforderungen usw. gesteckt wird, _ nicht _ für uns verloren geht. Wenn WinUI 3 veröffentlicht wird, haben wir einen erheblichen Teil unseres Teams frei, um zu Arbeitselementen zurückzukehren, die die Plattform voranbringen, und der Community auch die Möglichkeit zu geben, Code einzureichen. Das bedeutet, dass wir im Moment einen Rückstand aufbauen, den die ganze Kraft unseres Teams mit Hilfe unserer bestehenden UWP-Community und bald auch Win32 angehen wird.

Eine zusätzliche Sache, die Sie beachten sollten, ist, dass wir während der Migration von Code vom Betriebssystem auf WinUI 3 Schritte unternehmen, um den Code dahinter zu vereinfachen und zu bereinigen, wo wir können. Dies bedeutet, dass bestimmte Funktionserweiterungen und Fehlerbehebungen messbar weniger Zeit und Aufwand erfordern, wenn sie in WinUI 3 behoben werden.

NumberBox

Merkmale

Kehren wir zu NumberBox zurück. Sie haben tatsächlich Recht, wenn Sie sagen, dass V1 eine Teilmenge der gewünschten Funktionen ist.
Geplante V1-Funktionen wurden aufgrund von Abhängigkeiten von Dingen wie der Eingabevalidierung (die sich übrigens in der Vorschau in der WinUI 3-Alpha-Version befindet) auf V2 verschoben. Wir haben versucht, in unserer Spezifikation vollständig zu sein, indem wir alles anerkennen, was unserer Meinung nach V1 in der Spezifikation verdient (hier) und planen, diese Verpflichtung mit einer WinUI 3 V2-Version des Steuerelements vollständig zu erfüllen.

Indem ich den Geist von Open Source annehme, ist es mein Wunsch (und bitte sagen Sie mir, ob ich damit falsch liege), es vorzuziehen, so schnell wie möglich zuverlässigen, nützlichen Code zu veröffentlichen und die Feature-Sets inkrementell aufzubauen. In der Anwendung bedeutete dies, dass wir es vorziehen, unsere _meistens_ vollständige V1 in WinUI 2 zu veröffentlichen und ihr eine voll funktionsfähige Version mit Eingabevalidierung wie bei WinUI 3 folgen zu lassen.

Fehler

Wie @jesbis sagte, ist keine Codebasis fehlerfrei, aber Qualität steht für uns absolut im @jesbis bemerkt, Sie können das Verhältnis von Qualitätskorrekturen zu neuen Funktionen im Commit-Protokoll für WinUI 2 sehen, und sobald es Open Source ist, können Sie dasselbe für WinUI 3 sehen.

Ich bin weiterhin bestrebt, diese Fehler mit NumberBox zu beheben, und nehme mir den Rest des Tages Zeit, um auf offene Probleme, Fehler und Fragen zu reagieren, bei denen ich eine Bereicherung sein kann. Ich werde nächste Woche auch einen Tag beiseite legen. Bitte fühlen Sie sich ermutigt, mir Fragen auf Twitter zu senden oder mich hier im Repo zu kontaktieren.

Nächste Schritte

Open Source ist für uns das Versprechen, die Community als Teammitglieder zu umarmen, als säßen sie hier in unserem Büro in Redmond. Wir hören zu. Lassen Sie uns gemeinsam über diese Entscheidungen sprechen, damit wir uns darauf konzentrieren können, großartige Dinge als ein großes Team aufzubauen. 🙂

Wir ❤️ WinUI

Indem ich den Geist von Open Source annehme, ist es mein Wunsch (und bitte sagen Sie mir, ob ich damit falsch liege), es vorzuziehen, so schnell wie möglich zuverlässigen, nützlichen Code zu veröffentlichen und die Feature-Sets inkrementell aufzubauen. In der Anwendung bedeutete dies, dass wir es vorziehen, unsere größtenteils vollständige V1 in WinUI 2 zu veröffentlichen und ihr eine voll funktionsfähige Version mit Eingabevalidierung wie bei WinUI 3 folgen zu lassen.

Dies könnte nur ich sein, aber ich denke, dass es zwar wichtig ist, Code so schnell wie möglich zu versenden, es gibt jedoch bestimmte Arten von Problemen, die vor dem Versand von etwas gelöst werden sollten, zum Beispiel #1846 ist etwas, das vor dem Versand von V1 und dort angegangen werden sollte können auch ein paar andere sein.

@yaichenbaum Da hätte ich meine Worte besser

Wenn AD _muss-have_-Features sind und EH _nice to have_-Features sind, ist es meine Priorität, AD aus der Tür zu bekommen und EH schrittweise hinzuzufügen.

Der Grund, warum wir Staging in einem Preview-Branch mit Validierungspartnern durchführen, besteht darin, Fehler wie #1846 abzufangen, bevor die Steuerelemente auf eine stabile Veröffentlichung verschoben werden. Es tut uns leid, dass wir hier den Ball verloren haben, ich werde so schnell wie möglich mit @teaP zusammenarbeiten, um zu sehen, wie schnell wir das Problem lösen können! 🙂

An einer Stelle des Anrufs wurde erwähnt, dass WinUI-Apps Sandboxing über AppDomain ermöglichen würden.

Kann jemand darüber sprechen, wie WinUI 3.0+ Capabilities vs. AppDomain für die Anwendungsisolation und Ressourcenkontrolle positioniert?

Außerdem, das letzte, was ich für .Net Core wusste, gab es keine vollständige Unterstützung für AppDomain.

Vielleicht bin ich nicht erreichbar, aber sagen Sie, dass .Net 5 volle AppDomain-Unterstützung haben wird?

Danke, dass Sie diesen Anruf heute organisiert haben!

Kann jemand darüber sprechen, wie WinUI 3.0+ Capabilities vs. AppDomain für die Anwendungsisolation und Ressourcenkontrolle positioniert?

Tut mir leid, wenn es im Anruf nicht klar war, aber ich sprach von AppContainer , nicht von AppDomain.

Ah, ok, danke für die Klarstellung Jesse.

Zunächst einmal vielen Dank @jesbis (und dem ganzen Rest des WinUI-Teams) für die Organisation des heutigen Community-Calls! Obwohl es einige technische Schwierigkeiten gab, war dieser Anruf sehr aufschlussreich !!!

Wie @jesbis erwähnt, gibt es ein Problem bei der Verfolgung der für WinUI 3.0 angeforderten Tools und Funktionen. Wäre es besser, die Anfrage eines Konvertierungstools von WinUI 2.x zu 3.0 in eine separate Ausgabe aufzuteilen, um das Tracking zu erleichtern? Gibt es auch schon Pläne? Gibt es Pläne, das Tool Open Source zu machen, damit andere Entwickler bei der Entwicklung helfen können?

Eine weitere allgemeinere Frage (die auch für andere Nicht-WinUI-Teammitglieder gelten würde) betrifft den Beitrag. Gibt es derzeit Hindernisse, die Menschen daran hindern, Beiträge zu leisten? Wäre ein besserer Einstiegsleitfaden für Mitwirkende hilfreich?

Meiner Meinung nach kann das VS-Projekt etwas überwältigend sein, wenn Sie anfangen, zum Projekt beizutragen, und es gibt nicht viel Dokumentation darüber, wie man entwickelt, welches Testprojekt wofür verwendet werden sollte usw.

Vielleicht würden Verbesserungen in diesem Bereich es den Leuten erleichtern, etwas beizutragen 😅

Wie wird der Rendering-Layer von WinUI 3.0 erstellt? Verwendet es direkt D3D11, D2D, Abstraktionsschicht oder was? Hat es einen Software-Rendering-Layer oder verwendet es dafür D3D WARP?

@chingucoding

Ich wiederhole die Punkte, die ich gerade hier gemacht habe :

• Ich habe die Lang schon ewig nicht mehr benutzt
• Keine Ahnung, wie viel Code-Curn im Hintergrund für die WinUI 3-Version stattfindet, die die heute vorgenommenen Änderungen überschreiben würde
• Kein Zugriff auf einen Haufen Quellcode, der benötigt würde und/oder enorm bei der Bearbeitung von Problemen helfen würde

Edit: Ich gebe ein Beispiel. #1555 und #1849 sind anscheinend große Probleme mit einem Kernsteuerelement (TextBox), das die Texteingabe und -auswahl beim Multitasking verhindert.

Sie stehen ganz oben auf meiner Liste wichtiger Probleme, die gelöst werden sollten, aber ich habe keine Ahnung, wo ich anfangen soll. Ich weiß auch nicht, ob der Code, den ich zum Debuggen durcharbeiten möchte / muss, verfügbar ist.

@SavoySchuler

Wenn wir bei den Zielen 2 und 3 zu weit vordringen, bis WinUI 2 die Community-Mitglieder unterversorgt, können wir dieses Gespräch führen und sind offen für neue Prioritäten. Wisse nur, dass die Behebung aller Fehler in unserem Backlog die Markteinführung von WinUI 3 um ~6 Monate verzögern würde.

Ich verstehe auf jeden Fall. Allerdings ist NumberBox hier in meinen Augen etwas anders und ich sage sicherlich nicht, dass wir uns auf alle Fehler konzentrieren sollten. Im Moment werde ich nur im Zusammenhang mit der NumberBox sprechen. Obwohl es sicherlich noch einige andere eklatante Probleme gibt, die angegangen werden müssen.

NumberBox ist ein neu entwickeltes Steuerelement für WinUI 2.3 und kein Legacy-Steuerelement, das an dieser Stelle jeder akzeptieren muss. Warum sollten wir das nicht richtig machen, um zu starten? Dies ist ein Lackmustest für das neue Entwicklungsmodell.

Wenn AD Funktionen haben müssen und EH Funktionen haben, ist es meine Priorität, AD aus der Tür zu bekommen und EH nach und nach hinzuzufügen.

Ich stimme dir hier voll und ganz zu. Aber Sie müssen den Unterschied zwischen Funktionen und Fehlern verstehen. Mich beunruhigt, dass Sie nur in Ressourcen/Manpower für Microsoft denken. Haben Sie jedoch daran gedacht, dass App-Entwickler unzählige Stunden damit verschwenden, Fehler in den Steuerelementen zu umgehen? Es ist viel effizienter, diese Dinge an der Quelle zu beheben und hilft auch wirklich bei der Wahrnehmung der Plattform/des Tools.

Die andere Sache, die ich klar sagen möchte, ist, dass die ganze Arbeit, die in die Einreichung von WinUI 2-Fehlern, das Ausfüllen von Funktionsanforderungen usw. Wenn WinUI 3 veröffentlicht wird, haben wir einen erheblichen Teil unseres Teams frei, um zu Arbeitselementen zurückzukehren, die die Plattform voranbringen, und der Community auch die Möglichkeit zu geben, Code einzureichen.

Microsoft hat eine wirklich schlechte Erfolgsbilanz darin, unvollständige Software zu veröffentlichen und dann mit der nächsten neuesten und besten Technologie fortzufahren, bevor sie die Chance hat, die letzte abzuschließen. Bitte verzeihen Sie mir, dass ich Ihrem Versprechen skeptisch gegenüberstehe.

Kehren wir zu NumberBox zurück. Sie haben tatsächlich Recht, wenn Sie sagen, dass V1 eine Teilmenge der gewünschten Funktionen ist.
...Indem ich den Geist von Open Source annehme, ist es mein Wunsch (und bitte sagen Sie mir, ob ich damit falsch liege), es vorzuziehen, so schnell wie möglich zuverlässigen, nützlichen Code zu veröffentlichen und die Feature-Sets inkrementell aufzubauen.

Völlig auf der gleichen Seite mit Ihnen in Bezug auf die Funktionen. Bugs sind anders. Sie müssen Fehler anders angehen als Funktionen und mehr Ressourcen dafür bereitstellen. Es sieht einfach schlecht aus, ein brandneues Steuerelement wie NumberBox zu veröffentlichen und dann zu sagen, dass Sie erst in einem Jahr Ressourcen für die Behebung von Fehlern bereitstellen können.

Ich bitte Sie, die Fehler in V1 des Steuerelements zu beheben, die nicht von WinUI 3.0 abhängen. Einige sind ziemlich einfach und andere sind eklatante Fehler im Design (wie NaN, das bidirektionale Daten zum Absturz bringt). Sobald Sie sich zur Freigabe einer Funktion/eines Steuerelements verpflichtet haben, müssen Sie schnell daran arbeiten, die Fehler zu schließen. Es gibt IMMER Fehler, wenn Software ihre erste breite Version hat. Sie müssen nur Ressourcen planen, um eine schnelle Fehlerbehebung V2 durchzuführen (wie der Rest von uns App-Entwicklern). Da wir uns einig sind, dass Qualität oberste Priorität hat, beheben Sie bitte die folgenden Probleme mit NumberBox, bevor Sie sich anderen Dingen widmen.

1708 - Platzhaltertext ist bei jeder Formularverwendung des Steuerelements unbedingt erforderlich und eine der grundlegenden Funktionen, die bereits in der Spezifikation enthalten sind. Wenn dies für NaN tatsächlich behoben wurde, sollten wir es schließen. Null-Support ist ein anderes Thema unten.

1721 - Ein großes Problem mit UWP war die unvollständige Unterstützung für die Datenbindung in bestimmten Steuerelementen. Viele Anwendungsentwickler haben vor Jahren in MVVM-Design investiert und dann beim Versuch, auf UWP-Steuerelemente umzusteigen, festgestellt, dass die Datenbindung nur teilweise unterstützt wird. Dies ist ein großer Schmerzpunkt und inakzeptabel, wenn man bedenkt, wie grundlegend MVVM für die Best Practices von Microsoft ist. Das alte Windows-Entwickler-Tooling-Team würde das niemals ertragen - das ist Windows/natives Denken hier.

1839 - Grundlegendes hier. Dies sind nur grundlegende Fehler in der Steuerelementvorlage und MÜSSEN behoben werden. Keine Ausreden.

1846 - Wir hatten dieses Problem schon bei so vielen anderen Kontrollen. Warum gibt es noch keine Release-Checkliste, die dies testet? Wieder grundlegende Dinge, die repariert werden müssen. Es wirkt sich auf die Benutzerfreundlichkeit aller Apps aus, die dieses Steuerelement verwenden.

1852, #1853, #1854 - Auch diese sind nicht allzu kompliziert und wurden bei der ersten Implementierung nur übersehen. Es ist jedoch gesetzlich vorgeschrieben, die Barrierefreiheit in Software zu unterstützen, die in bestimmten Regionen verkauft oder für die Regierung entwickelt wurde. Als Plattform sollten Sie dies sofort beheben, damit Anwendungsentwickler das Steuerelement verwenden können. Nochmal, ich sollte diese Art von Dingen nicht mit Ihnen diskutieren müssen, es sind grundlegende Dinge.

Eine zusätzliche Sache, die Sie beachten sollten, ist, dass wir während der Migration von Code vom Betriebssystem auf WinUI 3 Schritte unternehmen, um den Code dahinter zu vereinfachen und zu bereinigen, wo wir können. Dies bedeutet, dass bestimmte Funktionserweiterungen und Fehlerbehebungen messbar weniger Zeit und Aufwand erfordern, wenn sie in WinUI 3 behoben werden.

Verstehen Sie auf hohem Niveau. Die Behebung der oben genannten Probleme wird WinUI 3.0 jedoch nicht um 6 Monate verzögern. Sie hängen auch nicht von WinUI 3.0 ab, um sie zu adressieren (außer möglicherweise für #1721). Sie schaffen einen gefährlichen Präzedenzfall, indem Sie NumberBox freigeben und dann nicht daran festhalten, um die erste Runde von Fehlern zu schließen. Diese Lektion sollten Sie bereits mit UWP selbst gelernt haben.

Vielleicht würden Verbesserungen in diesem Bereich es den Leuten erleichtern, ihren Beitrag zu leisten

Würde gerne dazu beitragen. Arbeiten Sie nicht gerne mit C++/WinRT und fühlen Sie sich sicherlich nicht qualifiziert, die Codebasis zu berühren, wie ich sie gesehen habe. Wenn Steuerelemente in C# verwaltet würden, hätten Sie viel mehr Beiträge erhalten. Ich verstehe, warum die Architektur so ist, wie sie ist, aber eine der Folgen sind weniger Gemeinschaftsbeiträge. Wir sind hier keine Systementwickler, wir sind Endbenutzer-App-Entwickler.

RE: Beitrag:

Eine weitere allgemeinere Frage (die auch für andere Nicht-WinUI-Teammitglieder gelten würde) betrifft den Beitrag. Gibt es derzeit Hindernisse, die Menschen daran hindern, Beiträge zu leisten? Wäre ein besserer Einstiegsleitfaden für Mitwirkende hilfreich?
Meiner Meinung nach kann das VS-Projekt etwas überwältigend sein, wenn Sie anfangen, zum Projekt beizutragen, und es gibt nicht viel Dokumentation darüber, wie man entwickelt, welches Testprojekt wofür verwendet werden sollte usw.
Vielleicht würden Verbesserungen in diesem Bereich es den Leuten erleichtern, ihren Beitrag zu leisten

Nichts sollte Leute davon abhalten, zu WinUI 2 beizutragen, der Codebasis, die sich derzeit im Repository befindet. Wenn Sie an einem WinUI 2-Problem arbeiten möchten, teilen Sie uns dies bitte mit und wir können es Ihnen zuweisen!

Wir haben viele Artikel mit guter Erstausgabe und Hilfe gesucht, wenn jemand mit Artikeln helfen möchte, mit denen (relativ) einfach zu beginnen sein sollte 🙂

Für Bugfixes können Sie einfach eine PR öffnen. Wenn es sich um eine wichtige neue Funktion handelt, müssen wir das Problem zuerst überprüfen , um sicherzustellen, dass der Vorschlag gut für WinUI geeignet ist.

Ich stimme voll und ganz zu, dass der Leitfaden für Mitwirkende besser sein könnte und dass der Anfang schwer ist - ich habe vor kurzem versucht, ihm zu folgen, um eine neue Funktion ( RadialGradientBrush ) zu implementieren, und festgestellt, dass er viele Verbesserungen gebrauchen könnte - er ist jetzt auf meinem Todo-Liste, um die Anleitung zu verbessern.

Ich gebe ein Beispiel. #1555 und #1849 sind anscheinend große Probleme mit einem Kernsteuerelement (TextBox), das die Texteingabe und -auswahl beim Multitasking verhindert.
Sie stehen ganz oben auf meiner Liste wichtiger Probleme, die gelöst werden sollten, aber ich habe keine Ahnung, wo ich anfangen soll. Ich weiß auch nicht, ob der Code, den ich zum Debuggen durcharbeiten möchte / muss, verfügbar ist.

Diese müssen noch von unseren Entwicklern sortiert (kategorisiert) werden (daher das Label "braucht-triage" - ich verfolge derzeit, warum sie es noch nicht getan haben, sorry), aber ich erwarte das, da TextBox nicht dabei ist WinUI 2 müssen diese auf WinUI3 warten.

Sobald sie eine Triage erhalten haben, sollten sie das Label Needs-winui-3 erhalten , das angibt, dass sie auf WinUI 3 warten müssen, bevor wir sie bearbeiten können.

Sobald WinUI 3 Open Source ist, kann jeder auch bei der Lösung dieser Probleme helfen.

Arbeiten Sie nicht gerne mit C++/WinRT und fühlen Sie sich sicherlich nicht qualifiziert, die Codebasis zu berühren, wie ich sie gesehen habe. Wenn Steuerelemente in C# verwaltet würden, hätten Sie viel mehr Beiträge erhalten.

Wir wissen, dass C++ eine höhere Barriere darstellt als C#, aber der Plan ist, dass WinUI eine C++-Plattform bleibt.

Ein weiteres großartiges Projekt, zu dem Sie beitragen können, ist das Windows Community Toolkit, zu dem Sie leichter beitragen können, da es C# ist und einige gelockerte Anforderungen hat.

Wir arbeiten mit den Betreuern zusammen und verwenden häufig das Community Toolkit, um neue Steuerelemente zu inkubieren, die schließlich auf die Xaml-Plattform migrieren (was eine Neuimplementierung in C++ beinhaltet).

Benötigt WinUI C++/CX? Wenn ja, scheint dies ein Problem für Win32 und andere zukünftige Ziele zu sein?

Wie wird der Rendering-Layer von WinUI 3.0 erstellt? Verwendet es direkt D3D11, D2D, Abstraktionsschicht oder was? Hat es einen Software-Rendering-Layer oder verwendet es dafür D3D WARP?

Das Rendering des WinUI Xaml-Frameworks wird hauptsächlich in der Windows 10-Kompositions-Engine implementiert. Die APIs der Kompositionsebene werden auch Teil von WinUI 3.

Im Endeffekt bedeutet das in der Regel hardwarebeschleunigtes Rendern mit Direct3D, Direct2D und DirectWrite, teilweise mit Software-Rendering, wo es sinnvoll ist.

Sie können auch Ihren eigenen benutzerdefinierten DirectX-Inhalt mithilfe von Interop-APIs einschließen.

Benötigt WinUI C++/CX? Wenn ja, scheint dies ein Problem für Win32 und andere zukünftige Ziele zu sein?

Nein - die WinUI-Plattform ist in C++ geschrieben, aber Ihre Apps müssen es definitiv nicht sein!

Mit WinUI 2 können Sie heute UWP-Apps mit .NET (C#, VB.NET) oder C++ erstellen.

Mit WinUI 3 ist es unser Ziel, dass Sie mit dem kommenden .NET 5 oder C++ Apps erstellen können, die UWP- und/oder Win32-APIs verwenden.

@jesbis Ich denke, Sie missverstehen meine Fragen möglicherweise ein wenig.

1) Ich weiß, dass WinUI in C++ geschrieben ist, aber erfordert jeder WinUI-Code nur Windows VC++ / CX-Erweiterungen? Wenn es CX-Erweiterungen erfordert, sehe ich dies als möglicherweise Portabilitätsprobleme auf der ganzen Linie, wenn WinUI auf andere Plattformen expandieren wollte. Dies könnte es dem UNO-Team beispielsweise erschweren, Code zu übernehmen.

2) Über das Rendering-System. Paar Sachen hier.

2.a) Ist die "Visual Layer" eine Abstraktions-API, die weit genug von DirectX-APIs entfernt ist, um später beispielsweise ein Vulkan-Backend zu unterstützen? (Ich bin mir sicher, dass diese Frage beantwortet wird, wenn die Quelle veröffentlicht wird, aber ich frage mich nur)

2.b) Meine Frage zur Software-Rasterisierung lautete eher: Wird WinUI 3.0 das vollständige Software-Rendering unterstützen (nicht nur Text-Rendering oder was-nicht)? Manchmal hat Screensharing-Software Probleme mit GPU-beschleunigten Apps (zumindest mit D3D9 / WPF) und das Erzwingen von Software-Rendering behebt das Problem in diesen Situationen). Oder wenn die App in einer VM ohne Hardware-GPU ausgeführt wird.

Die WinUI 3.0 Alpha-Anweisungen zum Installieren und Ausprobieren des vsix finden Sie hier:
https://aka.ms/winui/alpha

habe das mit Edge New gemacht, der Download-Link ist nicht aufgetaucht, habe ihn mit Chrome-Download dort wiederholt

habe das mit Edge New gemacht, der Download-Link ist nicht aufgetaucht, habe ihn mit Chrome-Download dort wiederholt

@hannespreishuber der Downloadlink sollte sich auf der letzten Seite der Umfrage befinden. Meinen Sie, dass die Umfrage in Chromium Edge nicht funktioniert hat, aber in Chrome funktioniert hat?

Der Download-Link sollte sich auf der letzten Seite der Umfrage befinden. Meinen Sie, dass die Umfrage in Chromium Edge nicht funktioniert hat, aber in Chrome funktioniert hat?

habe auf beiden Umfragen gemacht - aber die letzte Seite war anders, vielleicht meine Schuld.

habe auf beiden Umfragen gemacht - aber die letzte Seite war anders, vielleicht meine Schuld.

Okay, danke - wir haben die Umfrage auf beiden Edge-Versionen getestet und es schien zu funktionieren. Wenn also jemand Probleme mit dem Download hat, lassen Sie es uns bitte wissen und melden Sie das Problem auch in Edge, wenn der Seiteninhalt anders als Chrome gerendert wird (Einstellungen > Hilfe & Feedback > Feedback senden)

Ich weiß, dass WinUI in C++ geschrieben ist, aber erfordert jeder WinUI-Code nur Windows VC++ / CX-Erweiterungen? Wenn es CX-Erweiterungen erfordert, sehe ich dies als möglicherweise Portabilitätsprobleme an

@zezba9000 Wir haben WinUI 2-Steuerelemente und -Funktionen (der neue Code, der sich derzeit im Repository befindet) mit C++/WinRT implementiert, das dem Standard C++17 entspricht, aber der Rest von WinUI 3 ist eine viel größere und ältere Codebasis, die derzeit noch angewiesen ist auf WRL usw. Wir konzentrieren uns

Ist die "Visual Layer" eine Abstraktions-API, die weit genug von DirectX-APIs entfernt ist, um später beispielsweise ein Vulkan-Backend zu unterstützen? (Ich bin mir sicher, dass diese Frage beantwortet wird, wenn die Quelle veröffentlicht wird, aber ich frage mich nur)

Auch für die visuelle Ebene konzentrieren wir uns derzeit nicht auf die Portabilität. Es gibt einige lose Kopplungen zwischen der visuellen Ebene und den DirectX-APIs (Implementierung nicht mitgezählt), aber meist abstrahiert. Zur Klarstellung zu Open Source: Unser ursprüngliches Ziel für Open-Sourcing-Code und unsere täglichen Entwicklungsprozesse ist das Xaml-Framework, das derzeit keine Open-Sourcing auf der visuellen Ebene umfasst.

Meine Frage zur Software-Rasterisierung lautete eher: Wird WinUI 3.0 das vollständige Software-Rendering unterstützen (nicht nur Text-Rendering oder was nicht)? Manchmal hat Screensharing-Software Probleme mit GPU-beschleunigten Apps (zumindest mit D3D9 / WPF) und das Erzwingen von Software-Rendering behebt das Problem in diesen Situationen). Oder wenn die App in einer VM ohne Hardware-GPU ausgeführt wird.

Ja, das Rendern über Bildschirmfreigabe, in VMs usw. sollte alle funktionieren. Bei den meisten Inhalten sollte kein Unterschied sichtbar sein. Wenn Sie sich den WinUI 2-Code im Repository ansehen, sehen Sie möglicherweise auch die Verwendung einer API, mit der wir zur Laufzeit abfragen, ob bestimmte Effekte unterstützt / "schnell" werden, und in einigen Fällen auf ein einfacheres Rendern bestimmter Effekte zurückgreifen, aber Apps sollten dies nicht tun Sie müssen nichts Besonderes tun, um Software-Rendering zu unterstützen, wenn Sie die Standardsteuerelemente und -funktionen der Plattform verwenden.

Ich stimme dir hier voll und ganz zu. Aber Sie müssen den Unterschied zwischen Funktionen und Fehlern verstehen. Mich beunruhigt, dass Sie nur in Ressourcen/Manpower für Microsoft denken. Haben Sie jedoch daran gedacht, dass App-Entwickler unzählige Stunden damit verschwenden, Fehler in den Steuerelementen zu umgehen? Es ist viel effizienter, diese Dinge an der Quelle zu beheben und hilft auch wirklich bei der Wahrnehmung der Plattform/des Tools.

Stimme 100% zu - Ich möchte mich nicht einmal daran erinnern, wie viele Stunden ich damit verbringe, Fehler von UWP/WinRT zu umgehen.

Jesse,

Mir geht es in erster Linie um die Entwicklung von Unternehmensanwendungen. Ich verwende derzeit WinUI 3.0 Alpha, um einen Machbarkeitsnachweis zu erstellen, um zu demonstrieren, wie Xaml, GPRC, mehrere Fenster und echtes Multithreading dem Unternehmen und dem Geschäftsbenutzer ein produktiveres Anwendungserlebnis bieten können.

Wieso den? Weil wir eine Alternative zu browserbasierten/Small-Screen-Anwendungen brauchen. Ich habe noch viel mehr zu diesem Thema zu sagen, aber ich werde hier KISSEN.

Was ich mir vom WinUI-Team und tatsächlich von Microsoft wünsche, ist, die Entwicklung von Desktop-Apps für Unternehmen zu umarmen und zu unterstützen.

Es gab drei Hauptgründe, warum Web-Apps so schnell in Unternehmen eingeführt wurden: plattformübergreifender Support, Sicherheit und einfache Bereitstellung Um eine brauchbare Alternative zu sein, brauchen Desktop-Apps Antworten auf diese Fragen.

Es scheint, dass sich der Großteil der Softwareentwicklungsbranche auf die Bereitstellung von Anwendungen für den Browser- und/oder Mobil-/Tablet-Formfaktor konzentriert.

Unternehmensanwendungen laufen auf Workstations mit viel CPU, Bildschirmgröße, Arbeitsspeicher, Speicher, Grafik und Bandbreite im Vergleich zu „Mobile First“-Anwendungen. Die Benutzer dieser LOB-Anwendungen können sich stundenlang am Stück engagieren. Wir benötigen eine Anleitung zum App-Design, um diese Faktoren zu berücksichtigen.

Es gibt andere Dimensionen in Unternehmensanwendungen, die nicht viel diskutiert werden – Langlebigkeit und Fähigkeiten. Auch hier gibt es viel zu sagen, aber ich werde es zusammenfassen. Unternehmen investieren Geld in die Entwicklung von Anwendungen und planen, diese Apps für eine „lange“ Zeit zu verwenden. Dies bedeutet, dass die zugrunde liegende Technologie über Jahrzehnte unterstützt werden muss. Ich würde mir wünschen, dass WinUI die nächste langlebige Technologie ist, die Win32/MFC und WinForms ersetzt.

IT-Abteilungen kämpfen ständig damit, SEs mit den richtigen Fähigkeiten zu finden. Webtech hat dies noch schwieriger gemacht. Ich würde mir einen neuen Stack für C#, Xaml und SQL (C#XS) wünschen, der einen Schwerpunkt auf die Erstellung von Desktop-Apps legt.

Es gibt noch einen kleinen Punkt, den ich in Bezug auf das Styling ansprechen möchte. WinUI-Unternehmensanwendungen sollten ein Minimum an Formatierung „out of the box“ erfordern, um funktionsfähig zu sein. Auch, und dies könnte direkt an Fluent gerichtet sein, aber blenden Sie keine Steuerelemente (wie Bildlaufleisten) aus. Geschäftsanwender haben viel Bildschirm-Real-State und kümmern sich nicht darum, wie „schön“ eine Benutzeroberfläche ist, wenn sie nicht wissen, dass auf einer Seite mehr zu finden ist.

Wir brauchen eine robuste (kostenlose) Datagrid-Steuerung. Kann das nicht genug betonen.

Ich habe noch mehr Ideen, die ich bei Interesse teilen kann, aber ich höre hier auf und fasse zusammen:

• Microsoft muss eine umfassende Lösung zur Entwicklung von Desktopanwendungen bereitstellen.
• WinUI/Fluent muss die Anforderungen des Geschäftsbenutzers erfüllen, wie Funktion/Formular, UX für Desktop, Codebeispiele/Projektvorlagen, die mehrere Fenster demonstrieren, echtes Multithreading, Datenvalidierung, „formularähnliche“ Seiten.
• Microsoft muss deutlich machen, dass sie WinUI anbieten, um hochproduktive, langlebige Business-LOB-Anwendungen zu erstellen. Auch, warum .Net 5 + WinUI KEINE weitere DLL-Hölle sein wird.
• Machen Sie deutlich, dass WinUI der Ersatz für Win32/MFC und WinForms ist.
• Setzen Sie C#XS als Skillset für die IT ein.
• (Kostenloses) Datengitter

Ich hoffe, Sie fanden dies hilfreich.

@robloo Ruhe einfach - keine Debatte erforderlich! 🙂 Ich habe mich in meinem frühen Kommentar dazu verpflichtet, diesen Fehler zu beheben, und das gilt immer noch. Ich glaube, ich habe vorhin auch einen Fehler gemacht, indem ich weiter verallgemeinerte. Lassen Sie uns über die Fehler sprechen, die Sie aufgelistet haben. Zwei wurden kurz vor unserem großen Urlaub hier eingereicht (ich kann nicht für @teaP sprechen, aber ich war den größten Teil des Dezembers offline) und wir haben einen Managementwechsel auf unserer technischen Seite durchgemacht (Glückwunsch @ranjeshj!). Es ist keine Entschuldigung und ich entschuldige mich dafür, dass diese beiden Fehler während dieser Änderungen und Abwesenheiten nicht schneller behoben wurden. Die anderen hier aufgeführten wurden alle innerhalb der letzten 10 Tage oder weniger eingereicht.

Es darauf hinzuweisen, dass insbesondere NumberBox ein Schuldiger ist und dass sich diese stapeln, hilft uns, strategisch mit unserer Zeit umzugehen. Vielen Dank, dass Sie uns geholfen haben, dies zu erkennen. Ich habe Anfang nächster Woche Zeit geplant, um unsere ausstehende NumberBox-Fehlerliste mit unserem NumberBox-Entwickler @teaP und unserem (neu benannten) Engineering-Manager @ranjesh zu überprüfen, damit wir sie so schnell wie möglich gemeinsam lösen können.

@SavoySchuler Danke!

@SavoySchuler , es scheint, dass Sie in einer schwierigen Position stecken, zwischen denen Sie sich entscheiden müssen:

a) Beheben Sie Fehler in WinUI 2.x und verzögern Sie die Veröffentlichung von WinUI 3.0
oder
b) Überlassen Sie WinUI 2.x der Community und widmen Sie interne Ressourcen WinUI 3.0, um das früheste Veröffentlichungsdatum zu erreichen

Ich vermute, dass viele bestehende WinUI 2.x-Benutzer möchten, dass Sie die Fehler zuerst beheben, da sie derzeit betroffen sind. und unter der Annahme, dass WinUI 3.0 zusätzliche Fixes über 2.x bietet).

Ich persönlich möchte keine Verzögerung bei der Veröffentlichung von WinUI 3.0 sehen und halte es für vernünftig, dass sich die Community an der Lösung kritischer Probleme in WinUI 2.x beteiligt (schließlich ist es Open Source). Manche Leute haben die Erwartung, dass sie die ganze Arbeit machen sollten, weil es ein Microsoft-Projekt ist. Leider ist das nicht realistisch, und es ist auch nicht so, wie andere Open-Source-Projekte funktionieren.

@jesbis , es ist interessant, in Bezug auf WinUI 3.0 über den Visual Layer zu hören. Wollen Sie damit sagen, dass WinUI 3.0 für die ersten Versionen eine Abhängigkeit von Windows.UI.Composition Klassen haben wird? Gibt es eine Möglichkeit, dem Betriebssystem weitere Funktionen hinzuzufügen, um den Visual Layer vor der Extraktion in WinUI 3.0 zu unterstützen?

Als Referenz, Dinge, die mich interessieren:

• Win32-Modell "AppContainer". Wir sind auf anderen Betriebssystemen vollständig Sandbox-kompatibel, möchten jedoch auf "moderne" APIs zugreifen
• Die visuelle Ebene ( Windows|Microsoft.UI.Composition )
• DXGI-Swapketten in der visuellen Ebene / SwapChainPanel
• Fensterverwaltungs-APIs (AppWindow usw.)

@infoequipt danke für die ausführlichen Hinweise! Auf jeden Fall hilfreich. @marb2000 für Sichtbarkeit

Es ist interessant, in Bezug auf WinUI 3.0 über den Visual Layer zu hören. Wollen Sie damit sagen, dass WinUI 3.0 für die ersten Versionen eine Abhängigkeit von Windows.UI.Composition-Klassen haben wird?

@MarkIngramUK nein, entschuldigen Sie die Verwirrung - mein früherer Punkt

Microsoft.UI.Composition wird Teil von WinUI 3 sein und Microsoft.UI.Xaml wird davon abhängen. Bei der WinUI 3 Alpha ist das bereits der Fall.

Wir arbeiten an Open-Sourcing von Xaml, was bedeutet, dass der Xaml-Framework-Code in diesem Repository leben wird und unser Engineering-Team in Zukunft unsere gesamte tägliche Arbeit an Xaml auf GitHub erledigen wird. Das Microsoft.UI.Composition-Paket, von dem Xaml abhängt, wird jedoch weiterhin intern entwickelt und nur in binärer Form aktualisiert.

Danke für die Klarstellung @jesbis sehr geschätzt. Welche Verteilungsmethoden werden Sie dafür verwenden? Wir sind eine plattformübergreifende App, verwenden also CMake und sind von Windows.UI.Composition abhängig.

Gibt es Auswirkungen auf die Leistung beim Extrahieren der Visual Layer aus dem Betriebssystem? Dh wenn Sie nur auf die visuelle Ebene angewiesen sind, gibt es dann einen Nachteil beim Aktualisieren auf eine neue Bibliothek?

Gibt es einen Plan, Microsoft.UI.Composition schließlich als Open Source zu öffnen?

@MarkIngramUK Ich stimme weitgehend mit dem überein, was Sie sagen und was @SavoySchuler in einer "großen

Ich sollte wahrscheinlich sagen, dass ich all die Arbeit, die Microsoft hier leistet, und ihre Bemühungen, transparenter und kommunikativer zu sein, zu schätzen weiß.

Welche Verteilungsmethoden werden Sie dafür verwenden? Wir sind eine plattformübergreifende App, verwenden also CMake und sind von Windows.UI.Composition abhängig.

@MarkIngramUK würde das Konsumieren von NuGet-Paketen für Sie funktionieren? Dh was wir mit

Gibt es Auswirkungen auf die Leistung beim Extrahieren der Visual Layer aus dem Betriebssystem? Dh wenn Sie nur auf die visuelle Ebene angewiesen sind, gibt es dann einen Nachteil beim Aktualisieren auf eine neue Bibliothek?

Bleiben Sie dran 🙂 Leistungs-Benchmarking und -Arbeit ist auf unserer Roadmap für später in diesem Jahr, daher ist es ein bisschen zu früh, um Zahlen zu haben.

Gibt es einen Plan, Microsoft.UI.Composition schließlich als Open Source zu öffnen?

Es befindet sich in unserem Rückstand, um es möglicherweise in Betracht zu ziehen, aber wir haben keinen Plan dafür.

@MarkIngramUK Wenn ich fragen könnte: Welchen Nutzen erhoffen Sie sich von Open Source?

Komposition und Rendering-Code können etwas abstrus werden, daher bin ich gespannt, ob die Leute tatsächlich daran interessiert sind, einen Beitrag zu leisten oder als Referenz zu verwenden.

Es ist für uns WinUI 2.0-Benutzer schwieriger, Fehler zu akzeptieren, da wir derzeit Produktions-Apps haben. Wir müssen einen Kompromiss zwischen der Behebung einiger Fehler finden, die WinUI 3.0 nicht verzögern und WinUI 3.0 auf Kurs halten. Es gab eine zusätzliche Frustration, dass NumberBox ein brandneues Steuerelement war, das sofort vernachlässigt zu werden schien – mit einem Kommentar, dass Microsoft seit über einem Jahr nicht mehr darauf zurückkommen würde. Unabhängig davon stimme ich definitiv zu, dass WinUI 3.0 die Priorität hat und möchte nicht, dass es in nennenswertem Umfang verzögert wird.
Ich sollte wahrscheinlich sagen, dass ich all die Arbeit, die Microsoft hier leistet, und ihre Bemühungen, transparenter und kommunikativer zu sein, zu schätzen weiß.

@robloo danke! Wir versuchen wirklich transparent zu sein und es ist gut zu wissen, dass das wertvoll ist 🙂

Um noch einmal zu wiederholen, was Savoy erwähnt hat, wir haben Entwickler, die an WinUI 2.x arbeiten (wie hoffentlich auch aus dem PR-Log ersichtlich ist), also investieren wir definitiv immer noch parallel in WinUI 2 und 3 - es ist nur so, dass die meisten unserer Die Ressourcen befinden sich auf WinUI 3. Ich stimme zu, dass insbesondere NumberBox etwas Aufmerksamkeit benötigt und unser Entwicklungsleiter für Xaml-Steuerelemente sich jetzt damit befasst.

@robloo Du bist der Beste! 😄 Nochmals Entschuldigung für die Verwirrung - das einzige, was der erwähnten Verzögerung von ~ 1 Jahr unterliegt, waren die zusätzlichen Eingabevalidierungsmodi von NumberBox, da sie bei unseren für 3.0 geplanten Eingabevalidierungsarbeiten blockiert sind. Ansonsten werden @teaP , @ranjeshj und ich ab nächster Woche auf der NumberBox-Bugliste stehen. 🙂

Ich denke, @jesbis hat alles andere abgedeckt!

@jesbis ,

@MarkIngramUK würde das Konsumieren von NuGet-Paketen für Sie funktionieren? Dh was wir mit

Ich bin ehrlich, ich bin mit NuGet nicht so vertraut, aber wenn man sich diese SO-Antwort ansieht, scheint es nur zu funktionieren, wenn Sie CMake verwenden, um VS-Projektdateien zu generieren, was normalerweise nicht der Fall ist (normalerweise öffnen Sie einfach den Ordner). , das Ninja als Generator verwendet). Es ist eine Schande, dass Sie die Quelle nicht versenden können, da Sie auch könnten . Als Referenz bauen wir alle Bibliotheken aus dem Quellcode (was potenzielle ABI-Probleme vermeidet, insbesondere da wir auch unter Windows mit Clang/LLVM bauen).

Gibt es einen Plan, Microsoft.UI.Composition schließlich als Open Source zu öffnen?

Es befindet sich in unserem Rückstand, um es möglicherweise in Betracht zu ziehen, aber wir haben keinen Plan dafür.

Ich habe ein Interesse daran, daher würde ich mich gerne an der Diskussion beteiligen, wenn / wenn das passiert.

@MarkIngramUK Wenn ich fragen könnte: Welchen Nutzen erhoffen Sie sich von Open Source?

Komposition und Rendering-Code können etwas abstrus werden, daher bin ich gespannt, ob die Leute tatsächlich daran interessiert sind, einen Beitrag zu leisten oder als Referenz zu verwenden.

Erste Überlegungen tragen/erweitern sich (wie ich bereits erwähnt habe, wir haben eine Abhängigkeit von Windows.UI.Composition, aber nicht von Xaml Framework / UWP), denken jedoch laut darüber nach, den Visual Layer auf ein Vulkan- oder Metal-Backend für Cross- Plattform mag aufregend sein, aber ich habe das nur buchstäblich 30 Sekunden in Betracht gezogen. Außerdem würde Open Sourcing die quälende Sorge lindern, ein anderes Framework zu übernehmen, das in einigen Jahren von Microsoft aufgegeben werden wird (unsere aktuellen Apps basieren auf WPF, unsere vorherigen Apps wurden auf MFC erstellt, wir hatten Webkomponenten mit Silverlight, also , Sie können sehen, woher ich hier komme...).

NumberBox

Hallo allerseits! @teaP , @ranjeshj und ich haben heute alle unsere offenen NumberBox-Elemente durchgearbeitet.

• Wir haben schon einige geschlossen.
• @teaP hat eine kombinierte PR für mehrere weitere eingereicht ( Labelfilterung hier ).
• Für den Rest haben wir eine Vorgehensweise beschlossen (mit Ausnahme von #1721) und werden so schnell wie möglich mit Fixes reagieren. #1721 erfordert mehr Arbeit an unserem, um den besten Weg nach vorne zu diagnostizieren. Wir werden weiter daran arbeiten, dieses Problem zu lösen.

Vielen Dank an alle für die Zusammenarbeit mit uns. 🙂 Wir ❤️ WinUI!

Gibt es einen "Kalender" für die WinUI-Community-Aufrufe? Beispiel: in Form eines öffentlichen Kalenders, den wir unserem Live/Google/*-Kalender hinzufügen/in ihn integrieren können, um die Anrufdetails automatisch zu aktualisieren.

Die YouTube-Events sind im Voraus geplant, sodass Sie hier unter "bevorstehende Livestreams" eine Google-Erinnerung hinzufügen können:

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

Wir hatten auch eine .ics-Kalendereinladung, aber das verursachte bei einigen Leuten Probleme und es gab keine Möglichkeit, es zu aktualisieren, also haben wir es vorerst aufgegeben.