Microsoft-ui-xaml: 建议：向 WinUI 控件集添加一个扩展器控件。

创建于 2020-09-11 · 82评论 · 资料来源: microsoft/microsoft-ui-xaml

这是新功能或 API 提案的模板。例如，您可以使用它来针对现有类型提出新的 API，或者提出新的 UI 控件的想法。对于与 UWP 或应用程序模型相关的功能提案，请在 Project Reunion 存储库上打开一个问题：https://github.com/microsoft/ProjectReunion 如果您没有所有详细信息也可以：您可以从摘要开始和基本原理。此链接描述了 WinUI 功能/API 提案流程：https://github.com/Microsoft/microsoft-ui-xaml/blob/master/docs/feature_proposal_process.md

提案：WinUI 扩展器控件

已经针对这个问题打开了一个带有 PR 的规范。请继续在此提案中进行一般性讨论！

概括

在整个 Windows 中，Windows 安全、设置、照片、Paint 3D、通知中心、3D 查看器、Toasts 和 UWP Onedrive 应用程序使用不同的扩展器控件。目前没有一致的“Windows”方式来解决这种常见的用户体验模式。扩展器控件的动机在于它在许多应用程序场景中的使用以及与 WPF 的同等性。

基本原理

应该有一种内置且一致的 Fluent 方式来展开和折叠内容。
扩展器场景存在于行为和风格不一致的许多表面上，包括对讲述人友好、键盘控制、动画、设计和高对比度变化。

范围

| 能力 | 优先级 |
| :---------- | :------- |
| 跨 WinUI 应用程序提供一致的扩展器行为 | 必须|
| 根据用户与控件的交互进行大小扩展（推送其他内容）和折叠 | 必须|
| 支持未展开和展开内容中的Button、ToggleSwitch等控件| 必须|
| 支持4个方向扩展| 应该* |
| 支持在展开状态下修改所有内容（包括标题） | 可以|
| 支持扩展信息栏（关于实现的开放问题）| 可以|
| 包括扩展器之间的“手风琴行为”逻辑 | 不会|
| 轻装上阵 | 不会|

* v1 扩展器可以限定为仅向下扩展，默认向下扩展和扩展方向稍后添加。

重要笔记

提议的API

Public enum ExpandDirection 
{ 
Down = 0 
Up = 1 
Left = 2 
Right = 3 
} 

public class Expander : ContentControl 
{ 
Expander(); 

public object Header {get;set;} 
public DataTemplate HeaderTemplate { get;set; } 
public DataTemplate HeaderTemplateSelector {get;set;} 

public static readonly DependencyProperty HeaderProperty; 
public static readonly DependencyProperty HeaderTemplateProperty; 
public static readonly DependencyProperty HeaderTemplateSelectorProperty {get;} 

public bool IsExpanded { get;set} 
public ExpandDirection ExpandDirection { get;set;} 

protected virtual void OnExpanded(); 
protected virtual void OnCollapsed();

public event Expanded; 
public event Collapsed; 

public static readonly DependencyProperty IsExpandedProperty; 
public static readonly DependencyProperty ExpandDirectionProperty; 
} 

Visual States:  
ExpandStates: Expanded/Collapsed 

Accessibility: 
Support Expand/Collapse pattern (IExpandCollapseProvider)

其他地方的扩展器控件

扩展器场景示例

expandcontrol-4 1
expandcontrol-2

开放问题

在与WinUI团队讨论中，提出了向下扩展的V1可以缩短开发时间并使Expander更快地为开发人员提供（因为到目前为止Expander的场景都是向下的），并且计划中的V2可以添加ExpandDirection很快。在您的应用程序中，是否有任何扩展器需要向非向下方向扩展的场景？

Expander 应该如何与 InfoBar 配合使用？向 InfoBar 添加扩展功能？将 InfoBar 作为扩展器的内容？相反？

feature proposal team-Controls

资料来源

ejserna

👍15

最有用的评论

欢迎来到 WinUI 项目 @kat-y - Xaml 有着悠久的历史，但对于那些不熟悉它的人来说可能有点古怪。虽然 WinUI 是一个重新思考事物如何工作的机会，但在这种情况下，扩展器是一个相对简单的控件，因此从 WPF 到 WinUI 的简单移动就足够了。

@robloo我不同意您关于无需重新设计 XAML 控件模板的断言。 WPF AFAIR 有许多类似 chrome 的元素，这些元素在 WinUI/Fluent 中是不合适的。

处理 Chevron 和触摸目标大小，以及使用字体缩放大小。 Chevron 应该易于移除或添加。

这个例子有一个与文本一致的人字形。

这个例子根本没有人字形

这个例子有一个面向 V 形的前面

至于实现，打开和关闭时应该有动画过渡，除非用户关闭了动画，否则它只是切换状态。

mdtauk 于 2020-09-25

👍4 ❤2

所有82条评论

Expander 非常有用，自从它被添加以来，我一直在使用 Windows Community Toolkit 版本。不过，我不会过多地重新发明轮子，在我看来，只是从工具包中移植代码对于 1.0 版来说是完美的。

另一个例子：带有“MoreButton”的 ColorPicker 可以使用它。

robloo 于 2020-09-13

👍3

非常感谢您提交此提案！我将进行一些编辑，包括区分我认为真正的 Expander 场景和更像 Flyout/MenuFlyout 使用的场景。

kat-y 于 2020-09-21

我已更新此提案以包含有关范围、提议的 API 和以下未决问题的更多详细信息。

我们需要在 v1 Expander 中支持 ExpandDirection 吗？是否存在扩展器需要向非向下方向扩展的常见应用场景？

希望得到有关这些如何适合或不适合您的 Expander 用例的反馈！

kat-y 于 2020-09-25

我已更新此提案以包含有关范围、提议的 API 和以下未决问题的更多详细信息。
我们需要在 v1 Expander 中支持 ExpandDirection 吗？是否存在扩展器需要向非向下方向扩展的常见应用场景？
希望得到有关这些如何适合或不适合您的 Expander 用例的反馈！

它似乎确实是控件的基本功能

mdtauk 于 2020-09-25

👍3

它似乎确实是控件的基本功能

@mdtauk除了向下

kat-y 于 2020-09-25

是的，我们需要扩展方向。有很多使用它的情况，并且在 v1 版本之后添加它对控件模板进行不必要的破坏性更改。自 WPF 以来，Expander API 没有太大变化，这里的提案已经拥有所有必要的属性/事件/方法。我只想一次性实现所有这些，我们可以通过这种控制来完成。 UWP 社区工具包在设计方面进行了必要的更改，以更好地使用触控。我认为我们拥有所有的部分，没有必要重新发明任何东西。

编辑：社区工具包还有一个ContentOverlay属性。这可能是 V1 中可以跳过的内容。

robloo 于 2020-09-25

👍1

是的，我们需要扩展方向。有很多使用它的情况，并且在 v1 版本之后添加它对控件模板进行不必要的破坏性更改。

@robloo您能否详细说明这将是一个重大变化？我的理解是我们可以避免它在 V1 向下扩展时被破坏，而 V2 可以添加 ExpandDirection 并默认为向下。

kat-y 于 2020-09-25

它似乎确实是控件的基本功能
@mdtauk除了向下

自下而上加载新列表内容的聊天应用程序可能就是其中之一。

除了非常基本的基本要素：

已折叠
正在扩张
已扩展
正在折叠

以及 IsEnabled

下一个核心问题是扩展到哪里。

展开
向下展开
向左展开
向右展开

mdtauk 于 2020-09-25

自下而上加载新列表内容的聊天应用程序可能就是其中之一。

@mdtauk我不完全理解您对这个聊天应用程序示例的意思-您能详细说明一下吗？
至于属性 - 提议的 API 基于WPF Expander，所以我认为 IsExpanded 和 ExpandDirection 将涵盖它们。 IsEnabled 将用于什么 - 是否有您想要禁用扩展器的应用程序场景？

kat-y 于 2020-09-25

我过去使用的另一个示例是通常应该隐藏的次要、可编辑属性。只有在单击“选项”按钮并且扩展器向上打开时，这些才会显示在编辑器的底部。这真的取决于你想要的设计。扩展不同方向有很多有用的案例，似乎没有必要人为地限制这一点，尤其是在过去的惯例如此强大的情况下。我不认为这在控件的 V1 中会太困难，特别是因为所有问题都已经在社区工具包和 WPF 中解决了。

@robloo您能否详细说明这将是一个重大变化？我的理解是我们可以避免它在 V1 向下扩展时被破坏，而 V2 可以添加 ExpandDirection 并默认为向下。

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

我想如果您在设计模板和视觉状态时非常小心，就有可能使其不间断。但是，要做到这一点，您确实需要设计功能，因此您不妨实现它。这都是相当基本的，没有理由从一开始就对这个控件进行 V2 计划。

我知道重新发明轮子很诱人。但是请保留它，以便将应用程序从 WPF 移植到 WinUI 的人可以做到这一点，而无需进行任何绝对必要的代码更改。 WinUI 需要开始纠正 UWP 的一些错误。

robloo 于 2020-09-25

👍1

IsEnabled 将用于什么 - 是否有您想要禁用扩展器的应用程序场景？

@mdtauk是正确的，这也需要支持 IsEnabled。每当有输入或状态更改的可能性时，禁用控件是非常强大的约定。请不要让我们为此辩护。

robloo 于 2020-09-25

👍3

在上面的屏幕截图中，Windows 安全有一个用于防病毒部分以及左侧导航菜单的扩展器。这显示了在多个应用程序需要支持的多个方向上非常真实地使用扩展器。我的投票是支持 V1 中的多个方向。

JustABearOz 于 2020-09-25

@robloo

我过去使用的另一个示例是通常应该隐藏的次要、可编辑属性。只有在单击“选项”按钮并且扩展器向上打开时，这些才会显示在编辑器的底部。

您能否详细说明发生这种情况的屏幕截图或特定应用程序，以便我可以更多地了解场景？ 我可以想到编辑器，其中一个选项按钮打开一个带有更多按钮的弹出窗口，但在我熟悉的那些中，其他内容不会向上推 - 弹出/弹出行为而不是扩展。

我想如果您在设计模板和视觉状态时非常小心，就有可能使其不间断。但是，要做到这一点，您确实需要设计功能，因此您不妨实现它。这都是相当基本的，没有理由从一开始就对这个控件进行 V2 计划。
我知道重新发明轮子很诱人。但是请保留它，以便将应用程序从 WPF 移植到 WinUI 的人可以做到这一点，而无需进行任何绝对必要的代码更改。

我同意你的观点，将应用程序从 WPF 移植到 WinUI 应该尽可能顺利！在与WinUI团队讨论中，提出了向下扩展的V1可以缩短开发时间并使Expander更快地为开发人员提供（因为到目前为止Expander的场景都是向下的），并且计划中的V2可以添加ExpandDirection很快。（我将编辑未解决的问题以获得这个额外的上下文）这就是为什么我希望了解开发人员是否有非向下扩展器的特定用例！ 😄

每当有输入或状态更改的可能性时，禁用控件是非常强大的约定。请不要让我们为此辩护。

感谢您对此进行解释，禁用状态更改是此类控件的理想功能是完全有道理的！

kat-y 于 2020-09-25

在上面的屏幕截图中，Windows 安全有一个用于防病毒部分以及左侧导航菜单的扩展器。这显示了在多个应用程序需要支持的多个方向上非常真实地使用扩展器。我的投票是支持 V1 中的多个方向。

@JustABearOz我认为左侧导航菜单实际上是一个NavigationView 。 😃 我同意防病毒部分是一个扩展器场景，在这种情况下向下扩展。很想知道您对非向下扩展器的任何特定用例！

kat-y 于 2020-09-25

@kat-y 好的，这消除了对左/右的需求，但是窗口中的 2 个示例似乎可以扩展，可以轻松应用于应用程序：
1：上面带有快速操作菜单的屏幕截图。可以肯定的是，它会扩大。
2：在windows中，系统托盘的弹出日历有一个部分，可以展开以显示议程/约会。

是否可以支持 V1 的 Up/Down 而不仅仅是 Down？

JustABearOz 于 2020-09-25

👍1

1：上面带有快速操作菜单的屏幕截图。可以肯定的是，它会扩大。

@JustABearOz非常感谢您提出这些示例！对于 1：我认为这是一个有趣的边缘情况 - 扩展是从“标题”（扩展按钮）“向下”，但控件本身位于表面的底部，因此标题（和扩展的内容）必须向上“移动”（否则它会跑出屏幕！）。似乎是在应用程序的“底部”处理扩展项的好方法，您同意吗？

2：在windows中，系统托盘的弹出日历有一个部分，可以展开以显示议程/约会。
是否可以支持 V1 的 Up/Down 而不仅仅是 Down？

我同意你的看法，这是一个标题在区域底部并向上扩展的场景！在这种情况下，日历的扩展器（以及整个弹出窗口）与任务栏相关联 - 您是否在应用程序中遇到过扩展器具有类似绑定位置而需要向上扩展的情况？

kat-y 于 2020-09-25

😕1 👍1

@kat-y 我没有冒犯的意思，但我觉得我们不得不重新解释 15 年前已知的事情。我不明白你为什么要我们举例说明实际使用中的扩展方向。我希望在内部，您必须将此用于规范审查并向管理层进行辩护。但解释可以简单地是 (1) 您需要授权用户实现他们的设计目标，微软不能说可以/不能使用控件做什么，而是由应用程序开发人员/设计师来发现什么是最好的对于他们的用例（look-less 控件的一个关键概念） (2) 最重要的是，这根本不是一个新想法。您正在复制此区域中的现有 API，并且需要保持应用程序兼容性。同样，如果这是一个新想法，我会更理解为什么我们必须捍卫它——在投入时间之前确保功能有用是很好的。

除了标题之外，这个控件中还有两个属性，如果是 C#，我可以在几个小时内使用 WCT 基础编写它。我们将花费更多的工时来谈论它而不是实现它，因为它现在存在于 WPF/WCT 中。

robloo 于 2020-09-25

👍3

感谢@robloo的输入，我正在联系 WinUI 团队，讨论当这些建议存在于其他第三方库（如 Toolkit）时，我们如何使这些建议最初更加健壮。我绝对认为调用现有示例应该是问题模板的一部分。

仅供参考@ranjeshj @ryandemopoulos @stmoy

michael-hawker 于 2020-09-25

@robloo谢谢你对我说实话！我知道应用程序开发人员应该能够确定什么最适合他们的用例，并且应用程序兼容性很重要。我希望与@michael-hawker 和 WinUI 团队的讨论将帮助我们在确定 Expander 的范围方面富有成效地前进！

以前我没有任何具体的例子来说明在非向下方向上使用扩展器。我将把来自 WinUI 社区的任何示例（包括@justABearOz指出的日历弹出）以及我从 Michael 那里学到的任何示例带到与 WinUI 团队的讨论中，作为在 Expander 的 v1 中保留 ExpandDirection 的证据。

我已经用我知道的扩展器控件列表更新了提案 - 如果我遗漏了什么，请告诉我。

kat-y 于 2020-09-25

我查看了 WPF 源代码和 WCT 源代码。我相信这也可以在几个小时内在 WinUI 中实现。尽管ContentOverlay属性可能应该重命名或排除在 V1 之外，但控件应该遵循我所看到的 WCT 实现。

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

由于这两个来源均来自 Microsoft 并获得 MIT 许可，因此它们应该是基础，不要从零开始。 Xamarin Forms 不符合 WPF->WinUI 的概念，因此可能应该被忽略（也没有附加功能）。从我所见，第 3 方解决方案也没有任何开创性的新想法。这种控制在很大程度上经受住了时间的考验。

robloo 于 2020-09-25

👍1

@robloo谢谢你对我说实话！我知道应用程序开发人员应该能够确定什么最适合他们的用例，并且应用程序兼容性很重要。我希望与@michael-hawker 和 WinUI 团队的讨论将帮助我们在确定 Expander 的范围方面富有成效地前进！

以前我没有任何具体的例子来说明在非向下方向上使用扩展器。我将把来自 WinUI 社区的任何示例（包括@JustABearOz指出的日历弹出）以及我从 Michael 那里学到的任何示例带到与 WinUI 团队的讨论中，作为在 Expander v1 中保留 ExpandDirection 的证据。

好吧，我的观点是真的不应该有太多关于这个的讨论。我选择在这里表达我的不满，因为这个控件是一个完美的例子。新的寻呼机控件或面包屑控件确实需要更多的监督，遵循流程很重要。然而，一个大型流程的开销一再显示出来，您将花费更多的工时做非增值的文书工作和讨论，而这些只是从 WCT 实施控制。我还没有看到 WinUI 团队使用其他之前的工作，这有点令人担忧。无需重新设计 XAML 控件模板。

robloo 于 2020-09-25

👍1

@robloo我不同意您关于无需重新设计 XAML 控件模板的断言。 WPF AFAIR 有许多类似 chrome 的元素，这些元素在 WinUI/Fluent 中是不合适的。

处理 Chevron 和触摸目标大小，以及使用字体缩放大小。 Chevron 应该易于移除或添加。

这个例子有一个与文本一致的人字形。

这个例子根本没有人字形

这个例子有一个面向 V 形的前面

至于实现，打开和关闭时应该有动画过渡，除非用户关闭了动画，否则它只是切换状态。

mdtauk 于 2020-09-25

👍4 ❤2

至于实现，打开和关闭时应该有动画过渡，除非用户关闭了动画，否则它只是切换状态。

我正要问动画。是否应该有办法为控件禁用它们，例如在动画布局过于昂贵的情况下？并非所有用户/开发人员都想要动画，因为它可能感觉有点反应迟钝或不想要（例如 TreeView）。不必重新模板控件来自定义该点可能会更好。另一件可以定制的事情是动画持续时间，在某些情况下，短动画比长动画更好。

chingucoding 于 2020-09-25

感谢所有精彩的讨论。一些想法

我们将需要像@mdtauk提到的那样更新模板，以考虑新设计以及在可能的情况下减少元素/提高性能的机会。
IsEnabled 是从 Control 继承的，所以我希望它可以工作。

ranjeshj 于 2020-09-25

👍3

至于实现，打开和关闭时应该有动画过渡，除非用户关闭了动画，否则它只是切换状态。
我正要问动画。是否应该有办法为控件禁用它们，例如在动画布局过于昂贵的情况下？并非所有用户/开发人员都想要动画，因为它可能感觉有点反应迟钝或不想要（例如 TreeView）。不必重新模板控件来自定义该点可能会更好。另一件可以定制的事情是动画持续时间，在某些情况下，短动画比长动画更好。

我相信某些控件具有可以分配给的 Transition 属性。因此，如果将非动画故事板作为资源包含在内，则可以应用它并且无需任何重新模板即可处理该故事板。

当系统设置关闭动画时，您必须覆盖过渡。

UIElement.Transitions？
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions?view=winrt-19041

此外，对于 IsEnabled 属性，还需要一个 Disabled 状态。是否应该有一个禁用扩展和禁用折叠，或者禁用总是折叠？

mdtauk 于 2020-09-25

关于动画的有趣点。我们使用系统设置关闭所有动画，但我认为除了当前重新模板之外，我们不会公开旋钮来关闭动画。

ranjeshj 于 2020-09-25

👍1

关于动画的有趣点。我们使用系统设置关闭所有动画，但我认为除了当前重新模板之外，我们不会公开旋钮来关闭动画。

我相信你可以添加一个 Style 用 null 覆盖 Transition 集合，如果你想关闭动画，假设有一个 Transition 集合要覆盖。

stmoy 于 2020-09-25

👍1

包括ExpandTransition和CollapseTransition ，它们可以使用控件属性设置的方向 - 这可以允许开发人员为每个设置过渡。

我喜欢这个想法，但我认为今天没有一种方法可以创建自定义主题转换，这会限制自定义的能力。这将允许通过删除它轻松禁用它。

mdtauk 于 2020-09-25

👍1

此外，对于 IsEnabled 属性，还需要一个 Disabled 状态。是否应该有一个禁用扩展和禁用折叠，或者禁用总是折叠？

为什么不镜像 TreeView 控件，您可以在其中使用IsExpanded和IsEnabled属性来创建您需要的两者的任何组合？如果禁用扩展在某些情况下效果最佳，则可以这样做。如果您需要禁用折叠，这也是可能的。

Felix-Dev 于 2020-09-25

👍3

@robloo我不同意您关于无需重新设计 XAML 控件模板的断言。 WPF AFAIR 有许多类似 chrome 的元素，这些元素在 WinUI/Fluent 中是不合适的。

@mdtauk好吧，我的建议是我们“应该在此处遵循 WCT 实施”： https : //docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander 。已经进行了适应触摸和更现代界面的设计更改。当然，没有人能设计得像你一样好，所以我相信还有改进的余地。仍然改变“设计”不需要重新设计模板以支持所有扩展方向。 WCT 应该是基础，然后如果我们有新的样式要应用，很好，它可以快速完成，但不能从头开始。

robloo 于 2020-09-25

👍1

@robloo我不同意您关于无需重新设计 XAML 控件模板的断言。 WPF AFAIR 有许多类似 chrome 的元素，这些元素在 WinUI/Fluent 中是不合适的。
@mdtauk好吧，我的建议是我们在这里“应该遵循 WCT 实施”...
我假设你的意思是 WPF 版本的 XAML 没有变化

但我仍然认为 WinUI 设计团队需要确认它及其变体——如果只是为了确认包含在 figma 工具包中的规范

mdtauk 于 2020-09-25

@kat-y 如果你是这个项目的新手，如果我听起来很刺耳，我深表歉意。关于如何在某些肯定需要的领域提高项目速度，我确实支持上述观点。此外，我们应该如何使用过去已经完成的工作，并在过去 15 年中进行了大量的实战测试。当然，这一切都不是针对您个人或任何人的。这是我多年来在微软看到的一个普遍的“膨胀”问题，团队需要更加精简和重新平衡，以支持更多的编码/更少的项目管理。与计划一样好，没有什么比试错更胜一筹的，因此迭代速度最终获胜。

@ranjeshj @michael-hawker 为什么不使用社区工具包中已经完成的工作？这不是 WinUI 团队第一次采取新的方法。在最坏的情况下，这会不必要地重复工作并导致碎片化。 WCT 版本已经基于 WPF 的思想并进行了必要的“现代”更改。

robloo 于 2020-09-25

❤1

@ranjeshj @michael-hawker 为什么不使用社区工具包中已经完成的工作？这不是 WinUI 团队第一次采取新的方法。在最坏的情况下，这会不必要地重复工作并导致碎片化。 WCT 版本已经基于 WPF 的思想并进行了必要的“现代”更改。

我相信社区工具包是用 C# 编写的，而 WinUI 需要 C/C++ 代码。

此外，WinUI 设计团队对 Toolkit 版本没有发言权，因此 Windows 和 App 设计团队的需求可能有特定的需求，如果他们要采用对自定义解决方案的控制。

mdtauk 于 2020-09-25

👍1

我相信社区工具包是用 C# 编写的，而 WinUI 需要 C/C++ 代码。

在 C# 和 C++/WinRT 之间转换代码相对简单。特别是对于我已经看过代码https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander的扩展器

此外，WinUI 设计团队对 Toolkit 版本没有发言权，因此 Windows 和 App 设计团队的需求可能有特定的需求，如果他们要采用对自定义解决方案的控制。

对于具体点，是的。但是，对于一般控制功能，我必须不同意。 WCT 将使我们完成 95% 的功能，并完成 100% 的功能。在顶部应用的任何设计更改都是微不足道的。

robloo 于 2020-09-25

👍1

@robloo你能详细说明哪些功能不同吗？上面提出的 API 与 WPF/WCT 非常匹配，同时试图与 WinUI 中的现有模式保持一致。

ranjeshj 于 2020-09-25

@ranjeshj我们可能不在同一页面上。我并不是说提议的 API 与 WCT 或 WPF 有很大不同。

有人提到此控件的第一个版本可能不支持 ExpandDirection。对于具有此功能的悠久历史的扩展器来说，这似乎是一个问题。然后似乎我们必须证明为什么需要这个功能。

我建议以 WCT 为基础，以扩展方向快速实现这一点。在复制粘贴 XAML 模板时，不需要重新发明轮子，因为只需要一个 C# -> C++ 的端口（并且代码隐藏非常小）。这将实现我们需要的所有功能，并避免没有足够时间添加 ExpandDirection 的担忧。这种方法会给我们一个功能齐全的控件。然后可以根据@mdtauk或任何其他人的建议在顶部完成任何设计/样式更改。我不明白 (1) 为什么 ExpandDirection 可能在 V1 的斩波块上 (2) 为什么如果时间是限制我们不使用现有代码。

是的，我对 WinUI 3 开发的不满情绪蔓延到了这几个地方，对此我深表歉意。

robloo 于 2020-09-25

👍1

@robloo这不是关于在砧板上的东西 - 但我相信加入团队的新人会重新审视这些控件和 API，看看哪些是最重要的 - 并可能在引入新控件时去除多余的东西，或将控件移植到 WinUI。

当优先考虑哪些特性是 V1 中必不可少的，然后是 V2 中，只有核心和基本属性和行为会在那里，而不是不常用的遗留东西。

微软似乎根据客户的需求和愿望来决定添加哪些功能——而不仅仅是与旧框架达到同等水平。

所以它不是_justifying_，而是试图了解开发人员在他们的 UI 中实际使用这些控制模式做什么。
单独的 Windows Shell 具有多个版本的扩展器控件模式这一事实将是一个足够清楚的理由来包含它。事实上，每个实现看起来都不同，如果没有不同的话——这足以让设计团队整合控制设计以满足内部团队的需求。

mdtauk 于 2020-09-25

👍1

@mdtauk和往常一样，你提出了很好的观点。但是，如果这确实是微软正在采取的方法，我必须在一个关键方面不同意这一理念。 WinUI 要成功，它必须对现有的应用程序开发人员有意义。我正在努力避免另一个 UWP 场景，因为我们都知道 UWP 从未起飞。微软需要说服的开发人员使用 WinUI，就像之前的 UWP 一样，都是 WPF 开发人员。 WPF 应用程序从未跳转到 UWP 的原因之一是因为 UWP，尤其是在首次发布时，在几个关键功能领域的等效性非常差。这就是为什么当我看到路线图上缺少圆角时，我开始回忆 UWP 的噩梦（WPF 的基础圆角在 UWP 中被遗漏了很长时间）。排名第一的优先级应该是来自 WPF 和 UWP 的流畅移植体验，老实说，WPF 应该是更高的优先级，因为那里有更多的应用程序，而且微软显然首先专注于使用 WinUI 的桌面案例。因此，我们必须非常小心并积极避免重新发明轮子。

事实上，每个实现看起来都不同，如果没有不同的话——这足以让设计团队整合控制设计以满足内部团队的需求。

我一直明白设计可能需要修改。使用lookless-control 概念，这是一个与ExpandDirection 不同的问题。如果我们需要更多地现代化设计或使其在某些情况下更有用，那很好 - 它应该相对微不足道。在一天结束时，它也可以完全重新模板用于需要精细控制的那些。

robloo 于 2020-09-25

👍1

关于动画的有趣点。我们使用系统设置关闭所有动画，但我认为除了当前重新模板之外，我们不会公开旋钮来关闭动画。

公平地说，几乎没有控件使用动画。 TreeView 和 NavigationView 本质上使用扩展器，但都不使用动画来展开/折叠。大多数使用动画的控件通常都依赖于它们，例如 ProgressBar 或 ProgressRing。然而，Expander 并不依赖它，它更像是一个“很高兴拥有”。另一个例子是有些人没有使用 WCT Expander 控件，因为他们不喜欢动画。如果我们想包括尽可能多的人，有一个简单的方法来禁用不需要的动画会更容易。

我相信你可以添加一个 Style 用 null 覆盖 Transition 集合，如果你想关闭动画，假设有一个 Transition 集合要覆盖。

但这会是禁用/启用它的常用方法吗？大多数情况下，当我们提供多种样式时，它们的差异比仅一种动画更显着，例如 AccentColorButtonStyle 或 RevealButtonStyle。

包括 ExpandTransition 和 CollapseTransition，它们可以使用由控件的属性设置的方向 - 这可以允许开发人员为每个设置过渡。

我真的喜欢这个主意！

我喜欢这个想法，但我认为今天没有一种方法可以创建自定义主题转换，这会限制自定义的能力。这将允许通过删除它轻松禁用它。

我也很关心这个。使用没有任何自定义主题转换的 ExpandTransition 和 CollapseTransition API，这几乎只有“ExpendTransitionEnabled”和“CollapseTransitionEnabled”。

chingucoding 于 2020-09-25

👍1

@robloo如果您想谈谈有关 WinUI 3 开发的挫折，欢迎您给我写信（我的 Twitter 和工作电子邮件在我的 GitHub 个人资料中）。我不完全了解您目前的挫败感，但我通常是一个很好的人，可以从与客户或社区参与/发展相关的主题开始，并且在去年我已经运行了大量的焦点小组涵盖了您在工具、功能奇偶校验等方面列出的注意事项。

我会注意到我们的路线图非常紧张，所以我不能保证我有能力做出你想要看到的改变，但知道可以做些什么来更好地支持你总是有帮助的WinUI 的客户和/或贡献者，因此最坏的结果是，至少我们的团队会充分考虑您的需求。在最好的情况下，我想这将取决于你在寻找什么。让我们聊天？ 😄

@mdtauk感谢您对澄清的支持 - 您总是很好！我要说的是，我们的盘子上显然有很多事情要做，团队致力于尽可能精简和有效，努力在所有领域实现最有意义、最有影响力的进展。为了在所有其他持续进步的领域中继续投资新控件/功能，我们的团队成员需要像@kat-y 开发_非常_明确的需求规范，因为对我们来说最糟糕的事情是将我们有限的一部分资源投入到一个旋钮或API 实际上并没有被广泛使用，因为不仅有前期的开发成本，还有后期的持续维护成本。我只是简单地解析了这个线程，但对于@kat-y 来说，特别是作为一个新的团队成员，想要完全清晰地确保在一个真正的应用程序中有一个需要所请求的功能的真实场景是合理的（出于上述原因，也是为了确保我们拥有预览版验证合作伙伴，这些合作伙伴能够帮助确保所有开发的功能在提供边缘案例覆盖的生产环境中按要求执行）。遵守这一愿望可能并不总是公开广播，例如在验证合作伙伴是私人的情况下（如果您的需求不适合在此处公开发布，欢迎您直接联系@kat-y目前），但这在我们所有的 WinUI 2+ 控件版本中都是先例。

我希望这有帮助吗？我的目标是将此线程转回 @kat-y 和手头的 Expander 主题，但如果我可以回答更多问题或您希望看到的反馈，请直接与我联系。感谢你们在这个线程和 WinUI 中付出的所有工作、热情和精力！ 😄

SavoySchuler 于 2020-09-25

👍2 ❤1

@mdtauk和往常一样，你提出了很好的观点。但是，如果这确实是微软正在采取的方法，我必须在一个关键方面不同意这一理念。
我没有评论我是否同意这种方法，只是从我在这里的时间和观察 repos 的评估方式开始，我相信团队正在为此而努力。

（出于上述原因，也是为了确保我们拥有预览版验证合作伙伴，这些合作伙伴能够帮助确保所有开发的功能在提供边缘案例覆盖的生产环境中按要求执行）。遵守这一愿望可能并不总是公开广播，例如在验证合作伙伴是私人的情况下（如果您的需求不适合在此处公开发布，欢迎您直接联系@kat-y目前），但这在我们所有的 WinUI 2+ 控件版本中都是先例。
我相信使用微软自己的应用程序和壳牌作为例子更有可能引起认可，因为它表明内部需要某些不存在或不适合目的的东西，以至于他们不得不“推出自己的”——当然，像 Netflix、Facebook 等为 Windows 构建应用程序的大型野兽也会要求控制和其他位。

WinUI 不仅仅是要与 WPF、MFC、CommonControls、WinForms 等相提并论——（但这些遗留控件中更常用的没有现代等效项，应该认真研究）

Breadcrumb Bars 和 Expanders 被提议的事实表明 IMO 开始发生这种情况。并且每个控件或 API 添加都应该在理想的环境中进行评估和“合理化”，就像应用程序设计人员应该始终重新评估他们的 UI 和 UX 以确保它们适合目的一样。 - 在这种情况下，这似乎很明显，但我们仍应提供使用此模式和这些 API 的示例 - 以加强包含的理由。

mdtauk 于 2020-09-25

关于动画：如何使用 ItemsRepeater 提供的 ElementAnimator 方法？ ElementAnimator API 及其StartShowAnimation()和StartHideAnimation()看起来很有前景（“show”用于展开，“hide”用于折叠）。可以在具有默认动画实现的控件上提供 ElementAnimator 属性。如果不需要动画，则可以将该属性设置为 null，或者如果需要更细粒度的控制，则只能向 ElementAnimator 提供 Show 或 Hide 动画。

我对 ElementAnimator API 不太熟悉，似乎它可能无法在所有场景中使用，因为问题https://github.com/microsoft/microsoft-ui-xaml/issues/166存在。但是，如果仍然存在功能差距，也许可以将这些工作项（Expander 控件和 ElementAnimator 工作以使其可用于 Expander 控件）一起同步和设计。

Felix-Dev 于 2020-09-25

嗯，ElementAnimator 的想法真的很有趣。我在这里担心的是，这可能太复杂或过度设计了。毕竟，对于 ExpanderControl，我们需要提供一个自定义的 ElementAnimator，否则我们可以重用现有的主题动画。此外，ElementAnimator 提供的方法比扩展控件实际需要的要多，因此看起来有点不合适。

chingucoding 于 2020-09-25

我认为 ElementAnimator 用于处理出现在屏幕上的子元素或包含元素的偏移量是否正确？

根据显示为扩展器扩展的面板内的内容，这可能是矫枉过正。但是如果有办法以某种方式连接它，那么如果扩展面板包含元素 - 如果开发人员将某些内容附加到元素上，则可以驱动子动画。

所以扩展器不直接控制子元素转换，但如果开发人员愿意，可以启用它们

mdtauk 于 2020-09-25

是的，如果我们可以在这里创建可重复使用的动画，同时仍然为客户提供一些令人满意的定制选项，那么这将值得探索。例如，我们已经看到要求在项目展开/折叠时向 TreeView 控件添加动画 (https://github.com/microsoft/microsoft-ui-xaml/issues/208)。我想在这里可以建立一个案例，可以构建一组动画，使其对 Expander 和 TreeView 控件看起来都很棒。这将自动在不同控件之间具有一定程度的一致性。为用户创造视觉上的熟悉感，这也是一个令人信服的论点。

Felix-Dev 于 2020-09-25

👍2

我认为理想情况下，TreeView 和分层 NavigationView 应该在控件准备好时切换到 Expander 控件。毕竟，目前两个控件都需要处理由 ExpanderControl 解决的完全相同的问题。因此，共享动画不会对 TreeView 产生太大影响。

ElementAnimator 的问题（我的理解）是我们必须编写一个新动画。然而，我们已经可以为 Expander 使用内置动画。

根据显示为扩展器扩展的面板内的内容，这可能是矫枉过正。但是如果有办法以某种方式连接它，那么如果扩展面板包含元素 - 如果开发人员将某些内容附加到元素上，则可以驱动子动画。

我认为 ElementAnimator 的要点之一是允许向面板和集合添加动画，例如 ItemsRepeater。在 Expander 的情况下，情况并非如此，但 Expander 不是呈现项目集合的面板。

chingucoding 于 2020-09-25

在我的头顶上，通过缓动调整父面板的大小。然后包含对象的滑动和淡入淡出会感觉正确。

如果 Fluent Design 运动团队确定了适当的缓动，它会成为通用的操作系统范围的过渡，那就太好了。

mdtauk 于 2020-09-26

标记@stmoy，因为我们在谈论动画。

ranjeshj 于 2020-09-26

感谢@SavoySchuler加入并提供更多关于我们团队承诺的背景信息 - 我希望这有助于解释为什么我特别寻找需要 ExpandDirection 功能的应用程序示例！为了回应 Savoy 所说的，如果您的 Expander 需求无法在此处共享，请直接与我联系（如果您需要隐私，请通过 Twitter DM）。

@robloo感谢您的道歉，我完全理解您的意图，并且绝对希望 WinUI 控件能够以有意义和有效的方式进行范围和开发。我是团队的新手，非常感谢 WinUI 社区在讨论 Expander 的范围和实现时如此友好和热情！

关于这一点，我很高兴阅读这些关于动画的最新评论！

kat-y 于 2020-09-26

在阅读了与动画相关的评论后，听起来有 3 条可能的路线，按照工作量的增加顺序排列：

不包括设置动画- 正如@chingucoding指出的那样，当开发人员的场景不起作用或设置动画看起来不错时，这有好处。这里的风险可能是不一致，尽管在这条路线上似乎并没有太多的“空间”来处理不一致。

@mdtauk提议包括 ExpandTransition 和 CollapseTransition，

可以使用控件属性设置的方向 - 这可以允许开发人员为每个设置转换。

听起来比使用 ElementAnimator 的范围更小。这会给开发人员设置转换的完全灵活性吗？

在我的头顶上，通过缓动调整父面板的大小。然后包含对象的滑动和淡入淡出会感觉正确。

我理解其中的一部分，但是如果没有视觉效果😄，我很难想象。 “为父面板调整大小”是否意味着标题会改变大小？您能否详细说明“包含对象的幻灯片和淡入淡出”是什么意思？

@Felix-Dev 建议使用 ElementAnimator

ElementAnimator API 及其 StartShowAnimation() 和 StartHideAnimation() 看起来很有前景（“show”用于展开，“hide”用于折叠）。可以在具有默认动画实现的控件上提供 ElementAnimator 属性。如果不需要动画，则可以将该属性设置为 null，或者如果需要更细粒度的控制，则只能向 ElementAnimator 提供 Show 或 Hide 动画。

@chingucoding指出

然后我们需要提供一个自定义的 ElementAnimator，否则我们可以重用现有的主题动画。此外，ElementAnimator 提供的方法比扩展控件实际需要的要多，因此看起来有点不合适。

ElementAnimator 的要点之一是允许向面板和集合添加动画，例如 ItemsRepeater。在 Expander 的情况下，情况并非如此，但 Expander 不是呈现项目集合的面板。

TreeView 和分层 NavigationView 应该在控件准备好时切换到 Expander 控件。毕竟，目前两个控件都需要处理由 ExpanderControl 解决的完全相同的问题。因此，共享动画不会对 TreeView 产生太大影响。

我不确定 TreeView 和 hierachical NavigationView 是否具有与 Expander 完全相同的动画场景，当 Expander 将推送附近的任何内容（不一定是文本/按钮）以及当 Expander 相互“手风琴”时的场景以及可能具有关闭/打开的逻辑，具体取决于彼此的扩展。

鉴于 ElementAnimator 用于面板/集合动画，它是否对扩展器动画过度杀伤？

kat-y 于 2020-09-26

@mdtauk提议包括 ExpandTransition 和 CollapseTransition，
可以使用控件属性设置的方向 - 这可以允许开发人员为每个设置转换。
听起来比使用 ElementAnimator 的范围更小。这会给开发人员设置转换的完全灵活性吗？
在我的头顶上，通过缓动调整父面板的大小。然后包含对象的滑动和淡入淡出会感觉正确。
我理解其中的一部分，但是如果没有视觉效果😄，我很难想象。 “为父面板调整大小”是否意味着标题会改变大小？您能否详细说明“包含对象的幻灯片和淡入淡出”是什么意思？

expander_motion

抱歉耽搁了，我不得不制作这个小模型动画。
忽略实际的动画时间，它们只是为了说明。粉红色轮廓是扩展器标题 - 绿色边框用于扩展器窗格/内容等

mdtauk 于 2020-09-26

❤1

我不确定 TreeView 和 hierachical NavigationView 是否具有与 Expander 完全相同的动画场景，当 Expander 将推送附近的任何内容（不一定是文本/按钮）以及当 Expander 相互“手风琴”时的场景以及可能具有关闭/打开的逻辑，具体取决于彼此的扩展。

问题是，Expander 是否应该强制执行动画？ TreeView 和 Hierarchical NavigationView 肯定会受益于内置的扩展器控件，该控件负责扩展/折叠，并使我们能够在该区域获得更统一的体验。例如，TreeView 不为任何东西设置动画，而分层 NavigationView 为 V 形的旋转设置动画。

鉴于 ElementAnimator 用于面板/集合动画，它是否对扩展器动画过度杀伤？

可能是，积极支持 ElementAnimator（至少在预览中）的控件之一是 ItemsRepeater，它处理呈现数十个项目的大面板。另一方面，Expander 没有如此复杂的场景，而是一个要显示/隐藏的项目。

我注意到的另一件事是，没有办法自定义 V 形的放置位置（左/右或上/下）。也许这对作为自定义点很有用？ NavigationView 将 V 形符号放置在右侧，而 TreeView 将其放置在左侧。系统中现有的扩展器也是如此，设置应用程序的某些区域将其放置在左侧，而通知例如将它们放置在右侧。

chingucoding 于 2020-09-26

我注意到的另一件事是，没有办法自定义 V 形的放置位置（左/右或上/下）。也许这对作为自定义点很有用？ NavigationView 将 V 形符号放置在右侧，而 TreeView 将其放置在左侧。系统中现有的扩展器也是如此，设置应用程序的某些区域将其放置在左侧，而通知例如将它们放置在右侧。

我们可以引入类似ExpandGlyphPlacementMode的值，其中包含 TopLeft、TopRight、BottomCentered（可能还有更多（Left、Right、...））和额外的ExpandGlyphPlacementOffset属性开发人员可以用来修改如果需要，基本位置（由放置模式设置）。

除此之外，正如@mdtauk已经注意到的那样，用于自定义展开/折叠字形的 API（某些控件使用> ，其他控件使用v作为其展开字形）并控制字形。

Felix-Dev 于 2020-09-26

如果需要，我们可以引入像 ExpandGlyphPlacementMode 这样的值，如 TopLeft、TopRight、BottomCentered（可能还有更多（Left、Right、...））和一个额外的 ExpandGlyphPlacementOffset 属性开发人员可以用来修改基本位置（由放置模式设置） .

我不确定 TopLeft、TopRight 是否是这里的正确选择。也许像“开始”和“结束”之类的东西可能更适合这里？
在水平布局中，Start 将在左侧（在 RTL 语言中为右侧），在垂直打开模式中，这将是顶部。然后可以相应地定义“结束”。我在 TopLeft 中看到的问题是……它引入了很多复杂性（参见教学提示），但收益甚微。如果 ExpanderControl 向右打开，TopLeft 和 TopRight 将相同。我认为像底部居中这样的东西在很多空间中看起来有点尴尬并占用很多空间。

除此之外，正如@ mdtauk（分开提及不要向他的收件箱发送垃圾邮件）已经注意到的那样，用于自定义展开/折叠字形的 API（某些控件使用 >，其他控件使用 v 作为其展开字形）并控制字形。

问题是，如何实现这一目标。如果我们想以类似于分层 NavigationView 的方式为图标设置动画，我们将无法允许 API 用于交换展开和折叠的字形，这些字形可用于切换到 v 或 > 以进行折叠。也许我们可以有一个 API 指示折叠的字形方向？

chingucoding 于 2020-09-26

动画的想法似乎很不错。需要可以像列表视图等一样打开/关闭它们。标题和字形也需要自动切换 RTL 语言的边。然而，所有的字形定制似乎都在过度设计这个问题。不可能创建一种适用于所有已识别的具有自定义实现的情况的样式。相反，就像 CheckBox 和其他控件一样，默认设计应该是我们能做的最好的，但默认样式应该足够简单以重新模板。我不知道为什么每个人都对重新模板化控件如此不利，它非常是解决方案，实际上是外观较少控件的强大力量。添加更多属性也增加了我听说过的维护负担。

编辑：为一些事情定义资源以改进轻量级样式也可能是一个合理的选择。

robloo 于 2020-09-26

我不确定 TopLeft、TopRight 是否是这里的正确选择。也许像“开始”和“结束”之类的东西可能更适合这里？
在水平布局中，Start 将在左侧（在 RTL 语言中为右侧），在垂直打开模式中，这将是顶部。然后可以相应地定义“结束”。我在 TopLeft 中看到的问题是……它引入了很多复杂性（参见教学提示），但收益甚微。

@chingucoding NavigationView 使用垂直打开模式（因为 NavigationViewItem 垂直扩展），对吗？那么我如何能够在标题的左侧或右侧设置字形？我正在阅读您的评论，因为“开始”将是顶部，“结束”可能是标题的底部。但是我没有看到指定字形是否可以放在左上角或右上角的方法。对于我们经常看到的东西，我不应该使用像ExpandGlyphPlacementOffset这样的 API。

我认为像底部居中这样的东西在很多空间中看起来有点尴尬并占用很多空间。

我确信我在网络、应用程序等上看到过这样的例子……这就是我想出这个想法的原因。虽然最好可以在这里发布示例，看看这是否值得直接支持，或者我们是否会将其留给重新模板。

然而，所有的字形定制似乎都在过度设计这个问题。不可能创建一种适用于所有已识别的具有自定义实现的情况的样式。相反，就像 CheckBox 和其他控件一样，默认设计应该是我们能做的最好的，但默认样式应该足够简单以重新模板。我不知道为什么每个人都对重新模板化控件如此不利，它非常是解决方案，实际上是外观较少控件的强大力量。

@robloo我不反对重新模板化，但查看到目前为止发布的示例，一些开发人员使用“>”表示扩展字形，而其他人在垂直扩展时使用“v”作为扩展字形。与字形的位置相同。 Expander 控件应该使开发人员可以很容易地根据自己的意愿设置字形。重新模板总是伴随着权衡，主要是您不会自动受益于未来对 WinUI 中的控件模板所做的更改。相反，现在开发人员将承担维护他们定制模板的责任。

我们应该确定常见的自定义场景，并努力使它们尽可能被 Expander 控件访问。

以自定义字形为例（可在Fluent UI 网站上找到）：
fluent-ui-website-expand

字形符号定制必然意味着必须仔细考虑任何内置字形动画。同样有趣的是：客户更需要什么 - 能够根据他们的喜好轻松自定义字形或为字形提供内置动画（如在 NavigationView 中看到的）。我个人认为前者会更重要，但我没有任何硬数据来支持这一点。

另一个 Expander 控件是Telerik Expander 控件，它公开了我们在此处讨论的一些自定义 API（例如更改字形或字形符号位置的能力），我们也可以使用这些 API 来获得一些灵感。

Felix-Dev 于 2020-09-26

👀1 👍1

扩展字形
折叠字形
开发人员可以在他们认为合适的情况下覆盖

GlyphPlacement.Start .End .Above .Below
也许？

也许还使用内容对齐来处理填充宽度的标题，或者将字形和文本组合在一起

对于通知中心，与扩展器在同一行上有一个 clear all，那么如何处理呢？某种将扩展面板与扩展标题分开的方法？

mdtauk 于 2020-09-26

👍1

@chingucoding NavigationView 使用垂直打开模式（因为 NavigationViewItem 垂直扩展），对吗？那么我如何能够在标题的左侧或右侧设置字形？我正在阅读您的评论，因为“开始”将是顶部，“结束”可能是标题的底部。但是我没有看到指定字形是否可以放在左上角或右上角的方法。对于我们经常看到的东西，我不应该使用像 ExpandGlyphPlacementOffset 这样的 API。

这对我来说措辞不佳对于“水平打开模式”，我的意思是水平尺寸是固定的，因此内容以水平方式呈现。垂直模式也一样。还有什么是左上角和左下角？我会假设图标居中，大多数时候标题不应该/甚至不占用扩展区域中的太多空间，并且左上角和左下角最终几乎相同。

所以澄清一下，如果扩展器在垂直方向上扩展，则start为左（RTL 中的右侧），而end为右（RTL 中的左侧）；在水平扩展中， start为顶部， end为底部。类似于 CSS flex-start 和 flex-end。

Visual Studio 使用居中图标，但扩展按钮区域会拉伸整个控件：

关闭：

扩展：

GlyphPlacement.Start .End .Above .Below
也许？

这听起来是个很酷的主意！上面和下面会是什么样子？类似于 Visual Studio 的功能？

扩展字形
折叠字形
开发人员可以在他们认为合适的情况下覆盖

这将是一种方法，但是这不允许我们为图标设置动画（例如旋转）。然而，我认为优先考虑完全切换图标的可能性比在这里有动画更有意义。

也许还使用内容对齐来处理填充宽度的标题，或者将字形和文本组合在一起

100%

对于通知中心，与扩展器在同一行上有一个 clear all，那么如何处理呢？某种将扩展面板与扩展标题分开的方法？

我担心这个特定场景可能太复杂而无法简单地使用扩展器控件来实现。按钮的位置非常独特，但更重要的是，标题和展开图标不在同一行上，这对于将标题和图标放在一起的标准扩展器控件来说很难做到。这里有一个例子供参考：

chingucoding 于 2020-09-26

👍1

我并不反对重新模板化，但查看到目前为止发布的示例，一些开发人员使用“>”表示扩展字形，而其他人在垂直扩展时使用“v”作为扩展字形。与字形的位置相同。 Expander 控件应该使开发人员可以很容易地根据自己的意愿设置字形。

@Felix-Dev 这是流畅设计系统中应该标准化的事情之一。用户拥有一致的外观和感觉很重要。这应该改变的唯一时间是如果应用程序必须这样做以满足他们自己的设计语言，或者有一个我们没有想到的新用例。在这种情况下——重新模板。

编辑：我在第一次阅读时错过了您的 Telerik 示例。仍然认为我们增加了太多的复杂性并允许太多的设计选项：(1) 不容易被用户识别 (2) 会暴露很多历史上不需要的复杂性。当然，这里有一条细线。我们希望公开足够的功能，用户不需要重新模板，但我们也不希望公开太多的功能，以至于设计语言变得混乱。

WPF，或我能想到的任何其他扩展器控件，从来没有公开过一个属性来控制它。它确实是视图的重要组成部分，应该只保留在 XAML 中。视图模型（即在这种情况下控件的 DP）不应该知道关于干净无外观控件中的此类样式选择的任何信息。

robloo 于 2020-09-26

👍1

WPF，或我能想到的任何其他扩展器控件，从来没有公开过一个属性来控制它。它确实是视图的重要组成部分，应该只保留在 XAML 中。视图模型（即在这种情况下控件的 DP）不应该知道关于干净无外观控件中的此类样式选择的任何信息。

@robloo公开字形自定义的一种可能性是通过轻量级样式。这些资源，就像 DP 一样，应该被视为控件的公共 API 表面的一部分，但它们更接近控件模板（控件的外观）。因此，我们可以公开诸如ExpanderExpandGlyph和ExpanderCollapseGlyph （例如 NavigationView 具有NavigationViewItemExpandedGlyph资源）。

以这种方式公开字形符号自定义也可以理解为建议提供 MDL2 字体中存在的字体元素，从而使用 Fluent Design 批准的图标。看看 MDL2 字体，它似乎具有我在网络示例中看到的所有常用展开/折叠字形图标（不同的 V 形、+/-、圆圈中的 +/-，...）。虽然开发人员可能仍然可以覆盖 FontFamily（由SymbolThemeFontFamily资源提供），但我们只会直接将ExpanderExpandGlyph ,... 资源公开为控件的公共资源，因此开发人员可能会首先如果他们想要自定义图标，请查看 MDL2 字体系列（因为这将是扩展器用于字形的默认字体系列）。

对于那些感兴趣的人，至少还有一个尚未解决的问题，即当在给定的上下文中只有一组固定的图标有意义时，我们作为 WinUI 想要提供简单的自定义字形选项（NumberBox 旋转按钮字形自定义）： https :

Felix-Dev 于 2020-09-26

@Felix-Dev 您对轻量级造型的推荐对我来说最有意义。这就是我所说的“编辑：为一些事情定义资源以改进轻量级样式可能也是一个合理的选择”。上面的一些评论。

robloo 于 2020-09-26

问题是开发人员有多大可能不提供字形而是提供某种形式的其他图标，例如 BitmapIcon 或某种形式的自定义 FontIcon。如果非字形图标实际上不是许多开发人员会使用的自定义点，我认为使用字形（也许是符号字体）的轻量级样式资源是最好的选择，正如@robloo和@Felix-提出的那样-开发。

chingucoding 于 2020-09-26

如果字形或自定义字体不够用，重新模板化始终是一种选择。

带有 Segoe MDL2 或 FluentIcons 的 Font Glyphs 最有可能并且应该是默认设置；
根本没有字形也很常见；
然后是路径，SVG 不太可能但很有可能；
然后 PNG 或完整位图不太可能，但对于开发人员来说可能是可能的选择。

无论使用什么方法，都应该专注于前两个场景，但始终允许为第三个场景重新模板化。

然后就有可能为字形设置一个 ContentPresenter，并允许在其上放置任何内容。但不确定它如何与 VisualStates 一起使用以从折叠状态移动到展开状态。

至于动画图标 - 也许可以在这里使用 Lottie 控件？

另一个想法，就像您将 RadioButton 和 RadioButtons 作为一组一样......

一组扩展器应该制作手风琴控件吗？这将允许一次只能扩展一个扩展器的行为？

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

mdtauk 于 2020-09-26

👍2

如果字形或自定义字体不够用，重新模板化始终是一种选择。
带有 Segoe MDL2 或 FluentIcons 的 Font Glyphs 最有可能并且应该是默认设置；
根本没有字形也很常见；
然后是路径，SVG 不太可能但很有可能；
然后 PNG 或完整位图不太可能，但对于开发人员来说可能是可能的选择。
无论使用什么方法，都应该专注于前两个场景，但始终允许为第三个场景重新模板化。

重新模板将始终是一种选择，但是当然，如果控件发生（重大）更改，这可能会随着时间的推移而中断。因此，拥有轻量级资源可能是最好的选择，因为切换字形（和图标字体）是最常见的场景。

然后就有可能为字形设置一个 ContentPresenter，并允许在其上放置任何内容。但不确定它如何与 VisualStates 一起使用以从折叠状态移动到展开状态。

使用 ContentPresenter 对折叠/展开没有影响，它只是一个像其他元素一样的元素。

至于动画图标 - 也许可以在这里使用 Lottie 控件？

问题是你想要什么样的动画。简单的旋转可以（并且已经）在没有 lottie 的情况下完成。

另一个想法，就像您将 RadioButton 和 RadioButtons 作为一组一样......
一组扩展器应该制作手风琴控件吗？这将允许一次只能扩展一个扩展器的行为？

也许那可以是单独的控制？虽然在某些情况下它们可能是相互排斥的，但我认为在很多情况下，是否有多个开放并不重要。

chingucoding 于 2020-09-26

然后就有可能为字形设置一个 ContentPresenter，并允许在其上放置任何内容。但不确定它如何与 VisualStates 一起使用以从折叠状态移动到展开状态。
使用 ContentPresenter 对折叠/展开没有影响，它只是一个像其他元素一样的元素。
但是，它是两个状态都使用的 ContentPresenter，还是每个状态一个被换出/切换的状态？

至于动画图标 - 也许可以在这里使用 Lottie 控件？
问题是你想要什么样的动画。简单的旋转可以（并且已经）在没有 lottie 的情况下完成。
当字形是方向箭头/人字形时，旋转是有意义的 - 但是如果它的灯泡为某种提示或提示场景打开和关闭怎么办？有一个使用 Lottie #2802 的通用动画图标控件的建议 - 这种情况是否需要这样做，即使其默认/最常见的用途可能是简单的图标旋转？

另一个想法，就像您将 RadioButton 和 RadioButtons 作为一组一样......
一组扩展器应该制作手风琴控件吗？这将允许一次只能扩展一个扩展器的行为？
也许那可以是单独的控制？虽然在某些情况下它们可能是相互排斥的，但我认为在很多情况下，是否有多个开放并不重要。
我提到它只是因为 Fast Design 包含一个手风琴控件，它本质上与一堆扩展器相同 - 只是有一个多行为和单行为 API 来改变它们的协同工作方式。制作扩展器控件后，手风琴将是合乎逻辑的下一步，并且应该相对容易实现，使用方向属性覆盖各个方向。

mdtauk 于 2020-09-26

然后就有可能为字形设置一个 ContentPresenter，并允许在其上放置任何内容。但不确定它如何与 VisualStates 一起使用以从折叠状态移动到展开状态。
使用 ContentPresenter 对折叠/展开没有影响，它只是一个像其他元素一样的元素。
但是，它是两个状态都使用的 ContentPresenter，还是每个状态一个被换出/切换的状态？

这两种选择都有道理。我认为切换 ContentPresenter 的内容比换出 ContentPresenter 或拥有两个并隐藏/显示一个更好。

至于动画图标 - 也许可以在这里使用 Lottie 控件？
问题是你想要什么样的动画。简单的旋转可以（并且已经）在没有 lottie 的情况下完成。
当字形是方向箭头/人字形时，旋转是有意义的 - 但是如果它的灯泡为某种提示或提示场景打开和关闭怎么办？有一个使用 Lottie #2802 的通用动画图标控件的建议 - 这种情况是否需要这样做，即使其默认/最常见的用途可能是简单的图标旋转？

旋转动画将是一种动画方式，并且很容易实现。拥有一个动画成不同的图标会大不相同。这也可能会使 API 变得更加复杂（你如何支持这种行为？2 个动画和 2 个图标？或者你停止的一个动画？）

另一个想法，就像您将 RadioButton 和 RadioButtons 作为一组一样......
一组扩展器应该制作手风琴控件吗？这将允许一次只能扩展一个扩展器的行为？
也许那可以是单独的控制？虽然在某些情况下它们可能是相互排斥的，但我认为在很多情况下，是否有多个开放并不重要。
我提到它只是因为 Fast Design 包含一个手风琴控件，它本质上与一堆扩展器相同 - 只是有一个多行为和单行为 API 来改变它们的协同工作方式。制作扩展器控件后，手风琴将是合乎逻辑的下一步，并且应该相对容易实现，使用方向属性覆盖各个方向。

对，我明白了。是的，手风琴控制在扩展器控制之后绝对是一个好主意，并且可能很容易实现！

chingucoding 于 2020-09-26

当字形是方向箭头/人字形时，旋转是有意义的 - 但是如果它的灯泡为某种提示或提示场景打开和关闭怎么办？有一个使用 Lottie #2802 的通用动画图标控件的建议 - 这种情况是否需要这样做，即使其默认/最常见的用途可能是简单的图标旋转？
旋转动画将是一种动画方式，并且很容易实现。拥有一个动画成不同的图标会大不相同。这也可能会使 API 变得更加复杂（你如何支持这种行为？2 个动画和 2 个图标？或者你停止的一个动画？）

这是一个大问题，老实说，这是动画图标提案的问题。

如果字形/图标始终是一个箭头，则为它设置动画就可以了。但它有点锁定，除非您有一种简单的方法来删除或更改动画本身。

制作旋转 Lottie 动画会保留默认动画，这意味着要实现更多的工作，但在允许更改图标和动画（如果需要）方面更加灵活。

最简单的选择是不为字形设置动画。但是您添加的越多，使其易于覆盖或更改变得越重要。

mdtauk 于 2020-09-26

浏览网页，我看到很多用于典型 Expander UI 示例中的展开/折叠字形的静态图标。但是，在 Windows 上，我们也有此控件的潜在客户，他们似乎更喜欢动画（例如，请参见 shell 中的 NavigationView 和 toast 通知）。 Motion是 Fluent Design 的基石之一，因此在这里为那些想要动画字形而不需要重新模板化控件的客户保持选项开放可能是有意义的。

理想情况下，如果 MS 的不同团队想要使用带有动画字形（即动画箭头字形）的扩展器，该控件将提供一个内置选项，因此我们最终会在默认情况下获得一致的体验。如果每个团队自己负责动画，我们最终可能会看到不同的动画持续时间，不同的动画方向（即顺时针或逆时针），...如果我没记错的话，通知中的字形动画动作中心与 NavigationView 中字形的动画不同。如果可能，应该避免这种情况。

Felix-Dev 于 2020-09-26

动画令人愉悦，有助于使 UI 感觉流畅。在旋转 Storyboard 中进行硬编码是添加动画的简单方法，但如果该动画难以删除或更改 - 也许使用 AnimatedIcon 控件将是一种实现自定义的灵活方式的好方法。

我并不是说一种方式比另一种方式更好 - 只是在这里引起人们的注意，因为它正在为图标设置动画，这就是新控件的 Raison Detra。

如果已经承认字形应该是可定制的 - 旋转动画可能并不总是合适的。

mdtauk 于 2020-09-26

什么动画，什么不动画是一个非常困难的问题。正如 Martin 已经提到的，旋转动画并不总是有意义的。动画图标仍然有很多悬而未决的问题。

我认为最好为 v1 绘制字形/图标动画，特别是因为它不是很常见。需要重新考虑的一件事是，我们是否删除分层 NavigationView 上的现有动画以获得统一的体验。目前 TreeView 和 h-NavigationView 之间已经存在不一致，以动画/不动画图标的切换。

chingucoding 于 2020-09-26

确切地。我的最后一段并不是要阻止这里的任何探索，而是再次写下我们在这里面临的挑战之一是在“最终”之外提供足够的定制选项 - 重新模板 - 以满足普通客户想要，但仍要确保该控件将有助于为 Windows 带来更多的一致性，而不是潜在的更少。

正如我们已经看到的，这里可能没有完美的解决方案，因为想要同时提供图标自定义和动画支持（可能除了内置动画以保持一致性）很容易相互冲突。

让潜在客户（如 Windows Shell）加入这里以了解他们如何查看动画可能会有所帮助。据说 10X 将重点放在动画上，Windows Shell 和内置 Windows 应用程序可能是这里的“客户”。如果一个动画字形被认为是整个 UX 的一个重要部分，Windows 团队正在为 10X 努力，那么现在可能不需要“踢”这个挑战，而是在 V1 中提供动画支持。

Felix-Dev 于 2020-09-26

👍2

我希望看到一种一致的动画图标方法，现在似乎是动画图标提案。

我不会从 NavigationView 中删除任何动画，因为它是一个完全独立的 WinUI 新范式 - 似乎意图是为所有这些类似的控件添加动画 - 所以也许一旦准备好，控件就可以添加到导航视图

mdtauk 于 2020-09-26

👍1

听起来ElementAnimator对于动画扩展器来说太多了，而ExpandTransition和CollapseTransition就足够了。

@mdtauk感谢您制作模型动画！我明白你对展开和折叠动画的意思。

我相信手风琴行为将通过列表级逻辑（而不是新的手风琴控件）与 IsExpanded 实现，供开发人员将其定制为不同的场景（例如：一些扩展器彼此关闭，而其他扩展器可以同时展开）。

@Felix-Dev - 我已将 Telerik Expander 添加到提案中，感谢分享！

听起来有以下方向的可定制性的愿望：

字形外观：轻量级样式似乎是切换字形和图标字体的首选途径，通过ExpanderExpandGlyph和ExpanderCollapseGlyph 。 v1 Expander 中是否需要这种级别的自定义？

@Felix-Dev 虽然开发人员可能仍然可以覆盖 FontFamily（由 SymbolThemeFontFamily 资源提供），但我们只会直接公开ExpanderExpandGlyph ... 因此，如果开发人员愿意，他们可能会首先查看 MDL2 字体系列自定义图标（因为这将是扩展器用于字形的默认字体系列）。

字形动画：包括在扩展时更改为不同的字形 - 部分使用 AnimatedIcon #2802 解决。 听起来 v1 Expander 不需要这种级别的自定义。
@chingucoding声明，我倾向于同意：

我认为最好为 v1 绘制字形/图标动画，特别是因为它不是很常见。

字形位置： v1 Expander 中是否需要这种级别的自定义？ 如果 v1 包含 ExpandDirection和更改字形位置的选项，这会更加复杂。 @Felix-Dev 描述

如果需要，开发人员可以使用像 ExpandGlyphPlacementMode 之类的值，如 TopLeft、TopRight、BottomCentered（可能还有更多（Left、Right、...））和一个额外的 ExpandGlyphPlacementOffset 属性来修改基本位置（由放置模式设置）。

希望我已经正确理解了本周末的精彩讨论 - 如果我在某处弄错了，请告诉我！非常感谢大家对此的深刻见解。 😄

kat-y 于 2020-09-29

👍1

字形外观
字形位置

我认为这些是包含在 V1 中的最简单和最重要的自定义。

我还会添加一种隐藏字形的方法

字形动画
状态转换

如果需要优先排序并且核心行为和功能花费的时间太长，这些可以被赋予较低的优先级。

mdtauk 于 2020-09-29

感谢@mdtauk 的优先顺序！

我添加了一个新的开放问题：

Expander 应该如何与 InfoBar 配合使用？向 InfoBar 添加扩展功能？将 InfoBar 作为扩展器的内容？相反？

kat-y 于 2020-09-30

我想它会取代内容，但我认为设计信息栏的人应该提供可折叠栏的设计规范，扩展器设计人员可以查看。

这是一个需要进行的对话

mdtauk 于 2020-09-30

这里有_一堆_很棒的谈话！关于动画的话题...

听起来 ElementAnimator 对于动画 Expander 来说太多了，而 ExpandTransition 和 CollapseTransition 就足够了。

同意 ElementAnimator 对于动画扩展器来说太多了。如果所有东西都在 ItemsRepeater 中，它可能会工作，但 ElementAnimator 还不能在 ItemsRepeater 之外工作，所以我们需要弄清楚这一点。

我喜欢理论上有 ExpandTransition 和 CollapseTransition 的想法，但我们收到了大量反馈，说 Transition API 在理论上很好，但在实践中不太好，因为它们不可定制，它们通常与它们被使用，我认为它们不能在 WinUI 2.x 系列中构建，因为它们依赖于操作系统挂钩。由于这些特定的转换不存在，我更愿意探索其他选项而不是添加到我们的 ThemeTransition API 集合中。

最重要的是，如今作为平台的 Xaml 还没有很好地支持“布局动画”的一般区域，其中内容因新 UI 元素进入/增长/缩小/离开页面而移动。解决这个问题也需要 WinUI 3，但不在近期的路线图上。

特别是对于 Expander，我认为正确的行动方案最终可能是：
1) 在 Expander 代码中硬编码增长/收缩动画（并考虑包含一个 API 来关闭它——尽管我个人认为没有必要）
2) 向应用程序开发人员提供有关如何为扩展器周围的内容制作动画的指导，以便扩展器下方的内容向下滑动而不是“向下跳”

我不认为（2）一般不能在没有“布局动画”的情况下解决，但可能可以在扩展器下方的内容上使用 RepositionThemeAnimation 来解决。

stmoy 于 2020-09-30

👍3

@stmoy如果我们想使用现有的，我们可以将 PopInThemeAnimation 用于 (1)。

ranjeshj 于 2020-10-01

该提案已被批准用于规范编写。

作为与 WinUI 团队讨论的一部分，我们确定可以将 Expander 限定为支持 ExpandDirection 在 V1 中进行向上/向下扩展。这涵盖了我们在 Expander 中看到的场景，并为将来可能添加左/右扩展奠定了基础。

请继续在这里讨论，一旦规范和相关 PR 可用，将进行更详细的讨论。特别想听听您对这个悬而未决的问题的看法：

Expander 应该如何与 InfoBar 配合使用？向 InfoBar 添加扩展功能？将 InfoBar 作为扩展器的内容？相反？

kat-y 于 2020-10-02

对于 InfoBar，我想我需要打开一个单独的提案来深入了解它的具体需求以及它如何利用这个 Expander 控件。以下是我的一些初步想法：

InfoBar 需要自定义扩展器控件的标题和内容/窗格。信息栏在折叠时应在标题中显示“截断”消息，在打开时在展开的内容/窗格中显示完整消息。
InfoBar 不允许截断，如果需要，开发人员应该通过“shouldTruncate”属性选择当前的包装行为。
如果内容不再适合单行并且 shouldTruncate 设置为 true，则 InfoBar 可以/应该“成为”扩展器。实现这一点并了解何时确切地添加扩展行为是棘手的地方😊 MessageBar 通过其 isMultiline 属性缓解了这一点，但需要进一步思考这个领域。

我认为我们目前还可以研究 WinUI 中可能受益于这种扩展器行为的其他控件。

一些用于截断 InfoBar 的初始补偿：
Expand/collapse

对于实现，我最初的想法是 InfoBar 应该从 Expander 派生，而不是嵌套在 Expander 的内容中。想法？

gabbybilka 于 2020-10-02

我认为我们目前还可以研究 WinUI 中可能受益于这种扩展器行为的其他控件。
一些用于截断 InfoBar 的初始补偿：
我认为扩展器可能需要能够将雪佛龙按钮与被扩展的内容分开。

通知执行此操作

它还允许 InformationBar 控件集成它的扩展器。

如果你把它分开，它会成为一种行为/属性吗？因此，如果您为此属性指定 UI 元素或按钮，则扩展器标题不会显示它的按钮？

对于实现，我最初的想法是 InfoBar 应该从 Expander 派生，而不是嵌套在 Expander 的内容中。想法？
如果 Expander 无法将 Content 和 Header 与 Toggle/Disclose Button 分开，那么 InformationBar 将需要更多的工作来实现。

Expander 控件应尽可能灵活，专门用于集成到各种其他控件中，以及在 Windows Shell 中使用

mdtauk 于 2020-10-02

👍2

我已将初始信息添加到Expander 规范并打开了 PR - 请随时在那里继续规范讨论！这是规范 repo 上的 PR 100 😄

kat-y 于 2020-10-29

🎉2 👍1

此页面是否有帮助？

0 / 5 - 0 等级

Microsoft-ui-xaml: 建议：向 WinUI 控件集添加一个扩展器控件。

提案：WinUI 扩展器控件

概括

基本原理

范围

重要笔记

提议的API

其他地方的扩展器控件

扩展器场景示例

开放问题

最有用的评论

所有82条评论

相关问题