Expander ist sehr nützlich und ich verwende die Windows Community Toolkit-Version, seit sie hinzugefügt wurde. Ich würde das Rad jedoch nicht zu sehr neu erfinden, nur den Code aus dem Toolkit zu portieren wäre meiner Meinung nach perfekt für Version 1.0.

Ein weiteres Beispiel: der ColorPicker mit seinem 'MoreButton' könnte dies verwenden.

Vielen Dank für die Einreichung dieses Vorschlags! Ich werde einige Änderungen vornehmen, einschließlich der Unterscheidung zwischen dem, was ich für echte Expander-Szenarien halte, und denen, die eher von Flyout/MenuFlyout verwendet werden.

Ich habe diesen Vorschlag aktualisiert, um weitere Details zum Umfang, einer vorgeschlagenen API und der folgenden offenen Frage zu enthalten.

• Müssen wir ExpandDirection in einem v1-Expander unterstützen? Gibt es übliche App-Szenarien, in denen Expander in andere Richtungen als nach unten erweitert werden muss?

Würde mich über Feedback freuen, wie diese zu Ihren Anwendungsfällen für Expander passen oder nicht!

Ich habe diesen Vorschlag aktualisiert, um weitere Details zum Umfang, einer vorgeschlagenen API und der folgenden offenen Frage zu enthalten.

• Müssen wir ExpandDirection in einem v1-Expander unterstützen? Gibt es übliche App-Szenarien, in denen Expander in andere Richtungen als nach unten erweitert werden muss?

Würde mich über Feedback freuen, wie diese zu Ihren Anwendungsfällen für Expander passen oder nicht!

Es scheint eine Grundfunktion der Steuerung zu sein

Es scheint eine Grundfunktion der Steuerung zu sein

@mdtauk ist ExpandDirection anders als nach unten ein gängiges App-Szenario? Die Beispiele für Expander-Verhalten, die ich sehe, werden viel häufiger nach unten erweitert - ich möchte definitiv, dass Expander ExpandDirection hat, aber ist dies in einer v1 notwendig?

Ja, wir brauchen eine Richtungserweiterung. Es gibt viele Fälle für die Verwendung und es wäre eine unnötige grundlegende Änderung an der Steuerelementvorlage nach einer Version von v1, sie hinzuzufügen. Die Expander-API hat sich seit WPF nicht viel geändert und der Vorschlag hier enthält bereits alle erforderlichen Eigenschaften/Ereignisse/Methoden. Ich würde einfach alles in einem Schuss implementieren und wir können mit dieser Steuerung fertig sein. In Bezug auf das Design hat das UWP Community Toolkit die notwendigen Änderungen vorgenommen, um eine bessere Arbeit mit Touch zu ermöglichen. Ich denke, wir haben alle Teile und es besteht keine Notwendigkeit, etwas neu zu erfinden.

Bearbeiten: Das Community-Toolkit hat auch eine ContentOverlay Eigenschaft. Das könnte in einer V1 etwas übersprungen werden.

Ja, wir brauchen eine Richtungserweiterung. Es gibt viele Fälle für die Verwendung und es wäre eine unnötige grundlegende Änderung an der Steuerelementvorlage nach einer Version von v1, sie hinzuzufügen.

@robloo Könnten Sie

Es scheint eine Grundfunktion der Steuerung zu sein

@mdtauk ist ExpandDirection anders als nach unten ein gängiges App-Szenario? Die Beispiele für Expander-Verhalten, die ich sehe, werden viel häufiger nach unten erweitert - ich möchte definitiv, dass Expander ExpandDirection hat, aber ist dies in einer v1 notwendig?

Chat-Apps, die neue Listeninhalte von unten nach oben laden, sind vielleicht eine davon.

Über das sehr grundlegende Wesentliche hinaus:

• Istzusammengeklappt
• Wird erweitert
• IstErweitert
• Wird zusammengebrochen

Sowie IsEnabled

Der nächste Kernpunkt ist, wohin erweitert werden soll.

• Erweitern
• ErweiternNach unten
• ExpandLeft
• ErweiternRechts

Chat-Apps, die neue Listeninhalte von unten nach oben laden, sind vielleicht eine davon.

@mdtauk Ich verstehe nicht ganz, was Sie mit diesem Beispiel für Chat-Apps meinen - könnten Sie das
Was die Eigenschaften betrifft - die vorgeschlagene API basiert auf dem WPF-Expander, daher denke ich, dass IsExpanded und ExpandDirection sie abdecken würden. Wofür würde IsEnabled verwendet werden – gibt es ein Anwendungsszenario, in dem Sie einen Expander deaktivieren möchten?

Ein weiteres Beispiel, das ich in der Vergangenheit verwendet habe, sind sekundäre, bearbeitbare Eigenschaften, die normalerweise ausgeblendet werden sollten. Diese werden am unteren Rand eines Editors nur angezeigt, wenn Sie auf eine Schaltfläche "Optionen" klicken und der Expander nach oben geöffnet wird. Es liegt wirklich nur an dem Design, das Sie anstreben. Es gibt viele nützliche Fälle für die Erweiterung verschiedener Richtungen, und es scheint unnötig, dies künstlich einzuschränken, insbesondere wenn die bisherigen Konventionen so stark sind. Ich glaube nicht, dass all dies in einer V1 der Steuerung zu schwierig wäre, zumal alle Probleme bereits im Community-Toolkit und WPF gelöst wurden.

@robloo Könnten Sie

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander/Expander.xaml

Ich nehme an, wenn Sie bei der Gestaltung der Vorlage und der visuellen Zustände sehr vorsichtig sind, ist es möglich, sie bruchsicher zu machen. Dazu müssen Sie jedoch die Funktionalität sowieso wirklich entwerfen, damit Sie sie genauso gut implementieren können. Dies ist alles ziemlich einfach und es gibt keinen Grund für einen V2-Plan von Anfang an für diese Steuerung.

Ich weiß, dass es verlockend ist, das Rad neu zu erfinden. Aber bitte bewahren Sie es auf, damit Leute, die Apps von WPF auf WinUI portieren, dies ohne absolut notwendige Codeänderungen tun können. WinUI muss einige der Fehler mit UWP korrigieren.

Wofür würde IsEnabled verwendet werden – gibt es ein Anwendungsszenario, in dem Sie einen Expander deaktivieren möchten?

@mdtauk Stimmt, dies muss auch IsEnabled unterstützen. Das Deaktivieren von Steuerelementen ist eine ziemlich strenge Konvention, wenn die Möglichkeit einer Eingabe oder Zustandsänderung besteht. Bitte lass uns das nicht verteidigen.

In den obigen Screenshots hat Windows Security einen Expander für den Antivirus-Bereich sowie das linke Navigationsmenü. Dies zeigt eine sehr realistische Verwendung des Expanders in mehr als einer Richtung, die viele Apps unterstützen müssten. Meine Stimme ist für die Unterstützung mehrerer Richtungen in V1.

@robloo

Ein weiteres Beispiel, das ich in der Vergangenheit verwendet habe, sind sekundäre, bearbeitbare Eigenschaften, die normalerweise ausgeblendet werden sollten. Diese werden am unteren Rand eines Editors nur angezeigt, wenn Sie auf eine Schaltfläche "Optionen" klicken und der Expander nach oben geöffnet wird.

Könnten Sie mit einem Screenshot oder einer bestimmten App erläutern, wo dies geschieht, damit ich das Szenario besser verstehen kann? Ich kann mir Editoren vorstellen, bei denen eine Optionsschaltfläche ein Popup mit mehr Schaltflächen öffnet, aber in denen, die ich kenne, wird der andere Inhalt nicht nach oben verschoben - eher ein Popup-/Flyout-Verhalten als eine Erweiterung.

Ich nehme an, wenn Sie bei der Gestaltung der Vorlage und der visuellen Zustände sehr vorsichtig sind, ist es möglich, sie bruchsicher zu machen. Dazu müssen Sie jedoch die Funktionalität sowieso wirklich entwerfen, damit Sie sie genauso gut implementieren können. Dies ist alles ziemlich einfach und es gibt keinen Grund für einen V2-Plan von Anfang an für diese Steuerung.
Ich weiß, dass es verlockend ist, das Rad neu zu erfinden. Aber bitte bewahren Sie es auf, damit Leute, die Apps von WPF auf WinUI portieren, dies ohne absolut notwendige Codeänderungen tun können.

Ich stimme Ihnen zu, dass die Portierung von Apps von WPF auf WinUI so reibungslos wie möglich ablaufen sollte! In Gesprächen mit dem WinUI-Team wurde darauf hingewiesen, dass eine V1 mit dem Umfang nach unten die Entwicklungszeit verkürzen und Expander früher für Entwickler verfügbar machen würde (da die Szenarien für Expander bisher alle nach unten gerichtet waren), und eine geplante V2 könnte ExpandDirection hinzufügen bald darauf. (Ich werde die offene Frage bearbeiten, um diesen zusätzlichen Kontext zu haben.) Deshalb hoffe ich zu verstehen, ob es bestimmte Anwendungsfälle gibt, die Entwickler für nicht abwärts gerichtete Expander haben! 😄

Das Deaktivieren von Steuerelementen ist eine ziemlich strenge Konvention, wenn die Möglichkeit einer Eingabe oder Zustandsänderung besteht. Bitte lass uns das nicht verteidigen.

Danke für die Erklärung, es macht absolut Sinn, dass das Deaktivieren der Zustandsänderung eine gewünschte Funktion für diese Art von Steuerung ist!

In den obigen Screenshots hat Windows Security einen Expander für den Antivirus-Bereich sowie das linke Navigationsmenü. Dies zeigt eine sehr realistische Verwendung des Expanders in mehr als einer Richtung, die viele Apps unterstützen müssten. Meine Stimme ist für die Unterstützung mehrerer Richtungen in V1.

@JustABearOz Ich denke, das linke Navigationsmenü ist eigentlich eine NavigationView . 😃 Ich stimme zu, dass der Antivirus-Bereich ein Expander-Szenario ist, in diesem Fall nach unten erweitert. Würde gerne wissen, welche spezifischen Anwendungsfälle Sie für Nicht-Downward-Expander haben!

@kat-y Ok, das macht links / rechts überflüssig, aber 2 Beispiele in Fenstern, die sich zu erweitern scheinen und die leicht für Apps gelten könnten:
1: Der Screenshot oben mit dem Schnellaktionsmenü. Ziemlich sicher, dass sich das ausdehnt.
2: In Windows hat der Popup-Kalender in der Taskleiste einen Abschnitt, der sich nach oben erweitert, um Agenda/Termine anzuzeigen.

Ist es möglich, Up/Down für V1 statt nur Down zu unterstützen?

1: Der Screenshot oben mit dem Schnellaktionsmenü. Ziemlich sicher, dass sich das ausdehnt.

@JustABearOz vielen Dank für diese Beispiele! Zu 1: Ich denke, dies ist ein interessanter Randfall - die Erweiterung erfolgt von der "Kopfzeile" (der Erweiterungsschaltfläche) "nach unten", aber das Steuerelement selbst befindet sich am unteren Rand der Oberfläche, sodass die Kopfzeile (und der erweiterte Inhalt) muss nach oben 'verschieben' (sonst würde es über den Bildschirm laufen!). Scheint eine gute Möglichkeit zu sein, ein expandierendes Element unten in einer App zu haben, stimmen Sie zu?

2: In Windows hat der Popup-Kalender in der Taskleiste einen Abschnitt, der sich nach oben erweitert, um Agenda/Termine anzuzeigen.
Ist es möglich, Up/Down für V1 statt nur Down zu unterstützen?

Ich stimme Ihnen zu, dies ist ein Szenario, bei dem sich der Header am unteren Rand des Bereichs befindet und nach oben erweitert wird! In diesem Fall ist der Expander des Kalenders (und das Popup als Ganzes) an die Taskleiste gebunden. Sind Ihnen Szenarien in Apps begegnet, in denen Expander eine ähnliche gebundene Positionierung haben, die eine Erweiterung nach oben erfordert?

@kat-y Ich meine nichts für ungut, aber ich habe das Gefühl, dass wir Dinge neu erklären müssen, die vor 15 Jahren bekannt waren. Ich verstehe nicht, warum Sie uns bitten, Beispiele für die Expansionsrichtung in der Praxis zu nennen. Ich gehe davon aus, dass Sie dies intern zur Spezifikationsüberprüfung bringen und vor dem Management verteidigen müssen. Aber die Erklärung kann einfach sein: (1) Sie müssen die Benutzer in die Lage versetzen, ihre Designziele zu erreichen für ihren Anwendungsfall (ein kritisches Konzept für Look-less-Steuerelemente) (2) Am wichtigsten ist, dass dies überhaupt keine neue Idee ist. Sie kopieren eine vorhandene API in diesem Bereich und müssen die App-Kompatibilität beibehalten. Auch wenn dies eine neue Idee wäre, würde ich besser verstehen, warum wir sie verteidigen müssen – es ist gut, sicherzustellen, dass die Funktionen nützlich sind, bevor Sie die Zeit in sie investieren.

Abgesehen vom Header gibt es buchstäblich zwei Eigenschaften in diesem Steuerelement und wenn es C# wäre, könnte ich es in wenigen Stunden mit der WCT-Basis schreiben. Wir werden mehr Arbeitsstunden damit verbringen, nur darüber zu reden, als es so zu implementieren, wie es heute in WPF/WCT existiert.

Danke @robloo für den Beitrag. Ich

Zu Ihrer Information @ranjeshj @ryandemopoulos @stmoy

@robloo Danke, dass du ehrlich zu mir bist! Ich verstehe, dass App-Entwickler in der Lage sein sollten, herauszufinden, was am besten zu ihrem Anwendungsfall passt, und dass App-Kompatibilität wichtig ist. Ich hoffe, dass die Diskussion mit @michael-hawker und dem WinUI-Team uns helfen wird, beim Scoping von Expander produktiv voranzukommen!

Zuvor hatte ich keine konkreten Beispiele dafür, dass Expander in nicht abwärts gerichteter Richtung verwendet wurden. Ich werde alle Beispiele aus der WinUI-Community (einschließlich des Kalender-Flyouts, auf das @justABearOz hingewiesen hat) und alle, die ich von Michael lerne, zu Diskussionen mit dem WinUI-Team als Beweis für die Beibehaltung von ExpandDirection in v1 von Expander mitbringen.

Ich habe den Vorschlag mit einer Liste der mir bekannten Expander-Steuerelemente aktualisiert. Lassen Sie es mich wissen, wenn ich etwas übersehen habe.

• WPF
• Windows Community Toolkit
• Telerik-Benutzeroberfläche
• Xamarin.Forms
• Syncfusion.XForms.Expander

Ich habe mir sowohl den WPF-Quellcode als auch den WCT-Quellcode angesehen. Ich bin zuversichtlich, dass dies auch in WinUI in wenigen Stunden implementiert werden kann. Das Steuerelement sollte der WCT-Implementierung von dem folgen, was ich gesehen habe, obwohl die ContentOverlay Eigenschaft wahrscheinlich umbenannt oder aus V1 weggelassen werden sollte.

WPF:
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/Themes/XAML/Expander.xaml
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/Expander.cs

WCT:
https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander

Da beide Quellen von Microsoft und lizenziertem MIT stammen, sollten sie die Basis sein, beginnen Sie nicht bei Null. Xamarin Forms entspricht nicht den Konzepten von WPF->WinUI und sollte daher wahrscheinlich ignoriert werden (es gibt auch keine zusätzlichen Funktionen). Die Lösungen von Drittanbietern haben auch keine bahnbrechenden neuen Ideen, wie ich es gesehen habe. Diese Kontrolle hat sich weitgehend bewährt.

@robloo Danke, dass du ehrlich zu mir bist! Ich verstehe, dass App-Entwickler in der Lage sein sollten, herauszufinden, was am besten zu ihrem Anwendungsfall passt, und dass App-Kompatibilität wichtig ist. Ich hoffe, dass die Diskussion mit @michael-hawker und dem WinUI-Team uns helfen wird, beim Scoping von Expander produktiv voranzukommen!

Zuvor hatte ich keine konkreten Beispiele dafür, dass Expander in nicht abwärts gerichteter Richtung verwendet wurden. Ich werde alle Beispiele aus der WinUI-Community (einschließlich des Kalender-Flyouts, auf das @JustABearOz hingewiesen hat) und alle, die ich von Michael lerne, zu Diskussionen mit dem WinUI-Team als Beweis dafür bringen, dass ExpandDirection in v1 von Expander beibehalten wird.

Nun, mein Punkt ist, dass es wirklich nicht zu viele Diskussionen darüber geben sollte. Ich entscheide mich, meine Frustrationen hier auszudrücken, da diese Steuerung ein perfektes Beispiel ist. Die neue Pager-Steuerung oder Breadcrumb-Steuerung erfordert mehr Aufsicht und es ist wichtig, den Prozess zu befolgen. Allerdings zeigt sich hier und da der Overhead eines großen Prozesses, Sie werden viel mehr Arbeitsstunden damit verbringen, nicht wertschöpfenden Papierkram und Diskussionen zu erledigen, als nur die Kontrolle von WCT zu implementieren. Ich habe auch noch nicht gesehen, dass das WinUI-Team andere, frühere Arbeiten verwendet, was etwas besorgniserregend ist. Es ist nicht erforderlich, die XAML-Steuerelementvorlage neu zu entwickeln.

Willkommen beim WinUI-Projekt @kat-y - Xaml hat eine lange Geschichte, kann aber für Neulinge etwas skurril sein. Während WinUI eine Gelegenheit bietet, die Funktionsweise der Dinge zu überdenken, ist Expander in diesem Fall ein relativ einfaches Steuerelement und daher sollte ein einfacher Wechsel von WPF zu WinUI ausreichen.

@robloo Ich stimme Ihrer Behauptung nicht zu, dass die XAML-Steuerelementvorlage nicht neu entwickelt werden muss. WPF AFAIR hat eine Reihe von chromähnlichen Elementen, die in WinUI/Fluent fehl am Platz wären.

Handhabung der Chevron- und Touch-Zielgrößen sowie Verwendung der Schriftgrößen. Der Chevron sollte leicht zu entfernen oder hinzuzufügen sein.

In diesem Beispiel steht ein Chevron im Einklang mit dem Text.

Dieses Beispiel hat überhaupt kein Chevron

Dieses Beispiel hat eine vorangehende Seite, die einem Chevron zugewandt ist

Was die Implementierung angeht, sollte es beim Öffnen und Schließen einen animierten Übergang geben, es sei denn, der Benutzer hat Animationen deaktiviert, dann wechselt er nur den Zustand.

Was die Implementierung angeht, sollte es beim Öffnen und Schließen einen animierten Übergang geben, es sei denn, der Benutzer hat Animationen deaktiviert, dann wechselt er nur den Zustand.

Ich wollte gerade nach Animationen fragen. Sollte es eine Möglichkeit geben, diese für die Steuerung zu deaktivieren, zB in Szenarien, in denen das Animieren von Layouts zu teuer wäre? Nicht alle Benutzer/Entwickler möchten Animationen für solche Dinge, da sie sich vielleicht ein wenig zu unansprechbar oder einfach nicht gewollt anfühlen (zB TreeView). Es ist möglicherweise besser, das Steuerelement nicht erneut erstellen zu müssen, um diesen Punkt anzupassen. Eine andere Sache, die angepasst werden könnte, ist die Animationsdauer, in einigen Fällen sind kurze Animationen besser als längere.

Danke für all die tollen Diskussionen. einige Gedanken

• Wir müssen die Vorlage aktualisieren, wie @mdtauk erwähnt, um das neue Design sowie Möglichkeiten zur Reduzierung der Elemente/Verbesserung der Leistung nach Möglichkeit zu berücksichtigen.
• IsEnabled wird von Control geerbt, daher würde ich erwarten, dass das funktioniert.

Was die Implementierung angeht, sollte es beim Öffnen und Schließen einen animierten Übergang geben, es sei denn, der Benutzer hat Animationen deaktiviert, dann wechselt er nur den Zustand.

Ich wollte gerade nach Animationen fragen. Sollte es eine Möglichkeit geben, diese für die Steuerung zu deaktivieren, zB in Szenarien, in denen das Animieren von Layouts zu teuer wäre? Nicht alle Benutzer/Entwickler möchten Animationen für solche Dinge, da sie sich vielleicht ein wenig zu unansprechbar oder einfach nicht gewollt anfühlen (zB TreeView). Es ist möglicherweise besser, das Steuerelement nicht erneut erstellen zu müssen, um diesen Punkt anzupassen. Eine andere Sache, die angepasst werden könnte, ist die Animationsdauer, in einigen Fällen sind kurze Animationen besser als längere.

Ich glaube, einige Steuerelemente haben eine Transition-Eigenschaft, die zugewiesen werden könnte. Wenn also ein nicht animiertes Storyboard als Ressource enthalten war, könnte es angewendet werden und dies erledigt dies ohne erneute Vorlage.

Sie müssten den Übergang überschreiben, wenn die Systemeinstellung Animationen deaktiviert.

UIElement.Übergänge?
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions?view=winrt-19041

Auch bei der IsEnabled-Eigenschaft muss ein Disabled-Zustand vorliegen. Sollte Deaktiviert Erweitert und Deaktiviert Minimiert angezeigt werden oder wird Deaktiviert immer minimiert?

Interessanter Punkt zu Animationen. Wir schalten alle Animationen mit der Systemeinstellung aus, aber ich glaube nicht, dass wir Drehregler zum Ausschalten von Animationen freigeben, außer indem wir derzeit die Vorlage neu erstellen.

Interessanter Punkt zu Animationen. Wir schalten alle Animationen mit der Systemeinstellung aus, aber ich glaube nicht, dass wir Drehregler zum Ausschalten von Animationen freigeben, außer indem wir derzeit die Vorlage neu erstellen.

Ich glaube, Sie könnten einen Stil hinzufügen, der die Transition-Sammlung mit null überschreibt, falls Sie Animationen deaktivieren möchten, vorausgesetzt, es gibt eine zu überschreibende Transition-Sammlung.

Einschließlich eines ExpandTransition und CollapseTransition , die die von der Eigenschaft des Steuerelements festgelegte Richtung verwenden können - wodurch der Entwickler den Übergang für jeden festlegen kann.

Ich mag die Idee, aber ich glaube nicht, dass es heute eine Möglichkeit gibt, benutzerdefinierte Themenübergänge zu erstellen, die die Anpassungsfähigkeit einschränken würden. Dies würde es jedoch ermöglichen, es leicht zu deaktivieren, indem Sie es entfernen.

Auch bei der IsEnabled-Eigenschaft muss ein Disabled-Zustand vorliegen. Sollte Deaktiviert Erweitert und Deaktiviert Minimiert angezeigt werden oder wird Deaktiviert immer minimiert?

Warum nicht das TreeView-Steuerelement spiegeln, wo Sie die Eigenschaften IsExpanded und IsEnabled verwenden können, um eine beliebige Kombination der beiden zu erstellen? Wenn die Option "Erweitert" deaktiviert ist, funktioniert dies in einigen Fällen am besten. Wenn Sie deaktivierte Collapse benötigen, ist dies auch auf diese Weise möglich.

@robloo Ich stimme Ihrer Behauptung nicht zu, dass die XAML-Steuerelementvorlage nicht neu entwickelt werden muss. WPF AFAIR hat eine Reihe von chromähnlichen Elementen, die in WinUI/Fluent fehl am Platz wären.

@mdtauk Nun, meine Empfehlung war, dass wir hier "der WCT-Implementierung folgen sollten": https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander. Die Designänderungen zur Anpassung an die Berührung und eine modernere Benutzeroberfläche wurden bereits vorgenommen. Natürlich kann niemand so gute Designs machen wie Sie, also bin ich mir sicher, dass es Raum für Verbesserungen gibt. Das Ändern des "Designs" würde keine Neugestaltung der Vorlage erfordern, um alle Expansionsrichtungen zu unterstützen. WCT sollte die Basis sein und wenn wir dann ein neues Styling zum Auftragen haben, sehr gut, es kann schnell gemacht werden, aber nicht von Grund auf.

@robloo Ich stimme Ihrer Behauptung nicht zu, dass die XAML-Steuerelementvorlage nicht neu entwickelt werden muss. WPF AFAIR hat eine Reihe von chromähnlichen Elementen, die in WinUI/Fluent fehl am Platz wären.

@mdtauk Nun, meine Empfehlung war, dass wir hier "der WCT-Implementierung folgen sollten" ...
Ich nahm an, Sie meinten keine Änderungen gegenüber dem XAML der WPF-Version

Aber ich denke immer noch, dass das WinUI-Designteam es und seine Varianten akzeptieren muss – und sei es nur, um die Spezifikation zu bestätigen, die in die figma-Toolkits aufgenommen werden soll

@kat-y Wenn Sie neu im Projekt sind, entschuldige ich mich, wenn ich hart klang. Ich stehe zu meinen obigen Punkten, wie die Projektgeschwindigkeit in einigen Bereichen verbessert werden kann, was sicherlich erforderlich ist. Auch, wie wir das nutzen sollten, was in der Vergangenheit bereits getan und in den letzten 15 Jahren stark kampferprobt wurde. Natürlich richtet sich nichts davon persönlich an Sie oder an irgendjemanden. Es ist ein allgemeines "aufgeblähtes" Problem, das ich seit Jahren bei Microsoft sehe, bei dem die Teams schlanker und neu ausbalanciert werden müssen, um mehr Codierung/weniger Projektmanagement zu betreiben. So gut Pläne auch sind, nichts geht über Versuch und Irrtum, so dass die Geschwindigkeit der Iteration am Ende gewinnt.

@ranjeshj @michael-hawker Warum nicht das nutzen, was bereits im Community-Toolkit enthalten ist? Dies ist nicht das erste Mal, dass das WinUI-Team einen neuen Ansatz verfolgt. Das dupliziert unnötig Arbeit und führt im schlimmsten Fall zu Fragmentierung. Die WCT-Version basierte bereits auf den WPF-Ideen und brachte notwendige 'moderne' Änderungen mit sich.

@ranjeshj @michael-hawker Warum nicht das nutzen, was bereits im Community-Toolkit enthalten ist? Dies ist nicht das erste Mal, dass das WinUI-Team einen neuen Ansatz verfolgt. Das dupliziert unnötig Arbeit und führt im schlimmsten Fall zu Fragmentierung. Die WCT-Version basierte bereits auf den WPF-Ideen und brachte notwendige 'moderne' Änderungen mit sich.

Das Community Toolkit ist meiner Meinung nach in C# und WinUI erfordert C/C++-Code.

Auch das WinUI-Designteam hatte bei der Toolkit-Version kein AFAIK-Mitspracherecht, und so können die Anforderungen der Windows- und App-Designteams spezifische Anforderungen haben, wenn sie die Kontrolle über ihre benutzerdefinierten Lösungen übernehmen möchten.

Das Community Toolkit ist meiner Meinung nach in C# und WinUI erfordert C/C++-Code.

Das Übersetzen von Code in/aus C# und C++/WinRT ist relativ trivial. Speziell für den Expander, wo ich mir bereits den Code https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander angeschaut habe

Auch das WinUI-Designteam hatte bei der Toolkit-Version kein AFAIK-Mitspracherecht, und so können die Anforderungen der Windows- und App-Designteams spezifische Anforderungen haben, wenn sie die Kontrolle über ihre benutzerdefinierten Lösungen übernehmen möchten.

Für bestimmte Punkte ja. Für die allgemeine Steuerungsfunktionalität muss ich jedoch widersprechen. Das WCT würde uns bereits zu 95 % fertig und in der Funktionalität zu 100 % vollständig machen. Alle darüber hinaus vorgenommenen Designänderungen wären trivial.

@robloo Könnten Sie

@ranjeshj Wir sind möglicherweise nicht auf derselben Seite. Ich habe nicht behauptet, dass sich die vorgeschlagene API wesentlich von WCT oder WPF unterscheidet.

Es wurde erwähnt, dass ExpandDirection in der ersten Version dieses Steuerelements möglicherweise nicht unterstützt wird. Das scheint ein Problem für einen Expander zu sein, der eine lange Geschichte mit dieser Funktionalität hat. Dann schien es, als müssten wir rechtfertigen, warum diese Funktion überhaupt benötigt wird.

Ich schlug vor, das WCT als Basis zu verwenden, um dies mit Expansionsrichtung schnell umzusetzen. Das Rad muss nicht neu erfunden werden, da beim Kopieren und Einfügen der XAML-Vorlage nur eine Portierung von C# -> C++ erforderlich ist (und Code-Behind dafür sehr klein ist). Dies würde alle Funktionen implementieren, die wir benötigen, und Bedenken vermeiden, dass nicht genügend Zeit zum Hinzufügen von ExpandDirection vorhanden ist. Dieser Ansatz würde uns eine voll funktionsfähige Kontrolle geben. Dann können alle Design-/Styling-Änderungen basierend auf @mdtauk oder den Vorschlägen anderer Personen durchgeführt werden. Ich verstehe nicht (1) Warum ExpandDirection möglicherweise auf dem Hackblock für V1 ist (2) Warum, wenn die Zeit begrenzt ist, verwenden wir keinen vorhandenen Code.

Ja, meine Frustrationen über die Entwicklung von WinUI 3 im Allgemeinen fließen hier an einigen Stellen ein und ich entschuldige mich dafür.

@robloo Es geht nicht darum, dass etwas auf dem

Bei der Priorisierung der Funktionen, die in eine V1 und dann in eine V2 aufgenommen werden müssen, werden nur die Kern- und wesentlichen Eigenschaften und Verhaltensweisen vorhanden sein und keine Legacy-Elemente, die nicht häufig verwendet werden.

Microsoft scheint zu bestimmen, welche Funktionen basierend auf den Bedürfnissen und Wünschen der Kunden hinzugefügt werden sollen – und nicht nur, um die Gleichheit mit älteren Frameworks zu erreichen.

Es ist also nicht _rechtfertigend_, sondern nur der Versuch zu verstehen, was Entwickler mit diesen Kontrollmustern in ihrer Benutzeroberfläche tatsächlich tun.
Allein die Tatsache, dass die Windows-Shell über mehrere Versionen eines Expander-Steuerelementmusters verfügt, wäre ein klarer Grund, es einzubinden. Und die Tatsache, dass jede Implementierung anders aussieht, wenn nicht anders verhält, ist Grund genug für das Designteam, das Kontrolldesign zu konsolidieren, um die Anforderungen der internen Teams zu erfüllen.

@mdtauk Wie immer machst du gute Punkte. Ich muss dieser Philosophie jedoch in einem wichtigen Punkt widersprechen, wenn dies wirklich der Ansatz von Microsoft ist. Damit WinUI erfolgreich ist, muss es für bestehende App-Entwickler sinnvoll sein. Ich versuche, ein weiteres UWP-Szenario zu vermeiden, da wir alle wissen, dass UWP nie erfolgreich war. Die Entwickler, die Microsoft überzeugen muss, um zu WinUI zu kommen, sind wie zuvor UWP WPF-Entwickler. Einer der Gründe, warum WPF-Apps nie den Sprung zu UWP geschafft haben, liegt darin, dass UWP, insbesondere bei seiner ersten Veröffentlichung, in mehreren wichtigen Funktionsbereichen ein sehr schlechtes Äquivalent war. Als ich sah, dass abgerundete Ecken auf der Roadmap fehlten, begann ich mich an den UWP-Albtraum zu erinnern (abgerundete Ecken, die für WPF grundlegend sind, wurden für die längste Zeit aus der UWP herausgelassen). Die Priorität Nummer 1 sollte für eine reibungslose Portierungserfahrung von SOWOHL WPF als auch von UWP sein, und ehrlich gesagt sollte WPF wahrscheinlich eine höhere Priorität haben, da es dort weit mehr Apps gibt und Microsoft sich eindeutig auf Desktop-Fälle mit WinUI zuerst konzentriert. Wir müssen also auch hier sehr vorsichtig sein und es vermeiden, das Rad neu zu erfinden.

Und die Tatsache, dass jede Implementierung anders aussieht, wenn nicht anders verhält, ist Grund genug für das Designteam, das Kontrolldesign zu konsolidieren, um die Anforderungen der internen Teams zu erfüllen.

Ich habe immer verstanden, dass das Design möglicherweise geändert werden muss. Bei Verwendung von Lookless-Control-Konzepten ist dies jedoch ein anderes Problem als ExpandDirection. Wenn wir das Design mehr modernisieren oder in einigen Fällen nützlicher machen müssen, großartig - es sollte relativ trivial sein. Am Ende des Tages kann es auch für diejenigen, die eine feine Kontrolle benötigen, vollständig neu erstellt werden.

Interessanter Punkt zu Animationen. Wir schalten alle Animationen mit der Systemeinstellung aus, aber ich glaube nicht, dass wir Drehregler zum Ausschalten von Animationen freigeben, außer indem wir derzeit die Vorlage neu erstellen.

Um fair zu sein, verwenden fast keine Steuerelemente Animationen. TreeView und NavigationView verwenden im Wesentlichen einen Expander, aber beide verwenden keine Animationen zum Erweitern/Reduzieren. Die meisten Steuerelemente, die Animationen verwenden, basieren normalerweise auf ihnen, zB ProgressBar oder ProgressRing. Expander verlässt sich jedoch nicht darauf, es wäre eher ein "nice to have". Ein weiteres Beispiel ist, dass einige Leute das WCT Expander-Steuerelement nicht verwendet haben, weil ihnen die Animation nicht gefiel. Wenn wir so viele Leute wie möglich einbeziehen möchten, würde eine einfache Möglichkeit zum Deaktivieren unerwünschter Animationen dies erleichtern.

Ich glaube, Sie könnten einen Stil hinzufügen, der die Transition-Sammlung mit null überschreibt, falls Sie Animationen deaktivieren möchten, vorausgesetzt, es gibt eine zu überschreibende Transition-Sammlung.

Aber wäre dies eine übliche Möglichkeit, dies zu deaktivieren / zu aktivieren? Wenn wir mehrere Stile bereitstellen, unterscheiden sie sich meistens drastischer als nur eine Animation, zB AccentColorButtonStyle oder RevealButtonStyle.

Einschließlich eines ExpandTransition und CollapseTransition, die die von der Eigenschaft des Steuerelements festgelegte Richtung verwenden können – was es dem Entwickler ermöglichen könnte, den Übergang für jeden festzulegen.

Diese Idee gefällt mir richtig gut!

Ich mag die Idee, aber ich glaube nicht, dass es heute eine Möglichkeit gibt, benutzerdefinierte Themenübergänge zu erstellen, die die Anpassungsfähigkeit einschränken würden. Dies würde es jedoch ermöglichen, es leicht zu deaktivieren, indem Sie es entfernen.

Darüber mache ich mir auch Sorgen. mit der ExpandTransition- und CollapseTransition-API ohne benutzerdefinierte Designübergänge ist dies fast nur ein "ExpendTransitionEnabled" und "CollapseTransitionEnabled".

@robloo Wenn Sie über Frustrationen bezüglich der Entwicklung von WinUI 3 sprechen möchten, freue ich mich, wenn Sie mir schreiben (mein Twitter und meine Arbeits-E-Mail sind auf meinem GitHub-Profil). Ich bin mir Ihrer aktuellen Frustrationen nicht ganz bewusst, aber ich bin im Allgemeinen ein guter Anfang für Themen im Zusammenhang mit Kunden- oder Community-Engagement/-Entwicklung und habe im letzten Jahr eine beträchtliche Anzahl unserer Fokusgruppen geleitet das die Überlegungen, die Sie zu Werkzeugen, Feature-Parität usw. aufgeführt haben, abgedeckt hat.

Ich möchte anmerken, dass unsere Roadmap extrem eng ist, daher kann ich nicht versprechen, dass ich die gewünschten Änderungen vornehmen kann, aber es ist immer hilfreich für mich zu wissen, was getan werden könnte, um Sie besser zu unterstützen als Kunde und/oder Mitwirkender von WinUI, so dass das Worst-Case-Ergebnis darin besteht, dass zumindest Ihre Bedürfnisse von unserem Team in Zukunft gut berücksichtigt werden. Im besten Fall hängt das davon ab, wonach Sie suchen. Lass uns schreiben? 😄

@mdtauk Danke für deine Unterstützung bei der Klärung - du bist immer gut

Ich hoffe das hat geholfen? Es ist mein Ziel, diesen Thread wieder an @kat-y und die anstehenden Expander-Themen zu übergeben, aber bitte wenden Sie sich direkt an, wenn ich mehr beantworten kann oder Feedback Sie gerne berücksichtigt sehen möchten. Danke an euch beide für all die Arbeit, Leidenschaft und Energie, die ihr in diesen Thread und in WinUI gesteckt habt! 😄

@mdtauk Wie immer machst du gute Punkte. Ich muss dieser Philosophie jedoch in einem wichtigen Punkt widersprechen, wenn dies wirklich der Ansatz von Microsoft ist.

Ich habe mich nicht dazu geäußert, ob ich mit dem Ansatz einverstanden bin oder nicht, nur, dass das Team seit meiner Zeit hier und beobachtete, wie Repos bewertet werden, daran arbeitet.

(sowohl aus dem angegebenen Grund als auch um sicherzustellen, dass wir über Partner für die Vorschauvalidierung verfügen, die dazu beitragen können, dass alle entwickelten Funktionen in Produktionsumgebungen, die eine Edge-Case-Abdeckung bieten, die erforderliche Leistung erbringen). Die Einhaltung dieser Bestrebungen wird möglicherweise nicht immer öffentlich übertragen, z zu diesem Zeitpunkt), aber dies war ein Präzedenzfall in allen unseren WinUI 2+-Steuerelementversionen.

Ich glaube, dass die Verwendung von Microsofts eigenen Apps und Shell als Beispiel eher Anerkennung hervorruft, da es zeigt, wo ein interner Bedarf für etwas bestand, das nicht existierte oder nicht zweckdienlich war, bis zu dem Punkt, an dem sie mussten " roll your own" - aber natürlich werden auch die großen Biester wie Netflix, Facebook usw., die Apps für Windows entwickeln, nach Steuerelementen und anderen Kleinigkeiten fragen.

Bei WinUI geht es nicht nur darum, Parität mit WPF, MFC, CommonControls, WinForms usw. zu erreichen - (aber die häufiger verwendeten dieser Legacy-Steuerelemente ohne ein modernes Äquivalent sollten ernsthaft betrachtet werden)

Die Tatsache, dass Brotkrumenriegel und Expander vorgeschlagen werden, ist ein Zeichen dafür, dass dies IMO beginnt. Und jedes Steuerelement oder jede API-Ergänzung sollte in einer idealen Umgebung evaluiert und "begründet" werden, genauso wie App-Designer ihre UIs und UX immer neu bewerten sollten, um sicherzustellen, dass sie für den Zweck geeignet sind. - In diesem Fall mag es offensichtlich erscheinen, aber wir sollten dennoch Beispiele präsentieren, in denen dieses Muster und diese APIs verwendet werden - um die Argumente für eine Einbeziehung zu stärken.

Zu den Animationen: Wie wäre es mit einem ElementAnimator-Ansatz, wie ihn der ItemsRepeater bietet? Die ElementAnimator API mit ihren StartShowAnimation() und StartHideAnimation() sieht vielversprechend aus ("show" wird für die Erweiterung verwendet, "hide" wird für das Zusammenklappen verwendet). Eine ElementAnimator-Eigenschaft könnte auf dem Steuerelement mit einer Standard-Animationsimplementierung angeboten werden. Wenn keine Animation gewünscht wird, könnte die Eigenschaft auf null gesetzt werden, oder wenn eine genauere Steuerung erforderlich ist, könnte dem ElementAnimator nur eine Show- oder Hide-Animation bereitgestellt werden.

Ich bin mit der ElementAnimator-API nicht allzu vertraut und es scheint, dass sie noch nicht in allen Szenarien verwendbar ist, da das Problem https://github.com/microsoft/microsoft-ui-xaml/issues/166 existiert. Wenn jedoch immer noch eine Funktionslücke besteht, könnten diese Arbeitselemente (Expander-Steuerung und ElementAnimator arbeiten, um sie durch die Expander-Steuerung nutzbar zu machen) möglicherweise synchronisiert und zusammen entwickelt werden.

Hmm, die Idee mit ElementAnimator ist wirklich interessant. Meine Sorge hier ist, dass dies zu kompliziert oder überdimensioniert sein könnte. Schließlich müssten wir für das ExpanderControl dann einen benutzerdefinierten ElementAnimator bereitstellen, während wir ansonsten vorhandene Themenanimationen wiederverwenden könnten. Außerdem bietet ElementAnimator mehr Methoden, als das Expander-Steuerelement tatsächlich benötigt, so dass es etwas umständlich erscheint.

Denke ich richtig, dass der ElementAnimator für die Behandlung von Offsets für untergeordnete oder enthaltene Elemente gedacht ist, die auf dem Bildschirm erscheinen?

Es kann übertrieben sein, je nachdem, was sich innerhalb des Panels befindet, das als Expander angezeigt wird, expandiert. Aber wenn es eine Möglichkeit gäbe, es irgendwie zu verbinden, also wenn das expandierende Bedienfeld Elemente enthält - könnte untergeordnete Animationen gesteuert werden, wenn der Entwickler etwas an das Element anhängt.

Der Expander steuert also die Übergänge der untergeordneten Elemente nicht direkt, kann sie jedoch aktivieren, wenn der Entwickler dies möchte

Ja, wenn wir hier wiederverwendbare Animationen erstellen könnten und den Kunden dennoch einige zufriedenstellende Anpassungsoptionen bieten könnten, wäre dies eine Erkundung wert. Wir haben beispielsweise bereits Aufforderungen zum Hinzufügen von Animationen zum TreeView-Steuerelement gesehen, wenn ein Element expandiert/komprimiert wird (https://github.com/microsoft/microsoft-ui-xaml/issues/208). Ich kann mir vorstellen, dass hier ein Fall angeführt werden kann, in dem ein Animationssatz erstellt werden könnte, der sowohl für den Expander als auch für das TreeView-Steuerelement großartig aussieht. Das wird automatisch mit einem gewissen Maß an Konsistenz zwischen den verschiedenen Kontrollen kommen. Schaffung einer visuellen Vertrautheit für den Benutzer, die auch ein überzeugendes Argument ist.

Ich denke, im Idealfall sollten TreeView und hierachische NavigationView einfach zum Expander-Steuerelement wechseln, wenn das Steuerelement fertig ist. Schließlich müssen beide Controls derzeit genau das gleiche Problem lösen, das von ExpanderControl gelöst würde. Eine gemeinsame Animation würde also für TreeView keinen großen Unterschied machen.

Die Sache mit ElementAnimator (wie ich es verstanden habe) ist, dass wir eine neue Animation schreiben müssten. Es gibt jedoch bereits integrierte Animationen, die wir für Expander nutzen könnten.

Es kann übertrieben sein, je nachdem, was sich innerhalb des Panels befindet, das als Expander angezeigt wird, expandiert. Aber wenn es eine Möglichkeit gäbe, es irgendwie zu verbinden, also wenn das expandierende Bedienfeld Elemente enthält - könnte untergeordnete Animationen gesteuert werden, wenn der Entwickler etwas an das Element anhängt.

Ich denke, einer der Hauptpunkte von ElementAnimator war es, Animationen zu Panels und Sammlungen hinzuzufügen, zB ItemsRepeater. Im Fall von Expander ist dies jedoch nicht wirklich der Fall, Expander ist kein Panel, das eine Sammlung von Elementen rendert.

Aus dem Kopf, eine Größenänderung für das übergeordnete Bedienfeld mit Easing. Dann würde sich ein Slide und Fade für das/die enthaltende(n) Objekt(e) richtig anfühlen.

Wenn es sich um einen generalisierten OS-weiten Übergang mit der richtigen Lockerung handelt, die vom Fluent Design-Bewegungsteam bestimmt wird, wäre das gut.

Taggen von @stmoy, da wir über Animationen sprechen.

Vielen Dank @SavoySchuler, dass Sie

@robloo Vielen Dank für Ihre Entschuldigung, ich verstehe Ihre Absichten voll und ganz und möchte auf jeden Fall, dass WinUI-Steuerelemente sinnvoll und effizient gestaltet und entwickelt werden. Ich bin neu im Team und schätze es sehr, dass die WinUI-Community so freundlich und enthusiastisch ist, den Umfang und die Implementierung von Expander zu diskutieren!

In diesem Sinne freue ich mich, diese neueren Kommentare zu Animationen durchzulesen!

Nach dem Durchlesen der Kommentare zu Animationen scheint es 3 mögliche Routen zu geben, geordnet nach steigendem Arbeitsaufwand:

Keine Set-Animation enthalten - dies hat den Vorteil, wie @chingucoding betont hat , dass es Entwickler nicht abschreckt, wenn ihr Szenario mit der Set-Animation nicht funktioniert oder gut aussieht. Das Risiko besteht hier in einer möglichen Inkonsistenz, obwohl es auf diesem Weg nicht wirklich viel "Raum" für Inkonsistenzen zu geben scheint.

@mdtauk schlug vor, einen ExpandTransition und CollapseTransition einzuschließen,

die die von der Eigenschaft des Steuerelements festgelegte Richtung verwenden können - was es dem Entwickler ermöglichen könnte, den Übergang für jeden festzulegen.

Klingt nach einem kleineren Umfang als die Verwendung von ElementAnimator. Würde dies den Entwicklern volle Flexibilität bei der Einstellung der Übergänge geben?

Aus dem Kopf, eine Größenänderung für das übergeordnete Bedienfeld mit Easing. Dann würde sich ein Slide und Fade für das/die enthaltende(n) Objekt(e) richtig anfühlen.

Ich verstehe Teile davon, aber es ist schwer für mich, ohne, nun ja, ein Bild zu visualisieren 😄. Bedeutet "Größe für das übergeordnete Bedienfeld ändern", dass sich die Größe der Kopfzeile ändert? Könnten Sie näher erläutern, was Sie mit "ein Slide and Fade für das enthaltende Objekt (e)" meinen?

@Felix-Dev vorgeschlagen mit ElementAnimator

Die ElementAnimator API mit ihren StartShowAnimation() und StartHideAnimation() sieht vielversprechend aus ("show" wird zum Expandieren verwendet, "hide" wird zum Collaps verwendet). Eine ElementAnimator-Eigenschaft könnte auf dem Steuerelement mit einer Standard-Animationsimplementierung angeboten werden. Wenn keine Animation gewünscht wird, könnte die Eigenschaft auf null gesetzt werden, oder wenn eine genauere Steuerung erforderlich ist, könnte dem ElementAnimator nur eine Show- oder Hide-Animation bereitgestellt werden.

@chingucoding hat das bemerkt

wir müssten dann einen benutzerdefinierten ElementAnimator bereitstellen, während wir ansonsten vorhandene Themenanimationen wiederverwenden könnten. Außerdem bietet ElementAnimator mehr Methoden, als das Expander-Steuerelement tatsächlich benötigt, so dass es etwas umständlich erscheint.

Einer der Hauptpunkte für ElementAnimator war das Hinzufügen von Animationen zu Panels und Sammlungen, zB ItemsRepeater. Im Fall von Expander ist dies jedoch nicht wirklich der Fall, Expander ist kein Panel, das eine Sammlung von Elementen rendert.

TreeView und hierarchische NavigationView sollten einfach zum Expander-Steuerelement wechseln, wenn das Steuerelement bereit ist. Schließlich müssen beide Controls derzeit genau das gleiche Problem lösen, das von ExpanderControl gelöst würde. Eine gemeinsame Animation würde also für TreeView keinen großen Unterschied machen.

Ich bin mir nicht sicher, ob TreeView und hierarchische NavigationView genau das gleiche Animationsszenario wie Expander haben, was ist, wenn Expander beliebige Inhalte (nicht unbedingt Text / Schaltflächen) in die Nähe schiebt und die Szenarien, in denen Expander miteinander "Akkordeon" sind und haben möglicherweise eine Logik zum Schließen / Öffnen, abhängig von der Erweiterung der anderen.

Ist ElementAnimator für Expander-Animationen übertrieben, da es für Panel-/Sammlungsanimationen gedacht ist?

@mdtauk schlug vor, einen ExpandTransition und CollapseTransition einzuschließen,

die die von der Eigenschaft des Steuerelements festgelegte Richtung verwenden können - was es dem Entwickler ermöglichen könnte, den Übergang für jeden festzulegen.

Klingt nach einem kleineren Umfang als die Verwendung von ElementAnimator. Würde dies den Entwicklern volle Flexibilität bei der Einstellung der Übergänge geben?

Aus dem Kopf, eine Größenänderung für das übergeordnete Bedienfeld mit Easing. Dann würde sich ein Slide und Fade für das/die enthaltende(n) Objekt(e) richtig anfühlen.

Ich verstehe Teile davon, aber es ist schwer für mich, ohne, nun ja, ein Bild zu visualisieren 😄. Bedeutet "Größe für das übergeordnete Bedienfeld ändern", dass sich die Größe der Kopfzeile ändert? Könnten Sie näher erläutern, was Sie mit "ein Slide and Fade für das enthaltende Objekt (e)" meinen?

Entschuldigung für die Verspätung, ich musste diese kleine Mock-up-Animation machen.
Ignorieren Sie die tatsächlichen Animationszeiten, sie dienen nur zur Veranschaulichung. Die rosa Umrandung ist der Expander-Header - und der grüne Rand ist für den Expander-Bereich/Inhalt usw.

Ich bin mir nicht sicher, ob TreeView und hierarchische NavigationView genau das gleiche Animationsszenario wie Expander haben, was ist, wenn Expander beliebige Inhalte (nicht unbedingt Text / Schaltflächen) in die Nähe schiebt und die Szenarien, in denen Expander miteinander "Akkordeon" sind und haben möglicherweise eine Logik zum Schließen / Öffnen, abhängig von der Erweiterung der anderen.

Die Frage ist, sollte Expander Animationen erzwingen? TreeView und Hierarchical NavigationView würden definitiv von einem eingebauten Expander-Steuerelement profitieren, das sich um das Erweitern/Zusammenklappen kümmert und es uns ermöglichen würde, in diesem Bereich eine einheitlichere Erfahrung zu machen. TreeView animiert beispielsweise nichts, während hierarchisches NavigationView das Drehen des Chevrons animiert.

Ist ElementAnimator für Expander-Animationen übertrieben, da es für Panel-/Sammlungsanimationen gedacht ist?

Es könnte sein, dass eines der Steuerelemente, die ElementAnimator (zumindest in der Vorschau) aktiv unterstützen, ItemsRepeater ist, das sich mit großen Panels befasst, die Dutzende von Elementen rendern. Expander hingegen hat kein so komplexes Szenario, sondern nur ein einziges Element zum Ein- / Ausblenden.

Eine andere Sache, die mir aufgefallen ist, ist, dass es keine Möglichkeit gibt, die Position des Chevrons anzupassen (links / rechts oder oben / unten). Vielleicht wäre dies als Anpassungspunkt nützlich? NavigationView platziert den Chevron rechts, während TreeView ihn links platziert. Gleiches gilt für vorhandene Erweiterungen im System, einige Bereiche der Einstellungs-App platzieren sie links, während Benachrichtigungen beispielsweise rechts platziert werden.

Eine andere Sache, die mir aufgefallen ist, ist, dass es keine Möglichkeit gibt, die Position des Chevrons anzupassen (links / rechts oder oben / unten). Vielleicht wäre dies als Anpassungspunkt nützlich? NavigationView platziert den Chevron rechts, während TreeView ihn links platziert. Gleiches gilt für vorhandene Erweiterungen im System, einige Bereiche der Einstellungs-App platzieren sie links, während Benachrichtigungen beispielsweise rechts platziert werden.

Wir könnten so etwas wie ein ExpandGlyphPlacementMode mit Werten wie TopLeft, TopRight, BottomCentered (und möglicherweise mehr (Left, Right, ...)) einführen und ein zusätzliches ExpandGlyphPlacementOffset Objekt, das Entwickler verwenden könnten, um die Basisposition (durch Platzierungsmodus eingestellt), falls erforderlich.

Darüber hinaus, wie @mdtauk bereits bemerkt hat, APIs, um die Glyphen zum Erweitern/Einklappen anzupassen (einige Steuerelemente verwenden > , andere verwenden v für ihre Glyphen zum Erweitern) und um die Sichtbarkeit der Glyphe.

Wir könnten so etwas wie einen ExpandGlyphPlacementMode mit Werten wie TopLeft, TopRight, BottomCentered (und möglicherweise mehr (Left, Right, ...)) und eine zusätzliche ExpandGlyphPlacementOffset-Eigenschaft einführen, mit der Entwickler die Basisposition (durch den Platzierungsmodus festgelegt) bei Bedarf ändern können .

Ich bin mir nicht sicher, ob TopLeft, TopRight ... hier die richtige Wahl ist. Vielleicht passt hier etwas wie "Start" und "Ende" besser?
Bei horizontalen Layouts wäre Start links (bei RTL-Sprachen rechts), bei vertikaler Öffnung wäre dies oben. "Ende" könnte dann entsprechend definiert werden. Das Problem, das ich bei TopLeft sehe ... ist, dass es viel Komplexität (siehe TeachingTip) mit geringem Nutzen einführt. TopLeft und TopRight wären gleich, wenn das ExpanderControl nach rechts öffnet. Ich denke, so etwas wie unten zentriert zu haben, wird in vielen Räumen etwas umständlich aussehen und viel Platz einnehmen.

Darüber hinaus, wie @ mdtauk (Erwähnung aufteilen, um seinen Posteingang nicht zu spammen) bereits bemerkt hat, APIs, um die Glyphen zum Erweitern/Einklappen anzupassen (einige Steuerelemente verwenden >, andere verwenden v für ihre Glyphen zum Erweitern) und um die Sichtbarkeit der Glyphe.

Die Frage ist, wie man dies erreicht. Wenn wir das Symbol ähnlich animieren möchten, was die hierarchische NavigationView tut, können wir keine API zum Austauschen der erweiterten und reduzierten Glyphe zulassen, die verwendet werden könnte, um zu v oder > für reduziert zu wechseln. Vielleicht könnten wir eine API haben, die die Richtung der eingeklappten Glyphe anzeigt?

Die Ideen für Animationen scheinen ziemlich gut zu sein. Sie müssen wie die Listenansicht et al. ein- und ausgeschaltet werden können. Der Header und die Glyphe müssen auch für RTL-Sprachen automatisch die Seiten wechseln. Die gesamte Glyphenanpassung scheint jedoch das Problem zu überfordern. Es ist unmöglich, einen Stil zu erstellen, der für alle identifizierten Fälle mit benutzerdefinierten Implementierungen funktioniert. Stattdessen sollte das Standarddesign genau wie bei CheckBox und anderen Steuerelementen das Beste sein, was wir tun können, aber der Standardstil sollte einfach genug sein, um eine neue Vorlage zu erstellen. Ich weiß nicht, warum jeder so ablehnend gegenüber der Neugestaltung von Kontrollen ist, es ist sehr viel die Lösung und tatsächlich eine große Stärke von weniger aussehenden Kontrollen. Das Hinzufügen weiterer Eigenschaften erhöht auch den Wartungsaufwand, von dem ich so viel höre.

Bearbeiten: Das Definieren von Ressourcen für ein paar Dinge, um das leichte Styling zu verbessern, könnte auch eine vernünftige Option sein.

Ich bin mir nicht sicher, ob TopLeft, TopRight ... hier die richtige Wahl ist. Vielleicht passt hier etwas wie "Start" und "Ende" besser?
Bei horizontalen Layouts wäre Start links (bei RTL-Sprachen rechts), bei vertikaler Öffnung wäre dies oben. "Ende" könnte dann entsprechend definiert werden. Das Problem, das ich bei TopLeft sehe ... ist, dass es viel Komplexität (siehe TeachingTip) mit geringem Nutzen einführt.

@chingucoding Die NavigationView verwendet einen vertikalen Öffnungsmodus (da ein NavigationViewItem vertikal erweitert wird), oder? Wie könnte ich dann die Glyphe entweder auf die linke oder die rechte Seite der Kopfzeile setzen? Ich lese Ihren Kommentar so, dass "Start" oben stehen würde, "Ende" wahrscheinlich dann unten in der Kopfzeile. Aber ich sehe keine Möglichkeit, anzugeben, ob die Glyphe in der oberen linken Ecke oder in der oberen rechten Ecke platziert werden kann. Ich sollte keine API wie ExpandGlyphPlacementOffset für etwas verwenden müssen, das wir so häufig sehen.

Ich denke, so etwas wie unten zentriert zu haben, wird in vielen Räumen etwas umständlich aussehen und viel Platz einnehmen.

Ich bin mir sicher, dass ich Beispiele dafür im Web, in Apps usw. gesehen habe... und deshalb kam ich auf diese Idee. Es wäre jedoch am besten, wenn hier Beispiele gepostet werden könnten, um zu sehen, ob dies direkt unterstützenswert ist oder ob wir dies einer erneuten Vorlage überlassen würden.

Die gesamte Glyphenanpassung scheint jedoch das Problem zu überfordern. Es ist unmöglich, einen Stil zu erstellen, der für alle identifizierten Fälle mit benutzerdefinierten Implementierungen funktioniert. Stattdessen sollte das Standarddesign genau wie bei CheckBox und anderen Steuerelementen das Beste sein, was wir tun können, aber der Standardstil sollte einfach genug sein, um eine neue Vorlage zu erstellen. Ich weiß nicht, warum jeder so ablehnend gegenüber der Neugestaltung von Kontrollen ist, es ist sehr viel die Lösung und tatsächlich eine große Stärke von weniger aussehenden Kontrollen.

@robloo Ich bin der abgeneigt, aber wenn man sich die bisher geposteten Beispiele ansieht, verwenden einige Entwickler ">" für den Erweiterungs-Glyoh und andere verwenden "v" für die Erweiterungs-Glyphe, wenn sie vertikal erweitert werden. Dasselbe wie für die Position der Glyphe. Das Expander-Steuerelement soll es Entwicklern sehr leicht machen, die Glyphe nach ihren Wünschen zu setzen. Das erneute Erstellen von Vorlagen ist immer mit Kompromissen verbunden, hauptsächlich, dass Sie nicht automatisch von zukünftigen Änderungen an der Steuerelementvorlage in WinUI profitieren. Stattdessen liegt diese Last nun bei den Entwicklern, um ihre benutzerdefinierten Vorlagen zu pflegen.

Wir sollten gängige Anpassungsszenarien identifizieren und uns bemühen, sie durch das Expander-Steuerelement so zugänglich wie möglich zu machen.

Nehmen Sie zum Beispiel diesen Fall von benutzerdefinierten Glyphen (zu finden auf der Fluent UI-Website ):

Die Anpassung von Glyphensymbolen bedeutet notwendigerweise, dass jede eingebaute Glyphenanimation sorgfältig geprüft werden muss. Auch interessant zu wissen: Was würden sich Kunden mehr wünschen - die Möglichkeit, die Glyphen einfach nach ihren Wünschen anzupassen oder eine eingebaute Animation für die Glyphe zu haben (wie in der NavigationView zu sehen). Ich persönlich denke, ersteres wäre wichtiger, aber ich habe keine harten Daten, um das zu belegen.

Ein weiteres Expander-Steuerelement ist das Telerik-Expander-Steuerelement , das einige der hier besprochenen Anpassungs-APIs (wie die Möglichkeit, die Position des Glyohs oder des Glyphensymbols zu ändern) verfügbar macht, die wir auch als Inspiration verwenden könnten.

ExpandedGlyph
CollapsedGlyph
Was der Entwickler nach Belieben überschreiben könnte

Glyphenplatzierung.Start .Ende .Oben .Unten
Vielleicht?

Verwenden Sie möglicherweise auch die Inhaltsausrichtung, um die Kopfzeile zu verarbeiten, die die Breite ausfüllt, oder lassen Sie Glyphe und Text zusammenfassen

Für das Notification Center gibt es ein klares Alles in derselben Zeile wie den Expander, wie würde das also gehandhabt? Gibt es eine Möglichkeit, das Expanding-Bedienfeld vom Expanding-Header zu trennen?

@chingucoding Die NavigationView verwendet einen vertikalen Öffnungsmodus (da ein NavigationViewItem vertikal erweitert wird), oder? Wie könnte ich dann die Glyphe entweder auf die linke oder die rechte Seite der Kopfzeile setzen? Ich lese Ihren Kommentar so, dass "Start" oben stehen würde, "Ende" wahrscheinlich dann unten in der Kopfzeile. Aber ich sehe keine Möglichkeit, anzugeben, ob die Glyphe in der oberen linken Ecke oder in der oberen rechten Ecke platziert werden kann. Ich sollte keine API wie ExpandGlyphPlacementOffset für etwas verwenden müssen, das wir so häufig sehen.

Das war meinerseits schlecht formuliert Mit "horizontaler Öffnungsmodus" meinte ich, dass die horizontale Dimension fest ist, also der Inhalt horizontal präsentiert wird. Gleiches für den vertikalen Modus. Und was ist die obere linke und untere linke Ecke? Ich würde davon ausgehen, dass das Symbol zentriert ist, meistens sollte der Header nicht einmal zu viel Platz im expandierenden Bereich einnehmen und oben links und unten links wären fast gleich.

Zur Verdeutlichung: Wenn der Expander in vertikaler Richtung erweitert wird, ist start links (rechts in RTL) und end rechts (links in RTL); in der horizontalen Expansion ist start oben und end unten. Ähnlich wie bei CSS flex-start und flex-end.

Visual Studio verwendet ein zentriertes Symbol, der Bereich der Erweiterungsschaltfläche streckt jedoch das gesamte Steuerelement:

Abgeschlossen:

Erweitert:

Glyphenplatzierung.Start .Ende .Oben .Unten
Vielleicht?

Das klingt nach einer sehr coolen Idee! Wie würde oben und unten aussehen? Ähnlich wie bei Visual Studio?

ExpandedGlyph
CollapsedGlyph
Was der Entwickler nach Belieben überschreiben könnte

Dies wäre eine Möglichkeit, dies zu tun, jedoch würden wir das Symbol nicht animieren (zB drehen). Ich denke jedoch, dass es sinnvoller ist, die Möglichkeit zu priorisieren, das Symbol vollständig auszuwechseln, als hier eine Animation zu haben.

Verwenden Sie möglicherweise auch die Inhaltsausrichtung, um die Kopfzeile zu verarbeiten, die die Breite ausfüllt, oder lassen Sie Glyphe und Text zusammenfassen

100%

Für das Notification Center gibt es ein klares Alles in derselben Zeile wie den Expander, wie würde das also gehandhabt? Gibt es eine Möglichkeit, das Expanding-Bedienfeld vom Expanding-Header zu trennen?

Ich befürchte, dass dieses spezielle Szenario zu komplex sein könnte, um es einfach mit der Expander-Steuerung zu erreichen. Die Platzierung der Schaltflächen ist ziemlich einzigartig, aber was noch wichtiger ist, die Kopfzeile und das Erweiterungssymbol befinden sich nicht in derselben Zeile, was mit einem Standard-Erweiterungssteuerelement, das Kopfzeile und Symbol nebeneinander platziert, ziemlich schwierig wäre. Hier ist ein Beispiel als Referenz:

Ich bin der Neuvorlage nicht abgeneigt, aber wenn man sich die bisher geposteten Beispiele ansieht, verwenden einige Entwickler ">" für das Erweiterungs-Glyoh und andere verwenden "v" für das Erweiterungs-Glyphe, wenn sie vertikal erweitert werden. Dasselbe wie für die Position der Glyphe. Das Expander-Steuerelement soll es Entwicklern sehr leicht machen, die Glyphe nach ihren Wünschen zu setzen.

@Felix-Dev Dies ist eines der Dinge, die im fließenden Designsystem standardisiert werden sollten. Es ist wichtig, dass Benutzer ein einheitliches Erscheinungsbild haben. Dies sollte sich nur dann ändern, wenn eine App dies tun muss, um ihre eigene Designsprache zu erfüllen, oder es einen neuen Anwendungsfall gibt, an den wir nicht gedacht haben. In diesem Fall - Vorlage neu erstellen.

Bearbeiten: Ich habe Ihr Telerik-Beispiel beim ersten Lesen vermisst. Denken Sie immer noch, dass wir die Komplexität zu stark erhöhen und zu viele Designoptionen zulassen, die: (1) von Benutzern nicht so leicht erkannt werden (2) viel Komplexität offenlegen, die in der Vergangenheit nicht benötigt wurde. Hier ist natürlich ein schmaler Grat. Wir möchten genügend Funktionalität bereitstellen, die Benutzer nicht neu erstellen müssen, aber wir möchten auch nicht so viel Funktionalität bereitstellen, dass die Designsprache verwischt wird.

WPF oder andere Expander-Steuerelemente, die mir einfallen, haben nie eine Eigenschaft bereitgestellt, um dies zu steuern. Es ist wirklich ein wesentlicher Bestandteil der Ansicht und sollte nur in XAML bestehen bleiben. Das Ansichtsmodell (dh die DPs des Steuerelements in diesem Fall) sollte nichts über eine solche Styling-Wahl in einem sauberen Lookless-Steuerelement wissen.

WPF oder andere Expander-Steuerelemente, die mir einfallen, haben nie eine Eigenschaft bereitgestellt, um dies zu steuern. Es ist wirklich ein wesentlicher Bestandteil der Ansicht und sollte nur in XAML bestehen bleiben. Das Ansichtsmodell (dh die DPs des Steuerelements in diesem Fall) sollte nichts über eine solche Styling-Wahl in einem sauberen Lookless-Steuerelement wissen.

@roloo Eine Möglichkeit, die ExpanderExpandGlyph und eine ExpanderCollapseGlyph (die NavigationView hat zum Beispiel eine NavigationViewItemExpandedGlyph Ressource).

Die Anpassung von Glyphensymbolen auf diese Weise könnte auch als Empfehlung gelesen werden, in der MDL2-Schrift vorhandene Schriftelemente bereitzustellen, wodurch von Fluent Design genehmigte Symbole verwendet werden. Wenn man sich die MDL2-Schriftart ansieht, scheint sie alle häufig verwendeten Glyphensymbole zum Erweitern/Reduzieren zu enthalten, die ich in Beispielen im Internet gesehen habe (die verschiedenen Chevrons, +/-, +/- in Kreisen, ...). Während Entwickler wahrscheinlich immer noch die FontFamily (von der SymbolThemeFontFamily Ressource bereitgestellt) überschreiben könnten, würden wir die ExpanderExpandGlyph ,...-Ressourcen nur direkt als öffentliche Ressourcen für das Steuerelement verfügbar machen, daher werden Entwickler möglicherweise zuerst Schauen Sie sich die MDL2-Schriftfamilie an, wenn sie die Symbole anpassen möchten (da dies die Standardschriftfamilie ist, die vom Expander für die Glyphen verwendet wird).

Für Interessierte gibt es noch mindestens ein weiteres, noch ungelöstes Problem, wie weit wir als WinUI gehen wollen, um einfache Anpassungs-Glyphenoptionen bereitzustellen, wenn nur ein fester Satz von Symbolen im gegebenen Kontext Sinn macht (Anpassung von Glyphen-Anpassungen für die NumberBox-Drehschaltflächen). : https://github.com/microsoft/microsoft-ui-xaml/issues/2789 Ich weiß zumindest, dass einige von euch dieses Problem bereits kennen, aber da ich einige Parallelen in der Diskussion dort sehe wie hier In Bezug auf das Freilegen der Anpassungsoption (Glyphe) hielt ich es für sinnvoll, hier darauf zu verweisen. Vielleicht kann die hier gefundene Lösung auch auf den NumberBox-Fall angewendet werden, um die Konsistenz in WinUI zu gewährleisten.

@Felix-Dev Deine Empfehlung für leichtes Styling macht für mich am meisten Sinn. Das meinte ich mit "Bearbeiten: Ressourcen für ein paar Dinge zu definieren, um das leichte Styling zu verbessern, könnte auch eine vernünftige Option sein." oben ein paar Anmerkungen.

Die Frage ist, wie wahrscheinlich es ist, dass Entwickler keine Glyphe bereitstellen, sondern eine andere Art von Symbol haben, z. B. ein BitmapIcon oder eine Form von benutzerdefiniertem FontIcon. Wenn Symbole ohne Glyphen nicht wirklich ein Anpassungspunkt sind, den viele Entwickler verwenden würden, denke ich, dass eine leichte Styling-Ressource für die Glyphe (und vielleicht eine für die Symbolschrift) hier das Beste ist, wie von

Eine erneute Vorlage ist immer eine Option, wenn eine Glyphe oder eine benutzerdefinierte Schriftart nicht ausreicht.

• Schriftart-Glyphen entweder mit Segoe MDL2 oder FluentIcons sind am wahrscheinlichsten und sollten wahrscheinlich die Standardeinstellung sein;

• Es ist auch überhaupt keine Glyphe üblich;

• Dann gibt es Pfade, SVGs, die weniger wahrscheinlich, aber sehr wahrscheinlich sind;

• Und dann PNGs oder vollständige Bitmaps als unwahrscheinliche, aber möglicherweise mögliche Option für Entwickler.

Welcher Ansatz auch immer verwendet wird, sollte sich wahrscheinlich auf die ersten beiden Szenarien konzentrieren, aber immer eine erneute Vorlage für das dritte zulassen.

Dann gibt es die Möglichkeit, einen ContentPresenter für die Glyphe zu haben und alles darauf legen zu lassen. Aber ich bin mir nicht sicher, wie das mit den VisualStates funktioniert, um von Collapsed zu Expanded zu wechseln.

Was die Animation des Symbols angeht - könnte hier vielleicht das Lottie-Steuerelement verwendet werden?

Ein weiterer Gedanke, genauso wie Sie den RadioButton und die RadioButtons als Gruppe davon haben...

Sollte eine Gruppe von Expandern eine Akkordeonsteuerung machen? Was würde ein Verhalten ermöglichen, bei dem nur ein einzelner Expander gleichzeitig erweitert werden kann?

https://explore.fast.design/components/fast-accordion

Eine erneute Vorlage ist immer eine Option, wenn eine Glyphe oder eine benutzerdefinierte Schriftart nicht ausreicht.

Schriftart-Glyphen entweder mit Segoe MDL2 oder FluentIcons sind am wahrscheinlichsten und sollten wahrscheinlich die Standardeinstellung sein;

Es ist auch überhaupt keine Glyphe üblich;

Dann gibt es Pfade, SVGs, die weniger wahrscheinlich, aber sehr wahrscheinlich sind;

Und dann PNGs oder vollständige Bitmaps als unwahrscheinliche, aber möglicherweise mögliche Option für Entwickler.

Welcher Ansatz auch immer verwendet wird, sollte sich wahrscheinlich auf die ersten beiden Szenarien konzentrieren, aber immer eine erneute Vorlage für das dritte zulassen.

Eine erneute Vorlage wird immer eine Option sein, aber das kann natürlich mit der Zeit kaputt gehen, wenn es (große) Änderungen an der Steuerung gibt. Daher ist es hier wahrscheinlich am besten, eine leichtgewichtige Ressource zu haben, da das Auswechseln von Glyphen (und Symbolschriftarten) die häufigsten Szenarien sind.

Dann gibt es die Möglichkeit, einen ContentPresenter für die Glyphe zu haben und alles darauf legen zu lassen. Aber ich bin mir nicht sicher, wie das mit den VisualStates funktioniert, um von Collapsed zu Expanded zu wechseln.

Die Verwendung eines ContentPresenter macht keinen Unterschied in Bezug auf das Zusammenklappen/Erweitern, es wäre nur ein Element wie die anderen.

Was die Animation des Symbols angeht - könnte hier vielleicht das Lottie-Steuerelement verwendet werden?

Die Frage ist, welche Art von Animationen Sie haben möchten. Einfache Rotation kann (und wird) bereits ohne Lotterie auskommen.

Ein weiterer Gedanke, genauso wie Sie den RadioButton und die RadioButtons als Gruppe davon haben...

Sollte eine Gruppe von Expandern eine Akkordeonsteuerung machen? Was würde ein Verhalten ermöglichen, bei dem nur ein einzelner Expander gleichzeitig erweitert werden kann?

Vielleicht könnte das eine separate Steuerung sein? Es gibt zwar Szenarien, in denen sie sich gegenseitig ausschließen könnten, aber ich denke, in vielen Fällen spielt es keine Rolle, ob mehrere offen sind.

Dann gibt es die Möglichkeit, einen ContentPresenter für die Glyphe zu haben und alles darauf legen zu lassen. Aber ich bin mir nicht sicher, wie das mit den VisualStates funktioniert, um von Collapsed zu Expanded zu wechseln.

Die Verwendung eines ContentPresenter macht keinen Unterschied in Bezug auf das Zusammenklappen/Erweitern, es wäre nur ein Element wie die anderen.

Aber wäre es ein ContentPresenter, der von beiden Staaten verwendet wird, oder einer pro Staat, der ausgelagert/umgeschaltet wird?

Was die Animation des Symbols angeht - könnte hier vielleicht das Lottie-Steuerelement verwendet werden?

Die Frage ist, welche Art von Animationen Sie haben möchten. Einfache Rotation kann (und wird) bereits ohne Lotterie auskommen.

Drehungen sind sinnvoll, wenn die Glyphe ein Richtungspfeil / ein Chevron ist - aber was ist, wenn es sich um eine Glühbirne handelt, die sich für ein Tipp- oder Hinweisszenario ein- und ausschaltet? Es gibt einen Vorschlag für eine verallgemeinerte animierte Symbolsteuerung mit Lottie #2802 - würde diese Situation dies erfordern, auch wenn die Standard-/häufigste Verwendung eine einfache Symboldrehung ist?

Ein weiterer Gedanke, genauso wie Sie den RadioButton und die RadioButtons als Gruppe davon haben...
Sollte eine Gruppe von Expandern eine Akkordeonsteuerung machen? Was würde ein Verhalten ermöglichen, bei dem nur ein einzelner Expander gleichzeitig erweitert werden kann?

Vielleicht könnte das eine separate Steuerung sein? Es gibt zwar Szenarien, in denen sie sich gegenseitig ausschließen könnten, aber ich denke, in vielen Fällen spielt es keine Rolle, ob mehrere offen sind.

Ich erwähne es nur, weil Fast Design eine Akkordeon-Steuerung enthält, und es ist im Wesentlichen dasselbe wie eine Reihe von Expandern - nur dass es eine Multi- und Single-Verhaltens-API gibt, die ihre Zusammenarbeit ändert. Mit einem Expander-Steuerelement wäre ein Akkordeon ein logischer nächster Schritt und sollte mit einer Orientierungseigenschaft zum Überschreiben der einzelnen Richtungen relativ einfach zu erreichen sein.

Dann gibt es die Möglichkeit, einen ContentPresenter für die Glyphe zu haben und alles darauf legen zu lassen. Aber ich bin mir nicht sicher, wie das mit den VisualStates funktioniert, um von Collapsed zu Expanded zu wechseln.

Die Verwendung eines ContentPresenter macht keinen Unterschied in Bezug auf das Zusammenklappen/Erweitern, es wäre nur ein Element wie die anderen.

Aber wäre es ein ContentPresenter, der von beiden Staaten verwendet wird, oder einer pro Staat, der ausgelagert/umgeschaltet wird?

Beide Optionen sind sinnvoll. Ich denke, dass es besser ist, den Inhalt des ContentPresenter zu wechseln, als den ContentPresenter auszutauschen oder zwei zu haben und einen auszublenden / anzuzeigen.

Was die Animation des Symbols angeht - könnte hier vielleicht das Lottie-Steuerelement verwendet werden?

Die Frage ist, welche Art von Animationen Sie haben möchten. Einfache Rotation kann (und wird) bereits ohne Lotterie auskommen.

Drehungen sind sinnvoll, wenn die Glyphe ein Richtungspfeil / ein Chevron ist - aber was ist, wenn es sich um eine Glühbirne handelt, die sich für ein Tipp- oder Hinweisszenario ein- und ausschaltet? Es gibt einen Vorschlag für eine verallgemeinerte animierte Symbolsteuerung mit Lottie #2802 - würde diese Situation dies erfordern, auch wenn die Standard-/häufigste Verwendung eine einfache Symboldrehung ist?

Eine Rotationsanimation wäre eine Möglichkeit zur Animation und wäre einfach zu erreichen. Ein Symbol zu haben, das in ein anderes animiert wird, wäre ganz anders. Das würde die API wahrscheinlich auch komplizierter machen (wie unterstützt man ein solches Verhalten? 2 Animationen und 2 Icons? oder eine Animation, die man stoppt?)

Ein weiterer Gedanke, genauso wie Sie den RadioButton und die RadioButtons als Gruppe davon haben...
Sollte eine Gruppe von Expandern eine Akkordeonsteuerung machen? Was würde ein Verhalten ermöglichen, bei dem nur ein einzelner Expander gleichzeitig erweitert werden kann?

Vielleicht könnte das eine separate Steuerung sein? Es gibt zwar Szenarien, in denen sie sich gegenseitig ausschließen könnten, aber ich denke, in vielen Fällen spielt es keine Rolle, ob mehrere offen sind.

Ich erwähne es nur, weil Fast Design eine Akkordeon-Steuerung enthält, und es ist im Wesentlichen dasselbe wie eine Reihe von Expandern - nur dass es eine Multi- und Single-Verhaltens-API gibt, die ihre Zusammenarbeit ändert. Mit einem Expander-Steuerelement wäre ein Akkordeon ein logischer nächster Schritt und sollte mit einer Orientierungseigenschaft zum Überschreiben der einzelnen Richtungen relativ einfach zu erreichen sein.

Richtig, ich verstehe. Ja, eine Akkordeon-Steuerung ist definitiv eine gute Idee nach der Expander-Steuerung und wäre wahrscheinlich einfach zu implementieren!

Drehungen sind sinnvoll, wenn die Glyphe ein Richtungspfeil / ein Chevron ist - aber was ist, wenn es sich um eine Glühbirne handelt, die sich für ein Tipp- oder Hinweisszenario ein- und ausschaltet? Es gibt einen Vorschlag für eine verallgemeinerte animierte Symbolsteuerung mit Lottie #2802 - würde diese Situation dies erfordern, auch wenn die Standard-/häufigste Verwendung eine einfache Symboldrehung ist?

Eine Rotationsanimation wäre eine Möglichkeit zur Animation und wäre einfach zu erreichen. Ein Symbol zu haben, das in ein anderes animiert wird, wäre ganz anders. Das würde die API wahrscheinlich auch komplizierter machen (wie unterstützt man ein solches Verhalten? 2 Animationen und 2 Icons? oder eine Animation, die man stoppt?)

Dies ist eine große Frage, und um ehrlich zu sein, ist dies etwas für den Animated Icon-Vorschlag.

Das Animieren der Glyphe/des Symbols ist in Ordnung, wenn es immer ein Pfeil ist. Aber es sperrt das irgendwie, es sei denn, Sie haben eine einfache Möglichkeit, die Animation selbst zu entfernen oder zu ändern.

Das Erstellen einer rotierenden Lottie-Animation behält die Standardanimation bei, bedeutet etwas mehr Aufwand für die Implementierung, ist jedoch flexibler, wenn es darum geht, das Symbol und die Animationen bei Bedarf zu ändern.

Die einfachste Option ist, einfach keine Animation für die Glyphe zu haben. Aber je mehr Sie hinzufügen, desto wichtiger wird es, das Überschreiben oder Ändern zu vereinfachen.

Wenn ich durch das Web schaue, sehe ich ziemlich viele statische Symbole, die in typischen Expander-UI-Beispielen für die Maximierungs- / Minimierungsglyphen verwendet werden. Unter Windows haben wir jedoch auch potenzielle Kunden dieses Steuerelements, die Animationen zu bevorzugen scheinen (siehe beispielsweise die NavigationView- und Toast-Benachrichtigungen in der Shell). Bewegung ist einer der Eckpfeiler von Fluent Design, daher ist es hier wahrscheinlich sinnvoll, denjenigen Kunden Optionen offen zu halten, die eine animierte Glyphe wünschen, ohne das Steuerelement neu erstellen zu müssen.

Wenn verschiedene Teams bei MS einen Expander mit einer animierten Glyphe (dh animierten Pfeilglyphen) verwenden möchten, bietet das Steuerelement idealerweise eine integrierte Option, sodass wir am Ende standardmäßig eine konsistente Erfahrung haben. Wenn jedes Team selbst für die Animation verantwortlich wäre, könnten wir am Ende unterschiedliche Animationsdauern, unterschiedliche Animationsrichtungen (dh im oder gegen den Uhrzeigersinn) sehen... action center unterscheidet sich von der Animation der Glyphe in der NavigationView. Das sollte nach Möglichkeit vermieden werden.

Animationen sind ein Genuss und tragen dazu bei, dass sich die Benutzeroberfläche reibungslos anfühlt. Harte Codierung in einem Rotations-Storyboard ist die einfache Möglichkeit, eine Animation hinzuzufügen, aber wenn diese Animation schwer zu entfernen oder zu ändern ist, wäre die Verwendung des AnimatedIcon-Steuerelements möglicherweise eine gute Möglichkeit, eine flexible Möglichkeit zur Anpassung zu bieten.

Ich sage nicht, dass der eine Weg besser ist als der andere – ich möchte hier nur darauf aufmerksam machen, da er eine Ikone animiert, und das ist das Raison Detra für die neue Steuerung.

Und wenn anerkannt wurde, dass die Glyphen anpassbar sein sollten, ist die Rotationsanimation möglicherweise nicht immer angemessen.

Was animiert werden soll und was nicht, ist eine sehr schwierige Frage. Wie Martin bereits erwähnte, ist eine Rotationsanimation nicht immer sinnvoll. Und animierte Icons haben noch viele offene Fragen.

Ich denke, es könnte dann besser sein, Glyphen- / Symbolanimationen für v1 zu kratzen, zumal dies nicht sehr verbreitet ist. Eine Sache, die wir dann noch einmal überdenken sollten, ist, die vorhandene Animation in der hierarchischen NavigationView zu entfernen, um eine einheitliche Erfahrung zu erzielen. Derzeit besteht bereits eine Inkonsistenz zwischen TreeView und h-NavigationView, um das Umschalten des Symbols zu animieren/nicht zu animieren.

Genau. Ich wollte hier mit meinem letzten Absatz keine Erkundungen entmutigen, sondern nur noch einmal schreiben, dass eine der Herausforderungen, denen wir uns hier gegenübersehen, darin besteht, genügend Anpassungsoptionen außerhalb der "ultimativen" - Neuvorlage - bereitzustellen, um den gemeinsamen Kunden zufrieden zu stellen möchte, aber dennoch sicherstellen, dass das Steuerelement dazu beiträgt, Windows mehr Konsistenz zu verleihen, anstatt potenziell weniger.

Wie wir bereits gesehen haben, gibt es hier möglicherweise keine perfekte Lösung, da der Wunsch, sowohl Symbolanpassungen als auch Animationsunterstützung (vielleicht zusätzlich zu integrierten Animationen aus Konsistenzgründen) bereitzustellen, leicht miteinander kollidieren können.

Es könnte hilfreich sein, potenzielle Kunden wie die Windows-Shell hier an Bord zu holen, um zu sehen, wie sie Animationen anzeigen. 10X wird angeblich einen gewissen Fokus auf Animationen legen und die Windows-Shell und In-Box-Windows-Apps könnten hier "Kunden" sein. Wenn eine animierte Glyphe als wichtiger Bestandteil der gesamten UX angesehen wird, die das Windows-Team mit 10X anstrebt, könnte dies vorerst nicht erfordern, dass diese Herausforderung "punting" wird, sondern stattdessen Animationsunterstützung in V1 bietet.

Ich würde mir einen einheitlichen Ansatz zum Animieren von Symbolen wünschen, der im Moment der Vorschlag für animierte Symbole zu sein scheint.

Ich würde keine Animation aus der NavigationView entfernen, da es sich um ein völlig eigenständiges neues Paradigma für WinUI handelt - und es scheint, als ob die Absicht darin besteht, all diesen ähnlichen Steuerelementen Animationen hinzuzufügen - also könnte das Steuerelement, sobald es fertig ist, sein zur NavigationView hinzugefügt

Es klingt, als wäre ElementAnimator zu viel für die Animation von Expander, und dass ExpandTransition und CollapseTransition ausreichen würden.

@mdtauk danke für die Erstellung der Mock-up-Animation! Ich verstehe, was Sie mit den expandierenden und kollabierenden Animationen gemeint haben.

Ich glaube, dass das Akkordeon-Verhalten durch Logik auf Listenebene (und nicht durch ein neues Akkordeon-Steuerelement) mit IsExpanded erreicht wird, damit Entwickler dies an verschiedene Szenarien anpassen können (Beispiel: wo einige Expander einander schließen und andere gleichzeitig erweitert werden können).

@Felix-Dev - Ich habe den Telerik Expander zum Vorschlag hinzugefügt, danke fürs Teilen!

Es hört sich so an, als ob der Wunsch nach Anpassbarkeit in den folgenden Richtungen besteht:

Glyphendarstellung : Leichtes Styling scheint der bevorzugte Weg zu sein, um Glyphen und Symbolschriftarten auszutauschen, indem ExpanderExpandGlyph und ExpanderCollapseGlyph . Ist diese Anpassungsstufe in v1 Expander erforderlich?

@Felix-Dev Während Entwickler die FontFamily (von der Ressource SymbolThemeFontFamily bereitgestellt) wahrscheinlich immer noch überschreiben könnten, würden wir nur die ExpanderExpandGlyph direkt verfügbar machen ... daher werden Entwickler möglicherweise zuerst die MDL2-Schriftfamilie betrachten, wenn sie möchten Passen Sie die Symbole an (da dies die Standardschriftfamilie wäre, die vom Expander für die Glyphen verwendet wird).

Glyphenanimation : einschließlich Wechsel zu einer anderen Glyphe bei der Erweiterung - was teilweise mit AnimatedIcon #2802 gelöst wird. Klingt so, als ob diese Anpassungsstufe für v1 Expander nicht erforderlich ist.
@chingucoding erklärte und ich neige dazu, zuzustimmen:

Ich denke, es könnte dann besser sein, Glyphen- / Symbolanimationen für v1 zu kratzen, zumal dies nicht sehr verbreitet ist.

Glyphenposition : Ist diese Anpassungsstufe in v1 Expander erforderlich? Dies wird noch komplizierter, wenn v1 ExpandDirection und die Option zum Ändern der Glyphenposition enthält. @Felix-Dev beschrieben

Etwas wie ein ExpandGlyphPlacementMode mit Werten wie TopLeft, TopRight, BottomCentered (und möglicherweise mehr (Left, Right, ...)) und eine zusätzliche ExpandGlyphPlacementOffset-Eigenschaft könnten Entwickler verwenden, um die Basisposition (durch den Platzierungsmodus festgelegt) bei Bedarf zu ändern.

Ich hoffe, ich habe die tolle Diskussion von diesem Wochenende richtig verstanden - lasst es mich wissen, wenn ich mich irgendwo irre! Vielen Dank für Ihre aufschlussreichen Gedanken dazu. 😄

Glyphendarstellung
Glyphenposition

Ich denke, dies sind die einfachsten und wichtigsten Anpassungen in V1.

Ich würde auch eine Möglichkeit hinzufügen, die Glyphe auszublenden

Glyphenanimation
Zustandsübergänge

Diesen könnte eine niedrigere Priorität eingeräumt werden, wenn eine Priorisierung erforderlich ist und das Kernverhalten und die Funktionalität zu lange dauern.

Danke für die Prioritätsbestellung @mdtauk!

Ich habe eine neue offene Frage hinzugefügt:

• Wie sollte Expander mit InfoBar arbeiten? Hinzufügen von Erweiterungsfunktionen zu InfoBar? Setzen Sie InfoBar als Inhalt eines Expanders ein? Die Umkehrung?

Ich könnte mir vorstellen, dass es den Inhalt ersetzen würde, aber ich denke, dass diejenigen, die die Informationsleiste entwerfen, eine Designspezifikation für eine zusammenklappbare Leiste bereitstellen sollten, die sich die Expander-Designer ansehen können.

Es ist ein Gespräch zu führen

Es gibt eine Menge großartiger Gespräche hier! Zum Thema Animationen...

Es hört sich so an, als ob ElementAnimator zu viel für die Animation von Expander ist und dass ExpandTransition und CollapseTransition ausreichen würden.

Stimmen Sie zu, dass ElementAnimator zu viel für die Animation von Expander ist. Es könnte funktionieren, wenn alles in einem ItemsRepeater wäre, aber ElementAnimator funktioniert noch nicht außerhalb von ItemsRepeater, also müssen wir das herausfinden.

Theoretisch gefällt mir die Idee, ExpandTransition und CollapseTransition zu haben, aber wir haben eine Menge Feedback erhalten, dass die Transition-APIs theoretisch gut, aber in der Praxis weniger gut sind, da sie nicht anpassbar sind welche sie verwendet werden, und ich glaube nicht, dass sie in der WinUI 2.x-Serie gebaut werden können, da sie auf OS-Hooks angewiesen sind. Da es diese spezifischen Übergänge nicht gibt, würde ich lieber andere Optionen erkunden, als unsere Sammlung von ThemeTransition-APIs hinzuzufügen.

Darüber hinaus wird der allgemeine Bereich der "Layout-Animationen", bei dem sich Inhalte aufgrund neuer UI-Elemente bewegen, die die Seite betreten/wachsen/verkleinern/verlassen, in Xaml als Plattform heute nicht gut unterstützt. Um dies zu beheben, wird auch WinUI 3 benötigt, ist aber nicht auf der unmittelbaren Roadmap.

Insbesondere für Expander denke ich, dass die richtige Vorgehensweise wahrscheinlich wie folgt aussehen wird:
1) Kodieren Sie die Animation zum Vergrößern/Schrumpfen fest im Expander-Code (und ziehen Sie in Betracht, eine API einzufügen, um sie auszuschalten - obwohl ich persönlich nicht denke, dass eine erforderlich ist)
2) Bieten Sie App-Entwicklern Anleitungen zum Animieren von Inhalten rund um den Expander, sodass der Inhalt unter dem Expander nach unten gleitet, anstatt nach unten zu "springen".

Ich glaube nicht, dass (2) im Allgemeinen ohne "Layout-Animationen" gelöst werden kann, aber wahrscheinlich mit RepositionThemeAnimation auf den Inhalt unter dem Expander umgangen werden kann.

@stmoy Wir könnten PopInThemeAnimation für (1) verwenden, wenn wir mit den vorhandenen gehen wollten.

Dieser Vorschlag wurde zum Schreiben von Spezifikationen genehmigt.

Im Rahmen einer Diskussion mit dem WinUI-Team haben wir festgestellt, dass Expander so ausgelegt werden könnte, dass er ExpandDirection für die Aufwärts-/Abwärtserweiterung in V1 unterstützt. Dies deckt die Szenarien ab, die wir für Expander gesehen haben, und legt die Grundlage dafür, in Zukunft möglicherweise eine Links-/Rechts-Erweiterung hinzuzufügen.

Bitte fühlen Sie sich ermutigt, die Diskussion hier fortzusetzen, und detailliertere Diskussionen über die Spec und die dazugehörige PR werden stattfinden, sobald sie verfügbar sind. Ich würde besonders gerne Ihre Meinung zu dieser offenen Frage hören:

• Wie sollte Expander mit InfoBar arbeiten? Hinzufügen von Erweiterungsfunktionen zu InfoBar? Setzen Sie InfoBar als Inhalt eines Expanders ein? Die Umkehrung?

Für InfoBar muss ich meiner Meinung nach einen separaten Vorschlag erstellen, um zu erfahren, was genau es benötigt und wie es dieses Expander-Steuerelement nutzen kann. Hier einige meiner ersten Gedanken:

• Eine InfoBar muss die Kopfzeile und den Inhalt/Bereich des Expander-Steuerelements anpassen. Die InfoBar sollte eine "abgeschnittene" Nachricht in der Kopfzeile anzeigen, wenn sie reduziert wird, und eine vollständige Nachricht im erweiterten Inhalt/Bereich, wenn sie geöffnet wird.
• Eine InfoBar _muss_ nicht, um das Abschneiden zuzulassen, und es sollte die Option für den Entwickler vorhanden sein, das aktuelle Umbruchverhalten bei Bedarf über eine "shouldTruncate"-Eigenschaft auszuwählen.
• Eine InfoBar könnte/sollte zu einem Expander "werden", wenn der Inhalt nicht mehr auf eine Zeile passt und shouldTruncate auf true gesetzt ist. Dies zu implementieren und zu verstehen, wann genau das Erweiterungsverhalten hinzugefügt werden muss, wird schwierig 😊 MessageBar mildert dies über ihre isMultiline-Eigenschaft, aber in diesem Bereich müssen weitere Überlegungen angestellt werden.

Ich denke, wir können derzeit auch andere Steuerelemente in WinUI untersuchen, die von diesem Expander-Verhalten profitieren könnten.

Einige anfängliche Comps zum Kürzen von InfoBar:

Für die Implementierung sind meine anfänglichen Gedanken, dass eine InfoBar von einem Expander abgeleitet und nicht in den Inhalt des Expanders geschachtelt werden sollte. Die Gedanken?

Ich denke, wir können derzeit auch andere Steuerelemente in WinUI untersuchen, die von diesem Expander-Verhalten profitieren könnten.

Einige anfängliche Comps zum Kürzen von InfoBar:

Ich denke, der Expander muss möglicherweise in der Lage sein, den Chevron-Knopf vom Inhalt zu trennen, der erweitert wird.

Benachrichtigungen tun dies

Es würde auch dem InformationBar-Steuerelement ermöglichen, seinen Expander zu integrieren.

Wenn Sie es trennen, wird das zu einem Verhalten/einer Eigenschaft? Wenn Sie also ein UI-Element oder eine Schaltfläche für diese Eigenschaft angeben, zeigt der Expander-Header die Schaltfläche nicht an?

Für die Implementierung sind meine anfänglichen Gedanken, dass eine InfoBar von einem Expander abgeleitet und nicht in den Inhalt des Expanders geschachtelt werden sollte. Die Gedanken?

Wenn der Expander den Inhalt und die Kopfzeile nicht von der Schaltfläche zum Umschalten/Freigeben trennen kann, würde dies mehr Arbeit für die Implementierung der Informationsleiste erfordern.

Speziell für die zukünftige Integration in verschiedene andere Controls sowie für die Verwendung in der Windows-Shell sollte das Expander-Control möglichst flexibel sein

Ich habe der Expander-Spezifikation erste Informationen hinzugefügt und eine PR geöffnet - bitte zögern Sie nicht, die Spezifikationsdiskussion dort fortzusetzen! Es ist PR 100 im Spec-Repo 😄