这应该是一个比 Fabric 使用的按钮等上的圆角更广泛的项目。

• 纽扣
• 微调器/ProgressRing
• 不确定的进度条
• 复选框和单选按钮
• 组合框和文本字段
  等等。

Xbox 将继续有不同的要求，但随着一组新的 Xbox 游戏机的推出，也许微软设计团队可以共同努力，及时调整 WinUI 3.0 和 Xbox Next 的所有内容。

Fabric 目前似乎得到了很多关注，它的跨平台和 PWA 用例是什么。 所以也许 Fabric 成为蓝图——至少对于 Compact Density，并从 2px 移动到 4px 作为最小度量——然后你推断触摸可供性并填写缺失的控制状态。

ThemeShadows需要考虑圆角。 亚克力表面可能应该包括内边界和外边界，以确保它们从背景中显得更高。

@mdtauk正如第 4 条要求所述，我们计划通过 Xbox 合理化此更改。 也就是说，此特定功能仅限于圆角，以确保工作范围清晰。 请随时为您提出的其他设计建议提出单独的请求。

顺便说一句，我不太明白您对亚克力表面内外边框的反馈？ 它是您提到的 Xbox 设计，因为我们目前不使用您指定的两个边框。

@chigy当然对于 Xbox，那是它自己的事情。 但关键是圆角需要处理所有相关控件。

我不知道 Fluent 团队可能同意或不同意的内部 figma 设计规范 - 但它需要的不仅仅是 Buttons。

Fluent Web 的圆角使用 2px 圆角半径，但 Fluent XAML 倾向于使用 4px 作为基本度量。 然后是 CompactDensity 模板，它可能使用与 FluentWeb 相同的指标？

我制作了 Xbox Fluent 和 Fabric 共享控件的比较图像，以及它们的外观有何不同。 因此，在查看这些控件模板时，需要做的不仅仅是圆角。

忽略 Xbox 的东西

@mdtauk ，为了给你一个印象，这只是关于按钮，我一定没有明确说明......请放心，它不是。 请参阅要求编号 1 及其子项。 这与所有控件有关。

我还没有机会发布设计文件，但我们计划的拐角半径确实是 2px（覆盖 UI 为 4px）。 我实际上与 Fabric 团队（即 Fluent Web）密切合作，我们正在一起评估这些变化。 也就是说，让它们完全匹配并不是我们的目标，但是当用户并排看到它们时，我们确实需要保持连贯性并感觉自己是家庭的一部分。 参见要求 4。

因此，在查看这些控件模板时，需要做的不仅仅是圆角。

它正在开发中，但我们正在逐一/逐案进行。 我们谨慎地做出有意义的改变，不要为了改变而改变事物。

@chigy谢谢，谢谢，谢谢！

如果您能够与社区分享这些设计，我会很高兴，这不仅是因为我们都希望看到控件和 UI 的发展方向，而且在实施更改时，我们可以指出不一致之处，并确保未来控制建议会有宾至如归的感觉！

Fabric Web 和 Fluent Web 似乎都处于领先地位，XAML 以及 WPF 和 WinForms/Visual Styles 应该紧随其后！

@chigy @mdtauk在此处查看我的回复。 仅仅看到 UI 概念“了解 Fluent Design 的发展方向”或指出我认为的不一致是不够的。 我在上面的链接问题中进一步阐述了这一点，但长话短说，我希望用户和 Fluent Design (FD) 团队之间积极地来回交流，即使涉及到设计提案。

@mdtauk我一直看到您提出更新 WPF/WinForms 控件以匹配 FD 的观点。 我反对给你将有WinUI如果你想出货与Win10本机的外观和感觉，并在MS队（一个或多个）非UWP应用只有这些都对制造UWP / WinUI定最好的花有限的资源Windows 演示平台。
所以， @ YuliKl @chigy @pag3 ：你能对此发表评论吗？ 默认的 WinForms/WPF 控件是否会更新为具有新的 FD 外观，还是 WinUI 控件将成为我所理解的最新和最伟大设计功能的途径？

我在 Numberbox 提案中发布了这张图片，但它可能与正在更新的 TextBox 控件有一些相关性。

BorderThickness ， FocusReveal聚焦状态，边界禁用状态。

“旋转按钮”样式可以应用于搜索按钮、密码显示按钮、明文按钮。

聚焦状态下边框/控制元素周围的阴影对我来说太强烈了。 为什么他们甚至需要阴影？ 当前版本（只是边框颜色变化）完全没问题。 阴影可能表明控件（元素）被提升到前景，这在 3D 环境中可能有意义，但对于经典桌面环境肯定不需要，并且可以争辩说，会增加一些干扰。

聚焦状态下边框/控制元素周围的阴影对我来说太强烈了。 为什么他们甚至需要阴影？ 当前版本（只是边框颜色变化）完全没问题。 阴影可能表明控件（元素）被提升到前景，这在 3D 环境中可能有意义，但对于经典桌面环境肯定不需要，并且可以争辩说，会增加一些干扰。

聚焦时控件周围的 Glow 是 FocusVisualKind.Reveal，由系统控制。 我不得不近似它的外观，因为我没有完全匹配不透明度和大小的指标。

以我使用它作为指示，我认为发光会使焦点更清晰，而不仅仅是改变边框颜色。

@mdtauk分别，你能不能把这个问题的谈话限制在圆角？ 我真的很想得到关于圆角的反馈，我担心对于那些可能只是为了这个目的来到这里的人来说，这次谈话会变得太混乱。

也就是说，在我看来，您所展示的就像是 Reveal Focus 行为。 我们研究了使焦点状态更强大并进行了一些用户研究，我们确认它们太强了，正如@Felix-Dev 在他的回应中提到的那样。
https://docs.microsoft.com/en-us/windows/uwp/design/style/reveal-focus

@chigy如果研究表明 Reveal Focus on text control focus 太多，我会接受。 我的示例确实包括圆角，所有这些都对边框进行了一些细微的更改，这符合提案的“...与网络和应用程序风格方向一致”部分。

@mdtauk和 @Felix-Dev ，我现在已经上传了所提议更改的视觉合成。

@chigy是否有可能重新考虑文本控件、组合框、复选框和单选控件的边框粗细。

Fabric Web 选择了 1 epx 厚度，我认为这使控件更加优雅，尤其是新的圆角。 目前他们觉得有点笨重。

紧凑模式下的文本框将受益匪浅。 但是当聚焦时，边框可以更厚

默认情况下，按钮使用不透明度为 20% 的背景填充。 在 Fabric Web 中，它们使用 1 epx 边框并且没有填充。 我认为这可能是一个更好的解决方案，并且还可以让文本框控件中的按钮很好地适应。

带有旋转按钮的 NumberBox 提案说明了按钮和文本字段的这种组合

也许如果团队不愿意将此样式设为新的默认样式，则可以为其包含样式/模板。

为了帮助查看由@chigy创建的视觉这个

关于圆角话题的轶事和不专业的反馈。
同时使用 Edge 和 CrEdge，我对 CrEdge 的第一个问题是整个 UI 的圆润感。 它是可怕的，积极地让我不喜欢使用它。 如果您为事物添加圆角，请为我们这些不想要看起来像用安全剪刀剪掉的孩子的东西添加切换锋利边缘的功能。

为了帮助查看由@chigy创建的视觉

@mrlacey ，非常感谢！！

@chigy是否有可能重新考虑文本控件、组合框、复选框和单选控件的边框粗细。

@mdtauk ，我们现在正在整理一些关于如何分类工作的视觉变化（我们希望它们可以单独寻址但连贯），其中之一就是你要问的，敬请期待。

关于圆角话题的轶事和不专业的反馈。
同时使用 Edge 和 CrEdge，我对 CrEdge 的第一个问题是整个 UI 的圆润感。 它是可怕的，积极地让我不喜欢使用它。 如果您为事物添加圆角，请为我们这些不想要看起来像用安全剪刀剪掉的孩子的东西添加切换锋利边缘的功能。

@Zucce05 ，是的 #684 将通过能够轻松切换回非圆角来解决您的问题。 也就是说，正如您在我们的补偿方案中所看到的，为了保持专业外观，边角并不是那么圆。

@chigy
我也不喜欢圆角设计的变化，所以我很高兴听到有一个选项可以轻松切换回来。 我不认为会有系统范围的圆角半径选项，会有吗（类似于设置系统范围的强调色）？

关于边框粗细的话题：我喜欢现在的按钮粗细，边框粗细对我来说在当前的 UI 环境中也很独特。 我很少（如果有的话）在 UI 中看到这种与 UWP UI 不同的边框粗细，因此它始终充当一个很好的区分符：“我目前正在查看的 UI 是 UWP。” 我希望看到厚度保持现状。

查看您发布的视觉合成，我发现边框厚度看起来很奇怪的唯一区域是带有复选框的 TreeView。 在这种情况下，复选框的厚度对我来说看起来太厚了。 这可能是一种误导性的视觉效果，但在我看来，独立复选框的边框厚度更薄，对他们来说看起来不错。 因此，我会减少 TreeView 中 checkbixes 的边框厚度，以匹配正常复选框边框厚度的视觉效果。

@mdtauk ，我们现在正在整理一些关于如何分类工作的视觉变化（我们希望它们可以单独寻址但连贯），其中之一就是你要问的，敬请期待。

@chigy我做了一些视觉模型来说明我提到的变化，并使控件更接近 Fabric Web 的控件 - 但仍然使用 Fluent 控件指标。

添加到悬停的阴影由 Microsoft Store webviews 上的 Fluent Web 控件使用，但默认情况下可以省略，或者可以通过可以删除的主题动画来实现 Z 平移。

看看上面@mdtauk 的一些设计提案，我显然更喜欢按钮的当前边框厚度等......

我还想指出，我不太喜欢将 Windows Fluent Design 建立在 Fabric Web 或其他 Web UI 组件上——我希望 Windows 有一个独特的外观，与 Web 上正在发生的事情截然不同。 以 Internet 浏览器为例：Chrome 是当今使用最广泛的浏览器，但这是否意味着基于 Chromium 的 Edge 浏览器应该看起来完全相同或仅略有不同？ 在我看来不是。 正如我上面所说的，当前的 UWP 默认控件样式为 UWP（以及 Windows）提供了一个不错的独特外观。 我希望 Windows Fluent 团队考虑的一些事情（即不要只是为了改变而改变东西）。

@Felix-Dev Fabric Web 是微软基于 Fluent 的 Web 控件设计。 Chromium Edge 计划默认使用这些控件样式。 当然，Web 设计人员可以重新设计他们的 CSS 控件，开发人员也可以为 XAML 控件选择自己的模板。

我不知道为什么微软的控件设计需要从 Web 到 Windows 有如此大的不同。 看起来就像是不同的团队，而不是一起交谈。 开发人员仍然可以选择覆盖。 除非应用程序重新编译为 WinUI 3.0，否则这些新的默认值不会生效

查看您发布的视觉合成，我发现边框厚度看起来很奇怪的唯一区域是带有复选框的 TreeView。

@Felix-Dev，对于这个特定问题，我认为这只是 Figma 导出视觉效果有点奇怪的一些奇怪的错误。 我仔细检查了我从中导出 PNG 的实际构建和实际 Figma 文件，它们看起来不错。

RE：圆角的流行
@mdtauk和 @Felix-Dev ，
我的同事非正式地询问了开发人员（他们主要是 LOB/WPF/WinForms 开发人员）如何看待我们在他们的预览期间用圆角更新我们的控件，他们得到了观众的热烈掌声。 我们还经常收到人们抱怨我们没有在 Windows 版 Twitter 上拐弯抹角。

因此，虽然我确实尊重您的反馈（我希望您能收到反馈），但我们有轶事数据表明与我在这里听到的相反。 也就是说，这就是为什么我们正在考虑将其改回的方法，以防您希望这样做。 设计很棘手，因为它们相当主观。 如果你不喜欢红色，我不能强迫你穿红色衬衫，但如果那是“穿红色的一天”，你可能会对穿一件不显眼的衣服感兴趣。 如果你明白我的意思...... :)

好吧，最终归结为个人喜好。 我认为当前的 UWP 默认控件样式看起来不错，对我来说很重要的一个部分是它们与您在网络上或流行应用程序（如 Chrome 浏览器或 Android 等移动操作系统）上看到的相比看起来独一无二。 这是一股清新的空气。

现在，我可以理解为什么 MS 想要为其设计语言为 Windows 和 Web 使用不同的“默认”样式。 但是，我确实感觉到当前的方向是让 Windows 看起来更像移动应用程序/移动操作系统，而我并不是真正的粉丝（请参阅“XAML 控件与 Web 和移动应用程序的发展方式不一致”）在问题提案中）。

开发人员可能可以轻松修改样式，但对我来说最重要的是 MS 将采用的默认样式，因为该样式将用于所有 MS 提供的应用程序（即设置），因此外部开发人员也将基于样式进行工作（多一些，少一些）。

@chigy

我的同事非正式地询问了开发人员（他们主要是 LOB/WPF/WinForms 开发人员）如何看待我们在他们的预览期间用圆角更新我们的控件，他们得到了观众的热烈掌声。

这难道不是问错了听众吗？ 日常用户呢？ 例如，我确实看到很多用户抱怨最近在 reddit 和不和谐频道中推出圆角（尽管您也总会有用户不关心或不支持这种变化）。

至于 Twitter 的例子：这是一个来自第三方的应用程序，它可能希望拥有自己独特的品牌风格。 我可以接受（毕竟，这是您的团队介入并为控件样式添加自定义支持的地方）。 但我当然不会使用外部应用程序作为检修 Windows 官方设计语言的理由。

长话短说，感觉 Windows 设计团队的目标是让 Windows 更贴近移动/网络世界。 现在，我只希望这些变化不会太激进，并且 Windows 仍将保持独特的外观，使其易于与其他环境区分开来。

@Felix-Dev Fabric Web 控件与其他框架和默认 Web 控件不同。 与类似于 Windows 10 MDL2 控件和 Windows 8/WinJS 控件的旧外观相比，它们最近更新为使用 Fluent Design。

XAML 控件目前仍然使用它们的 MDL2 控件设计，一些元素，如浮出控件和菜单使用 Fluent Design 元素和材料。

Fluent 和 Fabric 中的文本样式更多地使用粗体和半粗体字重。 各种 Windows 10 概念也使用了这些。 但是 Windows Shell 和收件箱应用程序还没有全部采用这种风格。

Fabric Web 和 Fluent Web 是自 Fluent Design 宣布以来 Microsoft 对控件的最新更改，因此我们很自然地查看这些设计以帮助我们找到这些 UI 的发展方向。 WinUI 3.0 是平台的重大变化，所有控件都焕然一新，让它们感觉更好、更新鲜，并且与 Microsoft 的 Fluent Design 更加一致。

RE：Web 一致性、流畅性和 Windows 独有
@Felix-Dev 和@mdtauk ，
Windows 设计团队的目标之一是“熟悉”。 他们对我们的客户进行了大量用户研究（如您所指出的，不是我们的开发人员，而是我们的日常用户），并发现无缘无故地与众不同并不是您想象的好事（我正在总结所以这不是他们所做的确切测试，所以不要在这里引用我）。 Windows 需要吸引新类型的用户，他们对任何技术的体验都可能是从移动或 Web 开始的。 这些用户在被介绍到 Windows 时会感觉到巨大的差距，而拥有“不同”的外观和感觉也无济于事。 像圆角这样的小变化会在感知上产生巨大的差异。 Office 团队进行了类似的研究，结果类似，因此我们正在向圆角前进。 我们不是轻率地或凭空做出这个决定的。

这并不意味着我们使它们完全相同。 如果有我们可以改进的地方，我们想要那个。 我们也希望像 Felix 提到的那样独一无二，但它们需要有意义，而不仅仅是意见上的差异。 这些是我们使用 Fluent 独特处理方法的地方。

正如我在本次讨论中前面提到的，我与 Office、Windows 和 Edge 团队密切合作。 我们的设计团队渴望有一个来自 Microsoft/Fluent 的设计，因此他们非常仔细地查看差异并消除差异，以便我们有一个可以共同发展的起点。

然而，非常有趣的是，这些变化中的许多是由这些团队单独孵化的，但它们经常到达非常相似的地方。 边界的细化是 Office 首先实现的，但 Windows 已经讨论了一段时间了。 正如 Martin 所建议的，这些都是 Fluent Design 方向的一部分。

_RE：圆角的流行_
@mdtauk和 @Felix-Dev ，
我的同事非正式地询问了开发人员（他们主要是 LOB/WPF/WinForms 开发人员）如何看待我们在他们的预览期间用圆角更新我们的控件，他们得到了观众的热烈掌声。 我们还经常收到人们抱怨我们没有在 Windows 版 Twitter 上拐弯抹角。

因此，虽然我确实尊重您的反馈（我希望您能收到反馈），但我们有轶事数据表明与我在这里听到的相反。 也就是说，这就是为什么我们正在考虑将其改回的方法，以防您希望这样做。 设计很棘手，因为它们相当主观。 如果你不喜欢红色，我不能强迫你穿红色衬衫，但如果那是“穿红色的一天”，你可能会对穿一件不显眼的衣服感兴趣。 如果你明白我的意思...... :)

_RE：Web 一致性、流畅性和 Windows 独有_
@Felix-Dev 和@mdtauk ，
Windows 设计团队的目标之一是“熟悉”。 他们对我们的客户进行了大量用户研究（如您所指出的，不是我们的开发人员，而是我们的日常用户），并发现无缘无故地与众不同并不是您想象的好事（我正在总结所以这不是他们所做的确切测试，所以不要在这里引用我）。 Windows 需要吸引新类型的用户，他们对任何技术的体验都可能是从移动或 Web 开始的。 这些用户在被介绍到 Windows 时会感觉到巨大的差距，而拥有“不同”的外观和感觉也无济于事。 像圆角这样的小变化会在感知上产生巨大的差异。 Office 团队进行了类似的研究，结果类似，因此我们正在向圆角前进。 我们不是轻率地或凭空做出这个决定的。

这并不意味着我们使它们完全相同。 如果有我们可以改进的地方，我们想要那个。 我们也希望像 Felix 提到的那样独一无二，但它们需要有意义，而不仅仅是意见上的差异。 这些是我们使用 Fluent 独特处理方法的地方。

正如我在本次讨论中前面提到的，我与 Office、Windows 和 Edge 团队密切合作。 我们的设计团队渴望有一个来自 Microsoft/Fluent 的设计，因此他们非常仔细地查看差异并消除差异，以便我们有一个可以共同发展的起点。

然而，非常有趣的是，这些变化中的许多是由这些团队单独孵化的，但它们经常到达非常相似的地方。 边界的细化是 Office 首先实现的，但 Windows 已经讨论了一段时间了。 正如 Martin 所建议的，这些都是 Fluent Design 方向的一部分。

我完全赞成更改默认控件，并且 Fabric Web 控件比 IMO 当前的 XAML 控件设计更优雅、更精美。

但这不仅仅是更改模板，它还公开了更多属性，允许开发人员轻松覆盖这些更改，而无需重新模板化整个控件。

新的默认 CornerRadius 值可以是 ThemeResources，类似于
<Thickness x:Name="ControlCornerRadius" Value="2,2,2,2"/>
<Thickness x:Name="FlyoutCornerRadius" Value="4,4,4,4"/>

然后开发人员可以在 App.xaml 中覆盖这些 - 或者将CornerRadius="0" 应用到他们想要保持平方的控件上。

在此之后，我还建议将 BorderThickness 的默认值设置为 1epx 而不是 2epx - 但所有控件都将使用 ThemeResources，例如：
<Thickness x:Name="ControlBorderThickness" Value="1,1,1,1"
<Thickness x:Name="ControlFocusedBorderThickness" Value="2,2,2,2"
<Thickness x:Name="FlyoutInnerBorderThickness" Value="1,1,1,1"
<Thickness x:Name="FlyoutOuterBorderThickness" Value="1,1,1,1"

因此，这些可以在 App.xaml 中全局覆盖，或者仅在应用于少数控件的样式中覆盖。

设置新的默认值，但允许不需要重新模板化的覆盖。

但这不仅仅是更改模板，它还公开了更多属性，允许开发人员轻松覆盖这些更改，而无需重新模板化整个控件。

@mdtauk ，没错，正如我所提到的，它是由 #684 提出的更改跟踪的。 将@kikisaints添加到此线程，以便她看到您提供的良好反馈（但不要引用整个内容，因为它会很大。:)

@chigy当我发布最后一个回复时，添加了其他内容，所以我必须包含引号:)

我很想听到更多关于 Windows UI 团队一直在进行的讨论。 在过去的几年里，我一直在为自己的目的和 Twitter 对话制定控件设计理念，现在 Fabric Web 和 Office Xaml 中的一些东西是我想要改变的东西。 边框粗细、与单选按钮、复选框、下拉菜单等的某些不一致。

我很高兴看到这些变化的发展，也很高兴参与这里的讨论！

感谢您以我想要的建设性方式激发我的热情，即使它可能会让人觉得咄咄逼人或固执己见。

我绝对赞赏让自定义控件像设置属性一样简单的决定，而不必为单个更改重新模板化整个控件。

但是，最后，我最想看到的是操作系统中增加的个性化支持：正如您现在所知，我不喜欢提议的更改（微妙的圆角半径是一回事，减少边框厚度又是另一回事）我喜欢现在的设计。 另一方面，我们有像@mdtauk这样的用户，他们显然是提议更改的忠实

特别是从边界思考来看，提议的系统使得为角半径提供系统范围的选项变得非常容易（就像今天的强调色一样，它作为资源应用程序可以使用）。 特别是看到建议的角半径变化相当小，这对于应用程序来说在设计上也是可行的（如果开发人员不这么认为，可以随时选择退出）。

我很想听到更多关于 Windows UI 团队一直在进行的讨论。

@mdtauk ，我们打算通过 GitHub 带来所有即将到来的视觉变化，所以期待更多的变化。 我还计划扩展文档以包含其中一些背景，但这是我正在试验的东西，所以不确定这是否是确定的事情......

然而，最后，我最想看到的是在操作系统中增加个性化支持......
Windows 应该利用这些控件的新灵活性，并提供选项来自定义系统范围内的外观 - 在有意义的情况下，还可以让开发人员灵活地选择不遵循系统设置。

@Felix-Dev ，我们目前正在为 Windows 寻找的个性化类型（我假设用户可以从设置中更改某些内容？）会影响可用性。 我不确定圆角或边框厚度是否是其中之一。 Windows 的目标不是让用户可以按照自己的意愿设计整个 UI。 我们仍然希望提供 Windows 设计，圆角是关键设计因素之一，我认为这不是个性化的东西......至少现在根据个性化的定义。 感谢您的反馈，当我们考虑进一步的设计更改时，我会寻找可以公开的地方。

@Felix-Dev 由于开发人员可以对控件进行大量自定义，因此不可能与有关控件设计更改的任何操作系统设置保持一致。

@chigy当您将每个新控件设计的设计组件带到 GitHub 时，包含 Microsoft 从任何研究中收集的有关更改为何会改进事物的信息会很有用。 因此，与其说“我们把它从三角形改为六边形”，不如说是“在进行用户舒适度和熟悉度实验时，发现当把这个按钮设计从三角形改为六边形时，更多的人发现它更容易将其标识为按钮，与其他平台 UI 相比，感觉与此设计相似”等

@mdtauk

由于开发人员可以对控件进行大量定制，因此不可能与有关控件设计更改的任何操作系统设置保持一致。

我不是在谈论外部开发人员将如何尊重该用户设置——他们今天已经可以按照他们想要的任何方式设置控件的样式——而是关于 Windows 组件的外观。 这意味着设置应用程序、剪贴板、Snip 和 Sketch、任务栏弹出窗口中的 UI 元素（如网络面板中的按钮）等...

我几乎不使用 MS 提供的任何 UWP 应用程序之外的任何 UWP 应用程序，因此我对外部开发人员的自定义样式没有任何问题。 不过，我每天都会与 Windows 系统中的 UWP 元素进行交互。

@chigy正确，我正在查看 Win 10 设置应用程序中的一个设置，用户可以在其中更改 - 在某种程度上 - UI 的外观。 在增加工作使用户可以更改 UI 特征方面，什么真正有意义并且也可行，还有待观察。 我确实觉得现在提议的更改越小（微妙的圆角半径），添加一个选项以返回到以前的样式（方形控件）就越可行。

最后一件事：Win 10 拥有 8 亿用户，而且还在不断增加。 并不是每个人都像 Martin 一样对提议的更改如此热情，如果 Windows 也尝试适应这些用户，那就太好了。 正如您所说，UI 是非常主观的，如果有可能为 UI 系统增加灵活性，MS 至少应该考虑这一点。
例如，对于 Internet 浏览器，有一个主题的整个行业，其中不仅更改颜色，还更改选项卡或搜索栏等 UI 元素的外观： https :
但是对于Windows系统，用户不能随便创建一个自己的主题，如果MS能提供UI定制选项就好了。

@mdtauk @chigy
请查看这篇 reddit 帖子，了解不仅仅是我不喜欢圆角。 我们有人不喜欢整个举动，还有许多人呼吁为用户提供 Windows 外观的选择，以便他们可以恢复到当前外观。

好吧，所以我被很多人敦促给这个线程一些反馈，因为有一个对 UI 中提议的更改的询问，主要是强制圆角到几乎所有东西上的想法，并且作为一个既是图形界面设计师（主要是概念设计师）的人和设计）并且自从 Windows 10 还在开发中就一直使用我绝对会支持所有强烈不喜欢提议的更改以在整个操作系统中添加圆角的人，并强烈敦促不要进行这些更改，或者要么让用户可以通过个性化选项来选择是否需要圆角或尖角。

遗憾的是：只需将它们保留为 Square 或在用户级别使其可选。

我有足够多的理由，但我最大的理由只是 Windows 自从 Windows 8 以来就有方角，而且多年来几乎所有的东西都是围绕这个设计的，这个提议很大程度上是为了采用与 iOS 相同的圆角无论出于何种原因，Android 平台。 更大的问题是这样做不仅会增加系统范围内不一致的数量，而且会迫使如此“小”的 UI 更改实际上比您意识到的要大得多也会导致整个应用程序生态系统的不一致，因为您将有不想仅仅因为这样的简单更改而更新他们的应用程序的开发人员。

在我看来，这绝对不应该是开发人员的选择，不仅出于上述原因，而且 Windows 一直是关于自定义和功能的，以 Windows 98 aka Classic 主题为例。 当 Windows XP 出现时，许多人仍然使用 Classic，因为它比 Luna 主题有更多的自定义选项。 XP 根本没有将 Luna 主题强加给每个人，您仍然可以选择使用 Classic。 这个提议的更改不会让您选择在任何地方保留方角，它迫使每个人处理他们可能不喜欢的东西，在我看来，当让用户根据自己的喜好自定义操作系统时，这是一件非常糟糕的事情。

我知道你可能会想，“这么小的改变不是用户感兴趣的东西”或“让用户自定义太多东西会让他们感到困惑”但我很确定任何用户都能够理解在两者之间切换给出适当的描述和上下文，圆角和尖角甚至主题都可以。 我还要补充一点，很多人肯定有兴趣选择这个选项，而不是违背他们的意愿强加其他东西，如果您需要更多证据证明人们不喜欢四舍五入的想法，请参阅 Reddit 帖子@Felix-Dev角落无处不在。

许多人甚至非常不喜欢圆角的提议，许多人认为这是一种倒退，甚至查看即将推出的 Hololens UI 圆角的几个视频中的评论，大多数评论再次是关于强烈不喜欢所有圆角，甚至还有评论说“微软在 UI 部门认输并抄袭苹果或谷歌”的变体，尽管这不是微软第一次使用圆角，人们现在认为它是一件消极的事情。

同样，这应该只是一个选项，甚至是一个主题，它甚至不是一个新概念，因为 Windows 在以前的版本中已有多年的主题，如果有的话，这应该是一条消息，要求恢复强大的主题，而不是再次强制执行某些操作到每个人身上并减少选择。

我创建了一个链接到此提案的reddit 帖子，以便我们可以收集更多反馈。 看看到目前为止的评论，我可以说很多人都喜欢圆角的微妙方法。

人们还指出 UI 不一致——即使在官方的 Win 10 MS 应用程序中，请参阅设置应用程序和安全应用程序（导航视图扩展到标题栏）——以及 win32 系统组件和较新的 UWP 元素之间的差异。 正如@SavoySchuler提到的，这有望通过 WinUI 3.0 解决。 这不是关于此提案的具体问题，而是我们许多 Windows 用户的“总体”愿望。 与其说是圆角还是不圆角，不如说是 Windows 系统中的一致性。

一致性是这里的关键，也是我主要关心的问题。

WinUI 3.0 是关于影响收件箱应用程序和 Windows UI 的 XAML 控件的更改。

Fabric Web 是它自己的团队，但是所有团队都是一起交流的，他们的决策基于 Fluent Design，所以我的假设是 Fabric Web 的设计是来自微软的最新思想，所以一致性应该占上风。

Xbox Next，Windows Lite 和 Windows Core OS 将配备新的外壳，因此团队也必须考虑这一点——Windows 10 将提供旧版支持

@chigy所说的正是我和许多其他人刚刚要求的，一个更微妙的变化，也将允许用户级别而不是开发人员级别的人们简单地决定他们是否想要看到尖角或圆角，类似于如何Windows 主题曾经有效。

根据@Nepxune上面所说的，为用户提供他们可以为系统范围的角半径选择的值范围可能会很酷。 至少对于 0 - 2 范围内的小值，我认为不会对精心设计的 UI 产生任何负面影响。 毕竟，这些都是非常微妙的变化，因此仍应保留 Windows 的 UI 标识。

我确实看到，即使 UI 自定义将添加到 Windows，也必须有限制，无论是用户可更改的元素数量还是用户可以选择的值集。 否则，存在对现有 UI 产生负面影响的风险，并且还会偏离设计团队所需的 Windows 外观。

对此，我有不同的看法。
在该主题的早些时候，我看到了关于将 Fabric UI (Web) 和 Windows (UWP) 样式更紧密地结合在一起的讨论，这让我有点担心。

以下是一些背景信息：我多年来一直是 Microsoft Edge 的用户，我最喜欢的事情之一是它受 UWP 启发的外观和感觉。 当 Edge Insider 曝光时，我很失望地看到它使用了修改后的 Chrome 和 Web UI 设计，而不是其前身的 UWP 样式。 虽然显示的圆角非常小，但我对它们没有任何问题，这个线程给了我同样的失望感。 我不想看到 Windows 失去其独特的（和优越的！）外观和感觉，以支持匹配设计不良的“Web 标准”。 事实上，我更愿意看到 Fluent UWP 设计的各个方面都适用于 Fabric！

我相信 Edge 的计划是最终带回 Acrylic，并将 UI 更倾向于 Windows/Fluent 设计风格。

但 Windows 也在略微向前推进，以期弥合分歧。

在 OS 中引入一个 Setting 来在圆形和非圆形控件之间进行选择并非不可能，不可能将它强加给所有应用程序，并且以与 XP 时代视觉样式完全不同的方式工作。

此外，WinUI 3.0 将应用程序平台和控件与操作系统分开，因此将更多内容联系在一起可能不是一个好的决定。

当然，作为应用程序开发人员，您可以选择将控件上的 CornerRadius 值设置为 0 以恢复平方的控件。

我支持这种对小圆角的推动，但我更喜欢当前的垂直手柄滑块控件而不是圆形手柄滑块控件。 垂直手柄感觉更精确，更容易一目了然地弄清楚它在哪里。 至少我是这么看的。 继续努力吧！

MediaTransport Scrub Bar Thumb 是带有轮廓的圆形，而建议的新 Slider Thumb 是一个实心圆圈，这是否有原因？

我认为圆形拇指比不适合任何其他控件的笨拙菱形/药丸形状更令人愉悦。

我不知道你们是否记得它，但即使让人们在圆角中平铺对于当时的许多 Windows 粉丝来说也是一个大问题，这只是一些小改动。 对我来说，圆角无处不在意味着 Windows 将失去它自引入 Metro 设计语言和流畅设计以来的独特外观。 Tbh 设计语言对我来说一直是一个重要的关键，是什么让 uwp 开发对我有吸引力。 看到它变成通用的，真的很难过。

连同我已经完成的 TextBox 和 NumberBox 设计概念 - 这里有一些用于 ComboBox 和 EditableComboBox

不错的工作！
我有一些关于弹出菜单的建议。 有了阴影划分菜单，我们真的需要边框吗？ 并且 IMO 选择突出显示可以覆盖弹出表面的整个宽度，而不会留下间隙。

我很欣赏更薄的未聚焦边框，并且焦点显示发光应该可以在使用键盘切换 UI 时更容易看到哪个元素被聚焦（我实际上更喜欢它比上面的略强）。

不错的工作！
我有一些关于弹出菜单的建议。 有了阴影划分菜单，我们真的需要边框吗？ 并且 IMO 选择突出显示可以覆盖弹出表面的整个宽度，而不会留下间隙。

选择高光确实覆盖了整个宽度，但我在弹出窗口中放置了一个较亮的内边框，这将有助于它与亚克力效果和阴影一起从表面提升 - 内边框可以做得更微妙，但是如果它太强- 它更多的是一个想法，而不是一个完整的最终设计方案。

@mdtauk

在 OS 中引入一个 Setting 来在圆形和非圆形控件之间进行选择并非不可能，不可能将它强加给所有应用程序，并且以与 XP 时代视觉样式完全不同的方式工作。

这就是为什么我说让它对开发者来说是可选的。 老实说，什么都不会改变。 第三方应用程序已经可以提供他们想要的任何外观。 如果一家公司想要发布带有圆形 UI（圆形按钮，...）的应用程序，他们可以随意这样做。

此外，WinUI 3.0 将应用程序平台和控件与操作系统分开，因此将更多内容联系在一起可能不是一个好的决定。

正如我上面所说的，我将其描绘为类似于今天处理重音颜色（用户可以在设置中设置）的方式。 将其公开为资源控件可以将其角半径绑定到，这样，角半径更改将反映在应用程序中，而无需开发人员进行额外的工作。

只是从用户的角度留下我从 reddit 的反馈：“我喜欢提案中干净的圆角外观。 和其他人一样（在 reddit 上），整个操作系统的一致性仍然需要很多爱。”

MediaTransport Scrub Bar Thumb 是带有轮廓的圆形，而建议的新 Slider Thumb 是一个实心圆圈，这是否有原因？

@mdtauk ，事实上，这是我们正在考虑的事情，但这并不意味着我们会做出改变，所以我没有设定期望......

我有一些关于弹出菜单的建议。 有了阴影划分菜单，我们真的需要边框吗？ 并且 IMO 选择突出显示可以覆盖弹出表面的整个宽度，而不会留下间隙。

@quantumfrost ，是的，事实上，我们这样做。 影子很聪明。 因此，当系统处于低功耗模式或其他一些我们关闭阴影的情况时，边框就会发挥作用。 我们以微妙的方式设计了边界。 我们确实评估了几个不同的选项，但这是最可靠的。

@nepxune ，@mdtauk
感谢您的反馈意见。
让我回应你上面提出的几点。

提供用户设置以具有用户可以选择的圆角的选项是一个有趣的选项。 然而，它也与我们在整个 Windows 系统中必须权衡的其他重要功能的反馈有很大关系。

作为应用程序开发人员，我希望你们都敏锐地意识到需要优先考虑并为您的客户做正确的事情。 对于 Windows 案例，客户是使用操作系统的用户。 当然，在此操作系统上创建应用程序的开发人员也是重要的客户，我相信通过提供易于切换角半径的功能，我们能够解决此更改可能带来的主要问题。

对于使用该操作系统的用户，我们从客户那里听说 Windows 太吓人了。 Windows 和 Office 团队都进行了用户研究，他们最终（独立地）得出结论，即使像圆角一样微妙，也会使产品感觉熟悉和平易近人。

所以我知道 GitHub 和其他论坛上有很多人提到我们正在关注 iOS 和 Android，但事实并非如此。 我们是通过了解我们的用户来做出这个决定的。 是的，他们使用圆角的事实增加了熟悉度，但我们并没有盲目地关注行业正在做什么。

对此，我有不同的看法。
在该主题的早些时候，我看到了关于将 Fabric UI (Web) 和 Windows (UWP) 样式更紧密地结合在一起的讨论，这让我有点担心。

以下是一些背景信息：我多年来一直是 Microsoft Edge 的用户，我最喜欢的事情之一是它受 UWP 启发的外观和感觉。 当 Edge Insider 曝光时，我很失望地看到它使用了修改后的 Chrome 和 Web UI 设计，而不是其前身的 UWP 样式。 虽然显示的圆角非常小，但我对它们没有任何问题，这个线程给了我同样的失望感。 我不想看到 Windows 失去其独特的（和优越的！）外观和感觉，以支持匹配设计不良的“Web 标准”。 事实上，我更愿意看到 Fluent UWP 设计的各个方面都适用于 Fabric！

@19lmyers
感谢您对 Windows 失去其独特（甚至卓越）外观的担忧提供反馈。 正如上面评论中提到的，我们的用户不一定会因为他们不熟悉 Windows 而欣赏 Windows 的太大差异，所以这是一种平衡。

在 Fluent Design System 下，整个公司的设计团队正在讨论许多差异，并试图消除迄今为止引入的不必要的差异。 正如我上面对iOS和Android的评论，我们提出的那些设计并不是因为我们在复制Fabric，而是我们的Windows设计师基于重新评估他们自己的UI系统而得出的。 它们通常会产生相似的设计，这很有趣……也就是说，我非常感谢许多人对保持 Windows 独特性的热情。

欢迎来到我们的仓库，@zag2me！ 我们很高兴您加入这里的讨论。 我同意，这是提请注意对您而言重要的问题的正确位置！ 您可以在此处找到我们的功能请求表： https :

@chigy

提供用户设置以具有用户可以选择的圆角的选项是一个有趣的选项。 然而，它也与我们在整个 Windows 系统中必须权衡的其他重要功能的反馈有很大关系。

对于使用该操作系统的用户，我们从客户那里听说 Windows 太吓人了。 Windows 和 Office 团队都进行了用户研究，他们最终（独立地）得出结论，即使像圆角一样微妙，也会使产品感觉熟悉和平易近人。

我们是通过了解我们的用户来做出这个决定的。 是的，他们使用圆角的事实增加了熟悉度，但我们并没有盲目地关注行业正在做什么。

感谢您对 Windows 失去其独特（甚至卓越）外观的担忧提供反馈。 正如上面评论中提到的，我们的用户不一定会因为他们不熟悉 Windows 而欣赏 Windows 的太大差异，所以这是一种平衡。

这就是我遇到的问题：你提到了“Windows 用户”，但如果有的话，这个线程和其他链接的 reddit 线程到目前为止表明没有一个同质的“Windows 用户”组。 归根结底，公司始终可以按照大多数客户希望的方向前进，但即便如此，也会存在问题。 如果该比率相当小（并且每个数字背后都有庞大的绝对用户数）怎么办？ 基于这里的反馈意见，Reddit和其他地方我不明白的感觉是有绝大多数为一个UI或其他。

这导致我们提出我们中的一些人一直在提出的建议：向 Windows 添加更多 UI 自定义选项。

正如您所说的那样，应该仔细衡量给定的自定义选项，但不应将自定义本身作为一个选项丢弃。 正如您所说，此时我开始重复自己，建议的角半径变化是一个很小的变化，因此将其作为用户选择对 UI 的任何影响都应该可以忽略不计或直接不存在。 我和其他人也指出了这个例子的局限性，例如角半径范围在 0 - 2 之间的一组值，以确保用户不能以破坏“Windows UI”的方式自定义他们的 Windows身份”您的团队想要创建。

长话短说，在这些设计更改之上精心衡量的自定义选项听起来像是解决我们 Windows 用户之间许多不同 UI 偏好的好方法，并且对于为我们热情的 Windows 用户整个家庭创建令人满意的 UI 大有帮助.

@chigy
大多数人会同意 2px 是一个很好的半径。 给其他人一个关闭它的选项将是一个很好的理想。

大多数用户希望 Windows 处于 UI 的前沿，但其他传统用户不想改变。

不要为少数人牺牲改变，只要让他们选择关闭它即可。

@shaheedmalik
这里没有“遗留”用户，我也看不出你是如何得出“大多数用户想要[圆角]”或者当前的 Windows 外观不是“前沿”的。

UI 是非常主观的，但这并不意味着我们可以将不同的意见掩盖为“遗留”、“不愿意改变”等......

让我们不要试图仅仅丢弃其他用户所说的“不想从过去醒来的用户”的意见，而是保持当前的讨论充满激情，但也像迄今为止一样尊重。

@Felix-Dev Legacy 用户是那些有机会会留在 Windows 7 上的用户，那些抵制 Windows 8 中所做更改的用户，以及那些抵制 OS UI 向前发展的用户。

苹果和谷歌复制了 Windows 8.1 的功能，实施了它们，用户跳到这些平台上，因为它们被视为最前沿。 与此同时，微软听取了传统用户的意见，由于少数人大声疾呼而缩减规模。

在这种特殊情况下，大多数人希望圆角作为链接（https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/）

问题是，虽然我不是传统用户，但在我看来，您只是将每个不喜欢当前圆角推动（以及可能的边框厚度减少）的人都归入了那个确切的类别。 我也没有让你对我的帖子投反对票。

关于大多数情况：我不知道 MS 关于这个主题的任何设计调查，并且基于一个月前许多用户的反应，当时有关此推送的详细信息首次出现在 Internet 上，许多用户都不知道（所以很可能没有被问到）。 如果您查看这篇reddit 帖子（顺便说一句，到目前为止，该我们所知道的图片来看，这并不完全清晰。 我无法声称“这个立场显然占多数”，而且我将来也不会这样做。

如果我对您的帖子有误解，那么我深表歉意，但从我阅读它的方式来看，这显然是对任何反对此更改的声音的不屑一顾，宣称它是“不想更改的旧用户的声音” ”。 这是对我的不尊重，所有其他人都会在这场辩论中发表自己的意见。

@Felix-Dev 让我们不要试图将任何个人意见解读为这些赞成/反对投票和回复。

简单的答案是，这些更改不是一时兴起，也不是为了复制其他平台 UI 样式——而是咨询、反馈以及用户和开发人员表达意愿的结果。

我们应该尽量保持讨论的建设性，所以不是要不要改变，而是应该以什么方式改变。

人们讨厌原始帖子中的圆角，因为它们太圆了。
这个较新的帖子链接到这个更新的 GitHub 提案。 较新的反馈反映了更新提案的响应。 此外，一个月前的原始帖子被链接到向用户展示从原始提案到修订提案的变化。

我同意，我们应该回到提案并忘记这些最后的帖子。

我认为在这一点上很清楚将进行这些更改，我所要做的就是说服@chigy有一个经过仔细衡量的定制的案例，这里的每个参与者在某些时候可能会觉得有用 - 无论他们喜欢当前的用户界面改变与否。 正如我和其他人所说，包括@shaheedmalik ，添加某种角半径自定义可能是一个很好的理想。

现在有一个建议让开发人员可以轻松地在每个控件上设置自己的 CornerRadius (#684)，这也使团队能够默认将 CornerRadii 添加到控件中。

在操作系统级别执行此操作是一项复杂的任务，并且该研究并不能完全保证实现该任务所涉及的工程时间和精力。

但是你已经明确了@Felix-Dev 的观点，如果在新控件掌握在大多数 Windows 用户手中之后，收到的反馈可能会导致将来探索这个想法。

我已更新规范以从四舍五入中删除“AppBarSeparator”，因为我确认这是 1px 行。

我已更新规范以从四舍五入中删除“AppBarSeparator”，因为我确认这是 1px 行。

@chigy在 100% 缩放时，它将是 1 epx - 但在 200%、300%、400% 缩放时，这可能需要一些注意。

如果它真的是一条线，而不是一个矩形 - 也许将StrokeStartLineCap和StrokeEndLineCap设置为PenLineCap.Round

@mdtauk

在操作系统级别执行此操作是一项复杂的任务，并且该研究并不能完全保证实现该任务所涉及的工程时间和精力。

这个提议似乎已经完成了大部分工作，为控件添加了一个 CornerRadius 属性。 剩下的唯一事情就是创建资源 SystemCornerRadius 这些控件可以绑定到它们的实际角半径（类似于今天您如何使用 SystemAccentColor 资源以用户在“设置”应用程序中设置的强调色为 UI 元素着色。

至于创建此类资源并使其可通过“设置”应用程序更新需要多少工作，这仍有待 MS 发表评论。 但考虑到该提案已经在进行的工作，以及之前以公开 AccentColor 资源的形式进行的工作，我不认为它会像您所说的那样苛刻。 操作系统级别实际上只是提供一个可以读取和写入的圆角半径值，然后使用您已经为今天的强调色资源安装的相同系统。

@mdtauk

在操作系统级别执行此操作是一项复杂的任务，并且该研究并不能完全保证实现该任务所涉及的工程时间和精力。

这个提议似乎已经完成了大部分工作，为控件添加了一个 CornerRadius 属性。 剩下的唯一事情就是创建资源 SystemCornerRadius 这些控件可以绑定到它们的实际角半径（类似于今天您如何使用 SystemAccentColor 资源以用户在“设置”应用程序中设置的强调色为 UI 元素着色。

至于创建此类资源并使其可通过“设置”应用程序更新需要多少工作，这仍有待 MS 发表评论。 但考虑到该提案已经在进行的工作，以及之前以公开 AccentColor 资源的形式进行的工作，我不认为它会像您所说的那样苛刻。 操作系统级别实际上只是提供一个可以读取和写入的圆角半径值，然后使用您已经为今天的强调色资源安装的相同系统。

它是滑块还是开关？

[X] 控件上的圆角

顺便说一句，不会只有一个角半径值来设置。 有些元素只会在一侧有圆角，或者只有顶角会被圆角。 弹出控件和弹出控件将获得 4 epx 半径，而其他控件将只有 2 epx。

随着操作系统中此设置的更改，您将设置许多变量。 那么测试呢？ 也会有期待。 用户对他们决定忽略用户偏好的应用会有什么反应？
您如何与用户沟通哪些控件是四舍五入的，哪些不是？ 某些控件将具有内边框或外边框元素。 这些需要调整它们的 CornerRadius 值以确保正确地拥抱形状的边缘。

最后，这可能是一个受欢迎的变化，没有大惊小怪，因此向操作系统添加另一个选项可能被认为是一种过度反应。

@mdtauk @chigy
这当然需要一些计划，但团队显然希望让开发人员能够轻松创建方形控件。 因此，我可以使用简单的 UserRoundedCorners boolean switch代替角半径值设置。 事实上，设置值的想法只是为了添加更多选项，而不同意这一举动的用户总是只是给他们一个选项来恢复控件的外观。 所以，这根本不会成为问题。

至于“又一个选项”部分：听起来已经有太多可供用户使用的选项，这是一个完全不同的问题，不应用作不添加这个简单开关的定义点。

Windows 和设计团队每天（在 Twitter 上）讨论它希望如何包括用户而不是排除他们。 这是一个机会，我觉得这是比较容易的MS增加一个选项，以尊重他们的用户的意见纯粹的品种。

用户对他们决定忽略用户偏好的应用会有什么反应？

我认为这也不是问题，只要基本的 Windows 应用程序/用户界面元素会尊重它（即设置应用程序、安全应用程序、剪贴板、任务栏网络弹出连接/断开连接按钮......）。 第三方应用程序可以自由使用他们想要的样式，在设置应用程序中简单说明不保证第三方应用程序遵循此用户设置就可以了。

@mdtauk @chigy
我相信@Felix-Dev 是对的，带有简单切换的布尔开关可能是在用户级别进行自定义的方式，我觉得在用户级别进行自定义的滑块会使事情变得过于复杂，但是如果它是一个带有 3 个固定预设位置的滑块，事情可能会改变。

带有 3 个固定选项的滑块将允许进行额外设置，该设置可以像最初提出的那样具有更剧烈的角半径变化，因此您可以：

锋利 - 像现在这样的尖角
中间选项 - 新的较小半径
圆角 - 最初提议的半径变化或更圆角的东西

此选项有可能满足所有群体，此外，它是一个足够大的变化，您实际上可以将其作为 Windows 中的新“主题”功能传递出去，基本上即使通过将其标记为新功能，这对开发人员来说更像是一种变化带有切换实现或 3 个预设滑块的“主题”功能，您也可以将其作为新功能传递给消费者。

用户对决定忽略用户偏好的应用有何反应？

我觉得当强调色不可用时，用户只会像他们目前对强调色所做的那样看待它，第三方应用程序应该可以自由地做任何他们想做的事，但就像@Felix-Dev 所说的，Windows 应用程序/UI 元素肯定需要尊重用户的变量。

我认为没有必要在设置中添加注释说第三方应用程序不会遵守该设置，也没有必要在强调色部分添加免责声明，所以相信它与此相同好。

在操作系统级别执行此操作是一项复杂的任务，并且该研究并不能完全保证实现该任务所涉及的工程时间和精力。

但是你已经明确了@Felix-Dev 的观点，如果在新控件掌握在大多数 Windows 用户手中之后，收到的反馈可能会导致将来探索这个想法。

我觉得我必须在这里指出一些事情。 虽然我对任何一种提议的更改都没有强烈的感觉（我每天必须在不同的生态系统中使用过多的 UI 样式，因为不一致或更改会打扰我），但我觉得这种心态不是一个好的心态创造丰富的用户友好体验。

请不要发布已经完成 80% 并且可能会或可能不会在下一个版本中达到 100% 的功能。
可能会发生的情况是，没有开发人员会花时间为圆形或非圆形边框测试和开发他的应用程序。 他们为什么会。 系统现在使用四舍五入，为什么有人希望他们的应用程序看起来与操作系统略有不同（否则他们无论如何都会选择完整的主题）
如果有一个系统范围的切换，就会有实施它的动力。
但是，如果您以这种方式做事，则不需要切换，因为没有应用程序会首先看到实现它的需要。

关于原始主题：
我认为 2px 边框看起来很棒，除了组合框。
最后一个元素的高亮下方不应该留下白色边框（或者至少不超过左右，当然这意味着底部的高光角也必须是圆角的）并且也许不应该在其下方有圆角框和它的弹出窗口之间的展开状态。 我觉得这让他们之间出现了这种奇怪的脱节。
也许让弹出窗口的每一边都小 2px 并让它顶部没有圆角会更好。 这样，它看起来就像是从分配器中拉出的一张纸。 （我希望你能理解我的意思：D 遗憾的是我现在没有可用的工具来勾画它）

关于原始主题：
我认为 2px 边框看起来很棒，除了组合框。
最后一个元素的高亮下方不应该留下白色边框（或者至少不超过左右，当然这意味着底部的高光角也必须是圆角的）并且也许不应该在其下方有圆角框和它的弹出窗口之间的展开状态。 我觉得这让他们之间出现了这种奇怪的脱节。
也许让弹出窗口的每一边都小 2px 并让它顶部没有圆角会更好。 这样，它看起来就像是从分配器中拉出的一张纸。 （我希望你能理解我的意思：D 遗憾的是我现在没有可用的工具来勾画它）

我知道你在描述什么，我确实考虑过我的设计模型。 问题在于这意味着 ComboBox 将获得自己的弹出模板，这将使其与上下文菜单、菜单弹出、前缀、后缀、自动完成弹出等不同。

这就是我的意思（除了 Box 本身可以使底角保持圆形）
是的，不同的弹出窗口会有所不同，但同样存在两种类型的弹出窗口。
那些依附于某物的那些和那些不依附的。 他们现在必须有所不同只是做圆角的成本;)
此外，如果拐角半径变得可样式化，它不能仅由父控件设置。

我的 XAML 有点生疏，但像这样的组合框模板：

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

此外，如果拐角半径变得可样式化，它不能仅由父控件设置。

我的 XAML 有点生疏，但像这样的组合框模板：

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

这类似于您如何覆盖样式，但要在模板中使用，您需要为每个方向使用单独的样式。

<Thickness x:Name="FlyoutLooseCornerRadius" Value="4,4,4,4"/>

方向：

• 底部
• 底边左对齐
• 底边右对齐
• 满的
• 剩下
• 左边缘对齐底部
• 左边缘对齐顶部
• 对
• 右边缘对齐底部
• 右边缘对齐顶部
• 最佳
• 左上边对齐
• 顶边右对齐

Flyout 嵌入在 ComboBox 控件中。 因此，该控件将具有一个 CornerRadius 属性，该属性只会影响 ComboBox，而不影响包含的弹出框，这将是一个 ThemeResource 被覆盖。

<ComboBox CornerRadius="2,2,2,2">  
      <x:String>Blue</x:String>
      <x:String>Green</x:String>
      <x:String>Red</x:String>
      <x:String>Yellow</x:String>
</ComboBox>  

在 Flyout 对齐并附加到 ComboBoxes（和其他控件）时调整它的 CornerRadius 属性之后，可能需要将TopEdgeAligned和BottomEdgeAligned 添加到FlyoutPlacementMode枚举以实现所需的结果。

_（更新图片）_

我还对 Flyout 样式进行了 800% 的近距离观察。 两个边界将确保无论有无阴影，弹出窗口在明暗主题中看起来都很高。

那看起来非常好。
当然，当您附加的项目小于弹出窗口时，附加的外观看起来有点奇怪，但这绝对是由各个应用程序决定的。
底行项目的焦点突出显示可能不应该在底部四舍五入（因为顶部不是顶行），但这可能不是故意的。

顺便说一下，我刚刚注意到这种“附加外观”是 MacOs 顶部菜单栏的工作方式，因此这种外观似乎并不罕见；)

那看起来非常好。
当然，当您附加的项目小于弹出窗口时，附加的外观看起来有点奇怪，但这绝对是由各个应用程序决定的。
底行项目的焦点突出显示可能不应该在底部四舍五入（因为顶部不是顶行），但这可能不是故意的。

顺便说一下，我刚刚注意到这种“附加外观”是 MacOs 顶部菜单栏的工作方式，因此这种外观似乎并不罕见；)

我忘记了四舍五入，所以我更新了图像来解决这个问题，并在 Zoomed 示例中添加了更多细节 - 哦，包括悬停状态

我不确定我是否更喜欢中间的项目有一个圆形的亮点，因为一方面它更一致，另一方面它留下了那些有点咄咄逼人的外观（好吧现在我只是在编造东西:)）尖锐的白色突出显示的元素和边框之间的空间。
但这是我留给真正的设计师来决定的事情：D

我不确定我是否更喜欢中间的项目有一个圆形的亮点，因为一方面它更一致，另一方面它留下了那些有点咄咄逼人的外观（好吧现在我只是在编造东西:)）尖锐的白色突出显示的元素和边框之间的空间。
但这是我留给真正的设计师来决定的事情：D

我同意，我也有两种想法。 我想我喜欢它的直边，但由于召唤弹出按钮的控件将是圆形的，而这些是控件中的控件，它们_应该_是圆形的。

并且一些上下文菜单将包含不跨越弹出窗口的整个宽度的控件，因此圆形选择将适用于那些

我不确定我是否更喜欢中间的项目有一个圆形的亮点，因为一方面它更一致，另一方面它留下了那些有点咄咄逼人的外观（好吧现在我只是在编造东西:)）尖锐的白色突出显示的元素和边框之间的空间。
但这是我留给真正的设计师来决定的事情：D

我有同样的感觉。 如果组合列表与组合框大小相同，则它们应在原点处保持笔直，否则未对齐的一侧应为圆形。

@mdtauk @Qowy @shaheedmalik您是否可以为组合框创建自己的问题？ 这个线程一般是关于拐角半径的，而不是一些特定的情况，这些情况很容易产生一个全新的对话，如这里所见，因此掩盖了关于一般方法的讨论要点。

请不要误解这一点，但是如果我们对许多控件进行了这样的具体讨论，则该线程很容易失去其总体关注点。

非常感激！

PS：关于无边框高亮元素：元素高亮肯定是矩形。 让它具有圆润的颜色是很奇怪的。

我的观点可能是少数，但更改通用控件的角半径确实是一个糟糕的主意。 从@mdtauk 看上面的菜单示例并将其与当前的 Edge 菜单进行比较让我有点反感。 事情终于通过 Fluent 设计解决了，一切终于看起来一致并且非常好。 现在，让我们将其全部更改为看起来像 Web？ 不...让 Web 成为 Web，而不要管 Windows（和通用控件）。 如果开发人员想在他们自己的应用程序中使用第三方控件实现圆角，那就这样吧。 但是，现在开始改变默认的外观和感觉只是异端邪说——让苹果成为苹果，谷歌成为谷歌，让网络成为网络。 你们都只是继续做微软，做你自己的事——它正在发挥作用，所以让它发挥作用。 一方面，我真的很喜欢 Fluent 设计的 Microsoft Windows 10 外观和感觉，并希望我的应用程序看起来像 Windows - 而不是 Apple、Google 或 Web。 我无法忍受 Chrome 的外观——Edge 的外观比 macOS 好几光年，Windows 在形式和功能上要好得多。 而且，TBH，将 Windows 10 Mobile 带回手机。 真悲哀，别这么快就放弃了，让 Fluent 设计自己做吧。

@mdtauk

在操作系统级别执行此操作是一项复杂的任务，并且该研究并不能完全保证实现该任务所涉及的工程时间和精力。

这个提议似乎已经完成了大部分工作，为控件添加了一个 CornerRadius 属性。 剩下的唯一事情就是创建资源 SystemCornerRadius 这些控件可以绑定到它们的实际角半径（类似于今天您如何使用 SystemAccentColor 资源以用户在“设置”应用程序中设置的强调色为 UI 元素着色。
至于创建此类资源并使其可通过“设置”应用程序更新需要多少工作，这仍有待 MS 发表评论。 但考虑到该提案已经在进行的工作，以及之前以公开 AccentColor 资源的形式进行的工作，我不认为它会像您所说的那样苛刻。 操作系统级别实际上只是提供一个可以读取和写入的圆角半径值，然后使用您已经为今天的强调色资源安装的相同系统。

它是滑块还是开关？
[X] 控件上的圆角
顺便说一句，不会只有一个角半径值来设置。 有些元素只会在一侧有圆角，或者只有顶角会被圆角。 弹出控件和弹出控件将获得 4 epx 半径，而其他控件将只有 2 epx。
随着操作系统中此设置的更改，您将设置许多变量。 那么测试呢？ 也会有期待。 用户对他们决定忽略用户偏好的应用会有什么反应？
您如何与用户沟通哪些控件是四舍五入的，哪些不是？ 某些控件将具有内边框或外边框元素。 这些需要调整它们的 CornerRadius 值以确保正确地拥抱形状的边缘。
最后，这可能是一个受欢迎的变化，没有大惊小怪，因此向操作系统添加另一个选项可能被认为是一种过度反应。

这里的角半径为 2epx，那里的角半径为 4epx，而在另一个地方则不同，因为 2 或 4 看起来不太正确，这是糟糕的用户体验。 保持通用控件的原样 - 工作完成......继续制作其他伟大的东西。

@chigy
因此，我从几天前开始的reddit 线程中的响应中进行了统计，结果如下（不幸的是，似乎没有明显的方法可以轻松查看参与的用户总数）：

意见表达亲角半径（与当前用户界面相反）：18
表达支持当前用户界面（和反角半径）的意见：12（如果我将我作为 reddit 海报包含在内，则为+1，还包含

其余的部分：

• 要求 MS 提供 UI 选择
• 两者都很好
• 没有对提案发表意见
• 表达了对 Windows 系统不一致的普遍不满（即 Win32 程序与 UWP 应用程序）

尤其是最后一组（沮丧）是参与线程的很大一部分人。

总结结果，我们看到我们在圆角（提案）和方角（当前用户界面）方面都有相当大的派系。 除此之外，还有一群人表示希望能够在系统中的这两种风格之间切换。
然而，除了圆角与否之外，最给定的回应 - 一英里 - 最终为整个 Windows 系统带来一致性。 WinUI 3.0 和 MS 团队将把所有不同的 Windows 系统组件和 UWP 应用程序置于单一 UI 设计语言之下。

@chigy
微软设计团队一直在谈论“包括”用户而不是“排除”他们，我认为这个线程和上面的 reddit 线程表明有充分的理由在 UI 中提供一个简单的选项来在建议的圆角之间切换UI 和当前 UI（尖角）。

@Felix-Dev 从技术上讲，我发表的帖子是关于 Flyout 控件的，ComboBox 只是具有弹出组件的控件之一。

我碰巧认为四舍五入在所有情况下都是有意义的。 团队决定浮出控件和对话框将使用 4 个 epx 角，而其他控件将使用 2 个 epx。

@mdtauk ，
正如我所说，请不要误解这一点。 我认为在此线程中指出特定的控件 UI 绝对没问题（例如我在树视图示例中询问了复选框角半径的奇怪角厚度）。
只是，如果针对特定 UI 元素（例如浮出控件/组合框/...）发生跨越多个帖子的对话，我觉得最好为此特定问题创建一个单独的问题。 正如您所见，您关于弹出窗口的帖子很快引发了关于组合框的讨论。 现在想象一下，然后有人开始讨论焦点阴影应该是什么样子，我们有一个完整的“混乱”（如在近距离讨论的多个特定 UI 元素）开始，很难将线程带回一般建议以及如何处理。

@mdtauk ，
正如我所说，请不要误解这一点。 我认为在此线程中指出特定的控件 UI 绝对没问题（例如我在树视图示例中询问了复选框角半径的奇怪角厚度）。
只是，如果针对特定 UI 元素（例如浮出控件/组合框/...）发生跨越多个帖子的对话，我觉得最好为此特定问题创建一个单独的问题。 试想一下，然后有人开始讨论焦点阴影应该是什么样子，我们一开始就一团糟，很难将话题带回到总体提案以及如何处理它。

我不打算只针对弹出窗口单独提出问题，但我专门讨论了该控件的拐角半径。

我想知道@chigy是否可以为我们提供某种估计，当我们能够看到包含所有更新的控件设计的更新的设计工具包时，因此对话可以转向更具体的内容，而不是关于开始更改它们的决定的一般抱怨和。

如果你要计算帖子数，你也应该计算点赞数。

@shaheedmalik
没有明确地计算向上计数，因为我不确切知道那些向上投票者对这些 UI 类型的感受（例如，他们可以选择任何一种都可以，但仍然像当前 UI 一样喜欢圆形的corder提案）。 更重要的是，他们可能因为帖子中的某个部分而对帖子点赞，例如指出 UI 不一致。 因此，我只计算了在作者声明中您可以清楚地看到对任一 UI 的批准的实际帖子。

FWIW，“2px 似乎是最佳选择。” 以 54 分获得最高票数。

还有一个评价很高的帖子（+21 - 第 4 位）呼吁“最终用户主题支持”，尽管我无法确定所有这些赞成票是针对定制部分还是作者批评缺失的部分系统中的一致性。

我想知道@chigy是否可以为我们提供某种估计，当我们能够看到包含所有更新的控件设计的更新的设计工具包时，因此对话可以转向更具体的内容，而不是关于开始更改它们的决定的一般抱怨和。

谢谢你的慰问。 我在问题的“重要说明”部分链接了设计文件，所以请务必检查一下。

总的来说，我想确保我们在这里的对话集中在我们如何在 WinUI 中使用圆角。 我知道人们对这个想法有不同的看法，即使圆角通常是一个好主意。 所以我觉得值得一提的是，这是微软另一个团队正在推动的整体 Windows 设计方向的一部分。 我们只是想弄清楚如何让 WinUI 与这个新的设计方向一起工作，让开发人员更容易。 我们真的没有权力断定圆角不是 Windows 中的“东西”。 换句话说，圆角已经是一个计划，因此我们想让您了解并咨询我们的 WinUI 社区，以确保我们负责任地实施此功能。 希望这是有道理的。

我们真的没有权力断定圆角不是 Windows 中的“东西”。 换句话说，圆角已经是一个计划，因此我们想让您了解并咨询我们的 WinUI 社区，以确保我们负责任地实施此功能。

我怀疑这里的很多人都想与具有上述权威的人交谈，因为这对我们很多人来说都是主要问题。

谢谢你的慰问。 我在问题的“重要说明”部分链接了设计文件，所以请务必检查一下。

总的来说，我想确保我们在这里的对话集中在我们如何在 WinUI 中使用圆角。 我知道人们对这个想法有不同的看法，即使圆角通常是一个好主意。 所以我觉得值得一提的是，这是微软另一个团队正在推动的整体 Windows 设计方向的一部分。 我们只是想弄清楚如何让 WinUI 与这个新的设计方向一起工作，让开发人员更容易。 我们真的没有权力断定圆角不是 Windows 中的“东西”。 换句话说，圆角已经是一个计划，因此我们想让您了解并咨询我们的 WinUI 社区，以确保我们负责任地实施此功能。 希望这是有道理的。

您确实提到了有关某些事情的讨论仍在进行中，例如 TextBox 边框厚度等 - 所以我认为这些设计是一个_初始想法_而不是最终的最终设计。 （我想我希望仍然能够影响文本框、按钮、复选框等内容）

我想我知道这个问题的答案，但我还是会问 - 是否有计划分享团队已经决定的这些 Windows UI 设计？

Windows 计划的这些更改是否也适用于 Win32 视觉样式和 Shell 窗口标题栏等。如果是这样，WPF 在这些新样式适用的 Windows 版本上运行时可能还应更新其默认控件。 （我已经建议应该发生#699）

我们真的没有权力断定圆角不是 Windows 中的“东西”。 换句话说，圆角已经是一个计划，因此我们想让您了解并咨询我们的 WinUI 社区，以确保我们负责任地实施此功能。

我怀疑这里的很多人都想与具有上述权威的人交谈，因为这对我们很多人来说都是主要问题。

我猜这会在设计更改生效时出现在反馈中心 - 这很可能会到达 Windows 团队。

您确实提到了有关某些事情的讨论仍在进行中，例如 TextBox 边框厚度等 - 所以我认为这些设计是一个_初始想法_而不是最终的最终设计。 （我想我希望仍然能够影响文本框、按钮、复选框等内容）

我想我知道这个问题的答案，但我还是会问 - 是否有计划分享团队已经决定的这些 Windows UI 设计？

@mdtauk
是的，在这里要非常透明......事实是，这个特定问题的谈话越快放缓，我就能越早开始工作...... :)

@chigy如果我导致谈话脱轨和减缓进展，我深表歉意。 我只是想提供帮助，并确保 WinUI 3.0 看起来尽可能好！

@chigy
我现在很困惑。 您是 Windows Fluent 设计团队的工作人员，据说 WinUI 是“[...] 高度优化的原生 UI 平台，用于创建 Windows 本身”（引自此处的“WinUI 3 的好处”部分。所以，如果这不是影响 Windows 10 设计语言的地方，那么它是什么？

我不知道你的回复是什么感觉。 您基本上是在要求我们提供反馈，但事实证明我们从来没有太多机会影响提案？ 如果这个帖子里没有一个真正的权威，那么我们在这里所做的一切基本上都是热空气。 即使在像 Martin 那样的情况下，他发布了他的设计概念，希望它们能被设计团队实施。 WinUI 无法按照“Windows 设计权威”希望的方式设置控件样式，因为正如 WinUI 团队本身所说：“WinUI 3.0+ 将成为 Windows UI”。

@chigy
我和其他人投入了大量时间、精力和热情，试图强调“Windows 用户”并不是您的某些评论所暗示的同质群体。 我们向您展示了 Martin 和其他人之外的声音，他们不喜欢新的 UI 更新，因此想要为仔细衡量的 UI 定制提供理由。

感觉就像你忽略了这个需求。 你说“我们真的没有权力断定圆角不是 Windows 中的“东西”。”。 我和其他人最近几天并不是在呼吁放弃这个 UI 推送，而是在 Twitter 上关注你自己的“包括用户”而不是排除他们的设计演讲。 我们要求的是一个选项，而不是移动的逆转。
然而，到目前为止，除了“提供用户设置以让用户可以选择圆角的选项是一个有趣的选择之外，我们还没有得到太多的认可。但是，与其他反馈相比，它也与此反馈有很大关系”。我们必须在整个 Windows 系统中权衡的重要功能。”。 我想这是一个开始，但我们现在在哪里？

你说你不属于对 Windows 设计有权威的实际团队。 这意味着我们一直都在和错误的人说话！ 如果我们从来没有和团队中真正发号施令的成员交谈过，我想知道为什么你不能早点说。

我很失望，在投入了所有精力之后，现在才知道我从来没有和有权威的人交谈过。 基本上所有的反馈和我其他人收集的，使 UI 定制的理由基本上不会产生任何结果（因为你甚至不是一个需要说服的人）。

对不起，我就是无法理解它。 存储库中的 Windows Fluent 设计团队的一名成员据称驱动 Windows UI现在告诉我们几天后我们从未与真正重要的人交谈过。

对不起，如果这归结为咆哮，但我在这里有点震惊。 你可能不知道我在这个特定的讨论（以及其他写了热情回复的人）中投入了多少，但我想要求澄清一下。

我们现在对 UI 定制的呼吁实际上站在哪里？ 这个 repo 对于 Windows UI 讨论真的不再重要了吗？

我会留下它：

》 【WinUI 3.0】Windows原生UI平台WinUI 是高度优化的本机 UI 平台，用于创建 Windows 本身，现在更广泛地可供所有开发人员使用以访问 Windows。

@Felix-Dev 我希望影响，而不是坚持我的设计成为实际设计。 我是一名设计师，自 Windows Vista/7/Zune/Windows Phone 时代以来一直是 Windows 爱好者。

@mdtauk
确实，虽然您肯定不会反对 MS 采用您的想法，对吗？ 😉 毕竟，你对他们深信不疑！

对不起，如果它是因为你咄咄逼人而出现的（对我来说公平，你也说过这样你的提案可以这样提出），但@chigy的回复对我来说非常震惊。 希望你能理解！

WinUI 团队！= Windows 开发团队。

Windows 10 是当前的操作系统，但 Windows Lite 和 Windows Core OS 是未来的方向。

@chigy显然正在研究 Windows 团队计划对 OS Shell 做些什么，并希望确保 WinUI 3.0 将在那里看。 Windows 应用程序，如计算器、设置、任务栏弹出窗口和 Shell 等，可能都使用 WinUI 3.0，因此它们需要在同一页面上，设计明智。

Microsoft 的 Fluent Design 团队制定了其他 Microsoft 团队遵循的规则（颜色、字体样式和大小、材料等），例如 WinUI、Windows、Xbox、Office、Bing、Teams、Fabric、Fluent Web 及其 UI 设计工作。

如果我误解了这里的结构，我相信我会得到纠正。

我一直在为这个 repo 做出贡献的想法 - 一直试图弥合 Fabric Web 和 WinUI 3.0 之间的差距 - 我还包括了自 Win8 时代以来我一直在思考的想法。

澄清确实很好，因为这是我的理解方式：

@chigy是 Windows Fluent 设计团队的成员，FD（Fluent Design）是 Windows 10 的设计语言，因此她将成为 Windows 设计团队的成员。

然后是 WinUI 3.0，它被官方描述为驱动 Windows 并用于创建 Windows 本身的平台。 因此，Windows UI 设计讨论在这里确实让人感到宾至如归。
同样基于上述描述，这意味着 Windows 开发团队将使用 WinUI 来实现应用程序和系统 UI。 否则，需要在那些 UI 提案线程中明确指出，您不会与真正重要的人交谈，提案实际上只是关于实际实现的反馈，而不是 UI 设计。

即使 Windows Fluent 设计团队和 WinUI 团队不是设计和实现原生 Windows UI 的团队，也无法改变@chigy从未告诉我们我们从未与真正重要的人交谈过的事实。 我们投入了时间和精力（你与你的控制概念，我试图收集反馈，我们都进行了热烈的讨论，不要忘记所有其他热情参与的人），但最终我们从未与真正的 Windows UI 团队成员交谈过，我们实际上可以尝试说服我们的想法和信念的人。

我们真的没有权力断定圆角不是 Windows 中的“东西”。 换句话说，圆角已经是一个计划，因此我们想让您了解并咨询我们的 WinUI 社区，以确保我们负责任地实施此功能。 希望这是有道理的。

好吧，这对我来说是一个巨大的失望，就像其他人所说的对我们中的许多人来说这是一个大问题，所以如果你对此没有影响力，我可以礼貌地问@chigy ：我们应该与谁交谈？ 如果不是，我们怎么能在这个许多用户不喜欢的明显有争议的 UI 更改中发出我们的声音？

这与多年前Windows 10开发过程中发生的讨论非常相似，当时有人提议将Square个人资料图片变成圆形图片，许多人再次不喜欢这一点并前往反馈中心。 反馈中心有多个帖子获得了超过 1000000 多张支持票，要求不要这样做。

回应基本上只是再次告诉人们无论他们的意见如何，都将进行更改......

我会改写那篇文章，以减少居高临下和侮辱性的@Felix-Dev

@mdtauk
我的帖子在哪里侮辱？

我不会叫任何人任何名字，叫 WinUI 坏话，用侮辱性的话描述这个问题。 我没有人身攻击任何人，事实上我没有攻击任何东西。

@mdtauk
我的帖子在哪里侮辱？

我不会叫任何人任何名字，叫 WinUI 坏话，用侮辱性的话描述这个问题。 我没有人身攻击任何人，事实上我没有攻击任何东西。

@chigy是负责设计 WinUI 控件的人。 如果您将他的角色误认为是 Windows 或 Fluent 团队中的一个，那么您不应该说他的角色无关紧要，也不应该将其个人化。

@mdtauk
“Chigusa Sansen 是 XAML UI 平台团队的首席项目经理，也是 Fluent Design System 核心成员的一部分”（来源：https://mybuild.techcommunity.microsoft.com/speaker/545575?source=sessions）

在那次会议上，她还主持了与 Windows 相关的 FD 部分。

关于“真正重要的人”这部分。 我不认为这是侮辱性的，因为在我们的案例中，她确实说她不在实际上为 Windows 选择的 UI 方向发号施令的团队中。 我没有攻击千草三千小姐，也没有嘲笑她，也没有骂她。 我只是简单地陈述了她个人对我们说的话。

关于“真正重要的人”这部分。 我不认为这是侮辱性的，因为在我们的案例中，她确实说她不在团队中，而团队实际上为所选的 UI 方向发号施令
视窗。

好吧，我认为这是侮辱性的。 特别是你似乎误解了讨论的目的，而不是你被“误导”

@mdtauk
我们这里的波长不同，我没有必要去推测为什么会这样......

当我们开始关于一般 UI 移动的讨论时，Chigusa Sansen 小姐或 WinUI 团队的其他成员明确指出，该线程不适合进行此讨论。 相反，人们热情地开始讨论，争论支持/反对这一举动，认为他们正在与某人交谈 - 就本次讨论的性质而言 - 微软/Windows 的相关 UI 职位。

Chigusa 甚至参与了其中，您还随意添加了控制图像，希望能影响 UI 方向，并且没有 MS 的任何人进一步增加这种讨论一般 UI 设计的地方的感觉。 我的抱怨是，你似乎错过了， @chigy花了这么长时间才简单地告诉我们，在这里进行讨论真的没有多大意义，因为她显然甚至不在团队中打电话一般拍摄。

这与您所说的“误导”或“误解”无关，而是如此重要的信息被我们保留了好几天。 如果千草三仙小姐早点说出来，整个讨论早就开始了。 顺便说一句，这是你和她都想看到的。

@mdtauk
我们这里的波长不同，我没有必要去推测为什么会这样......

当我们开始关于一般 UI 移动的讨论时，Chigusa Sansen 小姐或 WinUI 团队的其他成员明确指出，该线程不适合进行此讨论。 相反，人们热情地开始讨论，争论支持/反对这一举动，认为他们正在与将在 Microsoft/Windows 担任重要 UI 职位的人交谈。 Chigusa 甚至参与其中，您还随意添加控件图像，希望能影响 UI 方向。 我的抱怨是，你似乎错过了， @chigy花了这么长时间才简单地告诉我们，在这里进行讨论真的没有多大意义，因为她显然甚至不在团队中打电话一般拍摄。

这与您所说的“被误导”或“被误解”无关，而是我们将如此重要的信息保留了好几天。 如果千草三仙小姐早点说这就是你和她都想看到的，那么整个讨论早就开始了。

@Felix-Dev @Nepxune
让我们保持文明和积极。 😃 那些发布的图像突出显示了对控件所做的更改，其中涉及 CornerRadius 值。 还有另一个问题是，将 CornerRadius 添加到目前不支持或不尊重该值的控件的特定机制可以支持它们，并且开发人员可以覆盖该值以将它们平方或自定义适合其品牌和需求的价值观。 第684章

此问题是指更新Common Controls上的Corner Radius，与Web和App风格方向一致。

我发布的想法是采用 Fabric Web 使用的样式，并将它们带到 XAML 控件中 - 所以我觉得它们在本次讨论的范围内。 控制 XAML 控件 ThemeResource 的操作系统功能稍微偏离主题，但相关。

谈话很有趣也很中肯，以至于有些人试图将其转变为讨论优缺点，首先进行改变 - 而不是如何成功地进行已经决定的改变制作。

我建议，如果您想提升一项提案，使舍入金额成为用户可以切换或更改的操作系统设置 - 那么这应该作为新建议提出。

请参阅行为准则并尽量保持尊重。 @chigy并没有试图欺骗或误导。

Martin 说得对，我们是负责帮助将设计产品化以满足未来 Windows 版本需求的平台团队。 我们还希望确保我们的平台适用于其他所有人，包括那些拥有自己的品牌和风格并且不想遵循 Windows 风格的平台。 所有这些反馈都非常有价值，我们还将与 Windows 设计团队分享，以确保他们听到操作系统级别的特定反馈，人们希望通过旋钮来自定义它。

谢谢@Felix-Dev、@ Nepxune和@mdtauk ，他们指出了我在接手这个 GitHub 项目时可能不太清楚的事情。 请注意，这是我们在开放社区中讨论的第一个与设计相关的问题，因此我们正在学习……

首先，如果我误导了该组中的任何人，我表示我是一名设计代表，我有权做出并非我本意的更改，如果您觉得浪费了时间，我深表歉意。

谢谢@jevansaks总结了 WinUI 在设计方面的作用。

也就是说，让我澄清一下我自己，因为我欠这个社区。 我是 WinUI 工程团队的项目经理。 我与整个公司的设计团队密切合作，以确保 WinUI 代表 Windows 设计方向以及 Fluent 的设计真理。 例如，就在昨天，我正与 Xbox 设计团队坐在一起讨论这里提出的一些设计更改。 确保它们对 Xbox 开发人员仍然有用。 在 WinUI 团队内部，我以更系统的方式横向和整体监督设计，确保我们不会发布从 UI/UX 角度引入不连贯性的单个功能。

我确实参与了代表 Windows 的 Fluent 设计系统工作，并努力为开发者社区发出强有力的声音。 还要澄清一下，Fluent 设计系统是一项集体努力，Microsoft 的许多团队（设计和工程团队）共同努力实现连贯的系统，我们可以在该系统中作为一家公司提供出色的 UX，并将其提供给像您这样的开发人员。 所以我参与其中并不意味着我可以打电话……在我看来，这个集体中没有一个人可以……这是一种集体努力……

@Felix-Dev ，只是为了让您知道我个人确实与 Windows 设计组织中的某个人讨论过您提出的有关用户设置的概念，以便确认我的回答（例如，没有围绕该问题的功能计划或有兴趣围绕该请求做某事）。 你的意见确实得到了讨论。 我知道这可能并不令人满意，但希望您知道我确实关心您的所有意见，并尽我所能成为这里的代表/桥梁。

大家好，我不是有意关闭issue的。 我试图关闭评论，但不小心这样做了！！

@mdtauk @jevansaks @chigy
我完全同意你的看法，这个讨论应该保持专业。 我们都对 Windows 充满热情，并希望看到 Windows 成为最好的产品。

说清楚，我从来没有指责千草三仙小姐“欺骗”或“误导”我们，也不是我的本意。 我也可以明确地说，我从未亲自攻击任何人，也不会。

然而，最近的对话还表明，这个开源项目仍处于学习阶段。 要成功地将两个世界结合起来，还有很多工作要做——微软公司及其热情的用户，并清楚地了解这种新的开源方法实际上会给社区带来多大的影响，以及相关的 Windows 团队将如何实际处理社区反馈.

总的来说，我已经对当前的状态印象深刻。 WinUI 团队会发出反馈并认真对待，即使不是与实际 WinUI 产品相关的反馈。 我很欣赏这一点，你也尊重我！

不幸的是，这里的这个特例可能会遭受一些症状，即作为一个非常年轻的开源项目，所有参与方仍未充分了解彼此。 我很乐观，我们可以利用这个案例来更好地理解这种新方法对我们所有人的可能性和局限性！

大家好！
非常感谢您的坦诚对话。 我学到了很多东西，我希望您愿意继续与我们合作，共同成长为一个开放的社区！

正如你们中的一些人所指出的，我不清楚 WinUI 团队和我可以做什么和不能做什么，所以让我尝试总结一下你们提出的重要观点和结论。 如果您觉得问题仍然存在，请继续！

请注意，我没有列出我们讨论的所有问题，因为我认为其中一些问题在我们的讨论中已解决。 如果您有其他想法，请告诉我！！

• 确保正在考虑 Xbox (@mdtauk)
  o Xbox 设计归 Xbox 团队所有。
  o 但是，是的，我们确实与他们密切合作。 我确认已经召开了一次会议，我们与 Xbox 设计团队一起审查了这个和即将到来的设计提案。
• 考虑对对齐进行其他与控件相关的更改，例如使边框线更细 (@mdtauk)
  o Windows 设计团队对 Windows 做出最终决定，同时与 Fluent Design System 集体协调以尝试在 Microsoft 设计团队之间保持一致。
  o WinUI 团队将使它更好地为开发人员工作，并有一个很好的开发人员故事来切换（或切换回来）。
  o 这将在即将发布的 GitHub 问题中进行跟踪。
• 社区希望有一个地方可以直接向 Fluent 设计团队（@ mdtauk 、@Felix-Dev、@Nepxune）表达他们的意见
  o 仅供参考，Fluent 团队确实有一个 LinkedIn 群组。
  o 这不属于 WinUI 团队或我自己。
  o 这已引起他们的注意，但如果发生某些事情，我们无法承诺。
  o 如果有事情发生，我一定会回馈给这个小组。
• 我们是否发布了 WPF/WinForms 的 Fluent 主题？ （@Felix-Dev，@mdtauk）
  o 这是我们还没有弄清楚的事情。
  o 这有点复杂。 我是一个正在为 Windows 的整体开发人员寻找设计指导和设计支持的人，所以这符合我关注的领域。 然而，坦率地说，这不是目前的优先事项，因为这不是 WinUI 的工作。
• 用户可以在其中打开/关闭圆角和/或在某个点（@Felix-Dev）/不喜欢圆角，保持它不圆角并为用户提供一个选项（ @Nepxune和人们在红迪网）
  o 不幸的是，这不是 WinUI 的决定。
  o 我现在可以推荐的最好方法是，一旦此更改传播到 Windows 操作系统，您仍然不觉得设计满足您的需求，就打开反馈中心问题？
  o 如果有什么安慰的话，我已经尽力通知了 Windows 团队，但他们的团队没有计划。

这总结了我们目前的计划：

• 使用 WinUI 2.x 获得的控件将更新默认视觉效果以使用圆角。
  o 换句话说，如果您不使用 WinUI 2.x，您将不会获得此更改。
• 大多数控件的圆角值为 2px，弹出式 UI 的值为 4px。 当 UI 与其他 UI 元素相交时没有舍入
  o 这里的视觉合成： https :
  o给与此对话的@Qowy 、 @shaheedmalik 的简短说明。 我们不会四舍五入的内线。 这反映在现有的视觉合成中。 Windows 设计团队已经查看并评估了不同的选项以及优缺点。
• 开发人员有一种方法可以轻松地将其切换回来 (#684)。
• 没有用户设置可以让用户来回切换或进行细粒度的更改。

@chigy感谢您发布的摘要。

我有几个关于接下来会发生什么的问题......

• 这些设计方案是否反映了所有控件的最终设计，或者是否有更多正在讨论的更改将在以后更新或发布？

• 您如何建议我们作为一个社区尝试影响 WinUI 中的一些设计选择或提出建议？

• 我们什么时候才能看到 Windows 设计团队对 Windows UI 的愿景，以便我们可以了解正在处理的控件设计的上下文？

• 是否会努力说服/哄骗/强制使用 XAML 的收件箱应用程序和外壳元素之间的一致性，以便一切都在设计上匹配？

• Xbox 修改后的控件设计会包含在 WinUI 中，还是只会出现在下一个 Xbox 设备上（在 Windows 上开发时无法测试这些控件模板？

@mdtauk ，哎呀，我写的太多了，但我想确保我能很好地解释自己...

• 这些设计方案是否反映了所有控件的最终设计，或者是否有更多正在讨论的更改将在以后更新或发布？

你在比赛中看到的是我们目前所能得到的最终结果。 也就是说，当我们在实际控件中实施更改时，可能会发生一些细微的更改，从而导致设计发生一些变化。 如您所见，comp 并未涵盖所有 UI 出现。 但是，我不希望通过这种特殊的努力...

• 您如何建议我们作为一个社区尝试影响 WinUI 中的一些设计选择或提出建议？

我希望社区告诉我们的是那些设计选择在应用程序中失败的地方。 是否有我们没有为您提供的定制场所？ 它是否出于某种原因完全破坏了您的应用程序？

正如我所提到的，设计决策是由设计团队做出的，但 WinUI 仍然负责为开发人员提供解决方案并确保这是一个合理的解决方案。 因此，可能有机会影响设计输出。 我不会保证会发生任何事情，但是在这种情况下，它如何不起作用以及如何修复它的真实示例最有效......

• 我们什么时候才能看到 Windows 设计团队对 Windows UI 的愿景，以便我们可以了解正在处理的控件设计的上下文？

通过愿景，您的意思是像一个完整的故事，告诉您整个 Windows 中引入的 UI 更改类型？ 你有什么特别的想法？

• 是否会努力说服/哄骗/强制使用 XAML 的收件箱应用程序和外壳元素之间的一致性，以便一切都在设计上匹配？

以下完全是我根据我所知道的情况发表的意见。 只是要清楚... :)
在我看来，问题是双重的。

第一个问题是，我们目前拥有依赖于操作系统版本的新 UI 交付系统。 因此，许多收件箱应用程序无法采用 Shell 正在使用的新样式等，因为它们仍然需要支持旧的操作系统版本。 我们正在尝试通过在 WinUI 中提供新的 UI 来解决这个问题，因此无论操作系统版本如何，您都可以采用这些更改。

第二个问题是它需要文化转变。 我在不同的 UI 平台上工作，包括 Windows Phone，我们尝试使用许多不同的方法来为产品带来一致性。 是这样的……就算你有速度限制，也不是每个人都遵守。 但是我们需要派多少警察来执行？ 我们必须创造一种遵循限速的文化。 这里没有神奇的解决方案。 我希望 Fluent Design System 能够帮助实现这一点。 通过使设计决策更多地是一个系统而不是个人意见。

• Xbox 修改后的控件设计会包含在 WinUI 中，还是只会出现在下一个 Xbox 设备上（在 Windows 上开发时无法测试这些控件模板？

我们没有专门为 Xbox 修改控件的计划。 我们过去没有这样做（我们确实发布了文档）并且没有收到来自 Xbox 团队和社区的任何强烈要求（这是预开源）。

@chigy再次感谢您如此坦率和回应。

我假设下一个 Xbox 也将支持应用程序 - 并且 Core OS 使用 XAML 作为它的外壳 - 这也意味着 Xbox 将像 Windows 一样需要 WinUI 3.0 控件。 因此，包含为 Xbox 设计的模板将简化流程，并使 Xbox 应用程序开发更平易近人——但这显然是其他团队的决定。 😄

至于愿景 - 我的意思是“这就是未来的 Windows Shell 和 Inbox 应用程序的样子。” 以及“我们正借此机会更新我们的 Windows 设计，以下是我们正在进行的一些更改……”

提示图片或视频😃

我也认为 Xbox 和 Windows 应该相互匹配。 我们的 Xbox 应用程序已在 Windows 上停产，但仍存在于 Xbox（CBS、FOX Sports）上或从未存在于 Windows 10（Youtube）上。

如果您不必进行任何类型的 UI 更改，它就会将这些应用程序保留在平台上。

只是我的想法。

我也认为 Xbox 和 Windows 应该相互匹配。 我们的 Xbox 应用程序已在 Windows 上停产，但仍存在于 Xbox（CBS、FOX Sports）上或从未存在于 Windows 10（Youtube）上。

如果您不必进行任何类型的 UI 更改，它就会将这些应用程序保留在平台上。

只是我的想法。

Xbox 应用程序确实需要不同的控制风格和行为。 但是这些应用程序应该能够在 Windows 上运行，只需包含一些允许这些应用程序运行而无需使用 Windows 控件样式的属性。 所以是Xbox First 的方法。

@shaheedmalik和@mdtauk ，关于 Xbox 和 Windows 应该匹配以及应用程序应该在彼此上运行的讨论，我有点困惑。

Xbox 外壳和 Windows 外壳的设计是不同的。 这是故意的，因为它们是独特的产品。 但是我们已经设计了 WinUI 控件，让想要使用一种样式的应用程序只需少量工作即可运行。 几年前，当我们与 Xbox 团队合作时，我们希望确保我们的 XAML 控件（当时没有 WinUI）在电视上正确显示，并发布了我之前提到的关于它的指南。

正确创建的 UWP 应用将在 Windows 和 Xbox 上运行。 对于@shaheedmalik列出的应用程序，它们的品牌非常多，我们经常看到相同的品牌在 Xbox 和 Windows 之间出现。 因此，一种应用程序设计经常在这些设备上运行。

同样，这是圆角话题，所以把它带回来......
这是开发人员在圆角版本发布后需要在 Xbox 上执行的操作。 如果开发人员采用具有圆角功能的 WinUI 2.x，那么如果开发人员想要匹配外壳的样式，则需要关闭圆角样式。 请注意，Xbox 上的许多应用程序都没有......这就是我们为那些关心的人发布指导文档的原因。 当我们发布时，我会确保 10FT 指导文档提到圆角。

至于愿景 - 我的意思是“这就是未来的 Windows Shell 和 Inbox 应用程序的样子。” 以及“我们正借此机会更新我们的 Windows 设计，以下是我们正在进行的一些更改……”

提示图片或视频😃

@mdtauk ，这是我过去问过设计团队的事情，所以我们作为一个平台团队，可以用它来为开发人员传达设计愿景。 据我所知，没有立即的计划，但我可以再查一下。

至于愿景 - 我的意思是“这就是未来的 Windows Shell 和 Inbox 应用程序的样子。” 以及“我们正借此机会更新我们的 Windows 设计，以下是我们正在进行的一些更改……”
提示图片或视频😃

@mdtauk ，这是我过去问过设计团队的事情，所以我们作为一个平台团队，可以用它来为开发人员传达设计愿景。 据我所知，没有立即的计划，但我可以再查一下。

谢谢你。 //Build/ 本来是分享正在计划的更改的绝佳机会，尤其是如果计划在夏季结束时更新这些控件模板以及 WinUI 3.0 的初始版本。

Xbox 外壳和 Windows 外壳的设计是不同的。 这是故意的，因为它们是独特的产品。 但是我们已经设计了 WinUI 控件，让想要使用一种样式的应用程序只需少量工作即可运行。 几年前，当我们与 Xbox 团队合作时，我们希望确保我们的 XAML 控件（当时没有 WinUI）在电视上正确显示，并发布了我之前提到的关于它的指南。

当然，贝壳会有所不同以适应体验。 我唯一的评论是，如果下一个Xbox要鼓励开发应用程序，默认的WinUI控件应该在WinUI中包含Templates和ThemeResources，以便在Xbox上运行时，它们将匹配控件设计的指南。 并且应该可以在开发过程中测试这些控件的外观。 在 Windows 和 XAML 设计器中。

我遇到了一些 Xbox 控件的设计文件，但它们不在 UWP 文档中。

@mdtauk ，我觉得这个关于 Xbox 的对话似乎更适合 #698？ 我已经在 Xbox 中 ping 某人，看看他们是否可以对其他对话发表评论（不承诺:)）。 再说一遍，这是一个开源社区，也许您可​​以创建所述资源并建议我们以某种方式消费？ 就是说...

@chigy这是我提交的一个问题，是为了确保社区添加到 WinUI 的任何控件都应包含在未来 Xbox 控制台上运行的模板。 如果开发人员想将 WinUI 3.0+ 用于他们的 Xbox 应用程序 - 所有控件都应该在电视上运行时调整为看起来正确。

但是随着设计几乎完成，这个问题没有更多的目的——除了在所有模板更新时被标记为完成。

我一直在 NumberBox 控件提交中提交想法，我们希望确保控件的设计与其余控件的计划相匹配。

如果开发人员想将 WinUI 3.0+ 用于他们的 Xbox 应用程序 - 所有控件都应该在电视上运行时调整为看起来正确。

@mdtauk ，正如我之前提到的，这是一个很好的建议，但这不是我们的优先事项，因为除了您自己之外，没有来自 Xbox 团队本身或社区的请求。

更新了 WebView 的 ScrollIndicator 不会通过 XAML 更新的事实，但我们按原样使用 web。

查看 MUXControlsTestApp 中的当前进度条 - 进度值条的右端是否也会被倒圆，还是会保留其平边？

音量弹出窗口中的滑块是否也有样式

显示是默认添加到所有控件中，还是仍然需要通过样式添加？

ColourPicker 中使用的 Sliders 是否会受益于具有类似于 MediaPlayer 的轮廓样式 - 这样它就不会在 Bar 的较暗颜色中丢失？

查看 MUXControlsTestApp 中的当前进度条 - 进度值条的右端是否也会被倒圆，还是会保留其平边？

根据设计定义，它应该。 请针对 MUXControlsTestApp 打开一个问题。

音量弹出窗口中的滑块是否也有样式

由于 shell UI 使用我们的公共控件，所以当我们的控件发生变化时它应该。 但是，如果您没有看到此更新，请打开 FeedbackHub 问题。 这是 shell 团队的工作，它不是 WinUI 团队对优先级和资源做出最终决定的事情。

显示是默认添加到所有控件中，还是仍然需要通过样式添加？

这不是圆角话题。
如果您希望默认将显示添加到所有控件，请打开一个新问题。

ColourPicker 中使用的 Sliders 是否会受益于具有类似于 MediaPlayer 的轮廓样式 - 这样它就不会在 Bar 的较暗颜色中丢失？

MediaPlayer 正在计划遵循新滑块的设计（#841）。 所以你的提议不在计划中。 如果你觉得这是一个可用性问题，请打开一个单独的问题。

哇！ 这里有很多评论。

我认为持续存在的尖角让 Windows 10 看起来独一无二。 如果要引入圆角，则必须对 Windows 徽标、Microsoft 徽标和磁贴进行处理。 一旦你摆脱了诸如瓷砖之类的地铁遗迹，您还需要重新制作Office等倾斜的标志。 我可以继续谈论引入圆角和一致性的影响，但我会在这里剪掉它。

@Poopooracoocoo新的办公室图标/徽标使用圆角，新的终端图标和新的视觉工作室图标/徽标也是如此。

FWIW，我不希望他们摆脱瓷砖，Windows 10 平板电脑用户界面已经够糟糕了，与 Windows 8.1 相比，降级幅度很大

@Poopooracoocoo ， @mdtauk ，
感谢您的反馈意见。 你们都对，必须全面应用变革。 因此，这项工作开始与 Fabric 和其他可见 UI（如 Edge）保持一致。 我们希望一致性在一夜之间发生，但这是一个旅程。 它从这里使用的 UI 平台的默认值（即 WinUI）开始。

状态更新：

圆角半径（又名圆角） How-To 文档 PR已创建。

这将作为文档添加到 docs.microsoft.com。
这将是https://docs.microsoft.com/en-us/windows/uwp/design/style/下的一个新页面

向社区提问：
我正在尝试编写更多的“背景解释 (WHY)”，我们的客户表示，我们在一些焦点小组中提供了我们的文档。 我想要反馈，因为这不遵循正常的文档模式。

这些额外信息是否有用/有用、不相关、缺少其他信息等？

@chigy我对文档的唯一建议是，您没有提到为什么控件将接收圆角。

@mdtauk ，不错的收获。 我有“待办事项”部分（原则）抓住了这一点，但不知何故在编辑过程中，上下文丢失了。 我仍在努力填写该部分。

状态更新

创建了一个单独的问题来跟踪工作以绕过 List 和 GridView 中的复选框 (#1096)

现在检查圆角更改，关闭此问题。

@mdtauk

FWIW，我不希望他们摆脱瓷砖，Windows 10 平板电脑用户界面已经够糟糕了，与 Windows 8.1 相比，降级幅度很大

抱歉现在才回复。 他们真的在摆脱瓷砖！ :(

这是一个有趣的决定，因为 Android 现在只允许自适应图标，类似于 iOS，而 Windows 正在切换到自由形式的图标。 “自适应”图标在闪屏上看起来更好，因为它们有一个单色图标，所以你不需要有一个令人眼花缭乱的白色闪屏。 另一方面，自由形式的图标看起来好多了，因为它们让开发人员可以更好地控制图标，并且它适合桌面平台（标题栏、任务栏之类的东西）以及 win32 应用程序。

Office 图标本身看起来不像 Word 或 PowerPoint 的图标。 有了这些变化，我觉得微软正在失去它的身份

@Poopooracoocoo我仍然希望有一个选项可以使用

@Poopooracoocoo和@mdtauk ，请在反馈中心提交反馈以进行磁贴讨论，因为 WinUI 团队不参与磁贴，也不了解计划。

@Poopooracoocoo和@mdtauk ，请在反馈中心提交反馈以进行磁贴讨论，因为 WinUI 团队不参与磁贴，也不了解计划。

我已经提交了关于保留磁贴的反馈 - 有很多赞成票的集合。 反馈中心不如 GitHub，因为几乎没有来自 Windows 开发团队的反馈或讨论贡献

您好，如何禁用舍入？ 当圆形按钮具有圆形工具提示时，它看起来很难看。

@kikisaints @chigy有没有办法禁用圆角，例如@mklemarczyk要求的特定元素？

您好，如何禁用舍入？ 当圆形按钮具有圆形工具提示时，它看起来很难看。

@mklemarczyk您是否尝试过在控件的样式中将 CornerRadius 值设置为 0？ 您可能必须在 App.xaml 中执行此操作才能影响所有 ToolTip 控件。

@kikisaints @chigy有没有办法禁用圆角，例如@mklemarczyk要求的特定元素？

@mklemarczyk ，你看过我们的指导文档吗？
https://docs.microsoft.com/en-us/windows/uwp/design/style/rounded-corner#page -or-app-wide-cornerradius-changes

@mklemarczyk您可以使用ToolTip.CornerRadius属性或 OverlayControlResource 作为两个选项来更改工具提示控件的角半径。

Control.CornerRadius属性自 Windows 1809 起可用，您可以像这样使用它：

<Application.Resources>
    <Style TargetType="ToolTip">
        <Setter Property="CornerRadius" Value="0" />
    </Style>
</Application.Resources>

这会将应用程序中的每个工具提示的角半径设置为 0。

或者，您可以使用

<Application.Resources>
    <CornerRadius x:Key="OverlayCornerRadius">0</CornerRadius>
</Application.Resources>

请注意，这不仅会设置应用程序范围内工具提示控件的圆角半径，还会设置使用此资源的所有其他控件（如 ContentDialog 和使用弹出窗口的控件（如 ComboBox））。 也就是说......理论上覆盖资源似乎不会影响这些控件，即使它应该（工具提示有效）。

来回如此之多以至于很难知道关于其他输入和圆角半径的决定是什么，但很快，在迁移 UWP 项目以专门使用 WinUI 3 后，我注意到只有按钮应用了圆角半径（以及其他更改，如增强显示等），但我的其他输入控件（例如组合框）保留了地铁外观（更暗/更厚的边框和 90° 角）。 这是故意的，WIP 还是错误？ 另外，为了让组合框匹配我最终需要使用 3epx 的圆角半径的按钮，尽管我在网上看到的所有内容都说新的默认圆角半径是 4epx？

来回如此之多以至于很难知道关于其他输入和圆角半径的决定是什么，但很快，在迁移 UWP 项目以专门使用 WinUI 3 后，我注意到只有按钮应用了圆角半径（以及其他更改，如增强显示等），但我的其他输入控件（例如组合框）保留了地铁外观（更暗/更厚的边框和 90° 角）。 这是故意的，WIP 还是错误？ 此外，为了让组合框匹配我最终需要使用 3epx 的圆角半径的按钮，尽管我在网上看到的所有内容_说_新的默认圆角半径是 4epx？

如果您发现 WinUI2 和 WinUI3 在样式方面存在差异，能否请您开一个新问题？ 从 WinUI2 到 WinUI3 的样式合并可能是一个错误。