应添加指向 Van Arsdel 示例的链接

我认为 Toolkit 中更通用的控件应始终找到移植到 C++ 并在 Windows UI 库中可用的方式。 选项卡控制何时足够成熟和稳定也应该发挥作用。

它发生在主菜单控件上:)

链接到提案中提到的标签撕下样本。

链接到提案中提到的标签撕下样本。

撕下选项卡是否会产生新的 AppWindow、新的 CoreWindow，以及如何处理不存在新窗口 API 的回退？

@mdtauk该示例当前使用较旧的多窗口 ApplicationView API，窗口在默认位置而不是拖动位置创建。 我一直在使用 AppWindow 进行测试，并希望更新新 SDK 的示例。

“虽然这些变通办法有助于弥合 WPF 的平台差距，但它们有许多限制，包括：”

您也应该在此处列出键盘输入。 这不仅仅是 Tab 键或快捷键。 当我们没有标签控制时，箭头是我们挣扎的事情，我们必须让每个人都保持一致，因为缺乏它。

对我们在工具包中听到的未解决问题的评论：

1. Tab Tearoff 应该是控件处理的还是应用程序处理的？

我认为 Tab 控件处理 TabView 之间的拖动和重新组合（承载相同的数据类型）以及公开拖出事件以及检查/拦截的能力非常重要。

但我不知道 TabView 是否也直接管理窗口生命周期很重要，因为这变得更加棘手。 开发人员可能还希望自定义将选项卡拖出时发生的情况，也许只是将其删除，或者为该内容创建一个特殊窗口与带有选项卡的新“主”窗口？ 或者他们可能不想处理必须为多个窗口编写代码的问题。

公开事件并拥有帮助程序（或利用现有的帮助程序，如 Windows Template Studio 中的帮助程序）可能更容易帮助创建/管理 Windows。 这个场景中最棘手的部分是线程之间的“数据传输”，至少新的窗口 API 应该有助于缓解这种情况。

1. 是否应该有一个内置的“添加新标签”按钮？ （我怀疑可能不是，因为控件不拥有选项卡的集合。）

我认为只要有足够的标题模板和示例，让实现者添加一个“添加”按钮是微不足道的，所以我认为它不需要内置，因为范式需要另一个事件。 这也是我们最初在工具包中想到的。 :)

1. TabItem.Icon 应该是 IconElement 还是 IconElementSource？

我们使用IconElement来模拟 NavigationViewItem 的属性。 此外， IconElementSource是IconElement ，所以IconElement不是更好，因为它更广泛？ 如果 WinUI 中有一个IconElement子类可以直接托管Image （类似于BitmapIcon但没有强制屏蔽），那就太好了。 这样，Icon 属性可以承载任何东西，无论是漂亮的矢量符号/字体图标还是 ico/png 文件（想想浏览器类型的场景图标）。

1. 应用程序如何自定义 Selected 选项卡的外观（即在 Edge 中）？

您是在谈论可以修改的公开样式属性还是所选项目的完全不同的模板？

1. API 目前从 Toolkit 中获得了很多灵感。 有没有机会迭代/改进？

我们得到的一项反馈是关于自定义选项卡末尾的空间。 例如，它是否应该只是一个模板区域，然后可以使用左/右水平对齐将东西粘贴到边缘而不是两个单独的区域？

其他问题：

• [ ] 有趣的是关于如何处理拖入内容区域与标题以及两者都是目标？ 如果应用程序希望允许在选项卡区域中放置其他内容（例如资源管理器中的文件）怎么办？
• []是“应用程序可以决定标签的位置/大小”在谈论TabStripPlacement属性吗？

还忘了提到要求 9，我们最初讨论过是否使用 Edge 模型（如工具包控件当前的行为）或 NavigationView 模型，它会在其中创建一个下拉 V 形。 我们想也许将来我们会同时支持两者。

我们最终选择了 Edge 模型，因为它实现起来更简单，因为那时我们不需要SplitObservableCollection类型的对象。 我已经开始研究一个作为测试，但我想知道它是否是一个有用的公开结构？

@stmoy您是否关闭了我们从工具包设计中获得的上面未解决的问题/反馈？

Windows Sets 放弃 Edge Tab 模型的消息如何影响该控件的开发方式？

使用 Edge 和它的 UI 现在几乎放弃了 ChromiumEdge (Edgium) 我们是否需要/想要重新考虑此控件的外观或行为以更适合可能使用它的应用程序类型？

• 属性对话框；
• MDI（多文档界面） - 像 Photoshop；
• 停靠的工具面板（Visual Studio/Blend/Adobe CC）；

更不用说类似的控件，如 Pivot 和正在开发的 UWP 功能区。 哪个用例被推荐，为什么有人会选择一个而不是另一个？ 指导和示例应该清楚地回答这些问题，以避免混淆或使用更重的控件而不是高性能和更轻的控件。

第一方控制应将正确的控制用于正确的目的，以尝试在一致使用中引领潮流。

在 #629 @mdtauk有一个功能建议：

也许是 ToDo 列表的一个想法。 标签放置？ 下，左，右。

是的，选项卡放置在某些时候应该在优先级列表中，以匹配 WPF 奇偶校验迁移方案。 不过，我们也没有时间在初始 Toolkit 版本中添加这些内容。

当我们确定此功能的范围时，支持“属性表选项卡”方案并专注于浏览器选项卡方案已成为非目标。 我们确实看到了与属性表的一些重叠，但属性表隐喻不是流畅设计的一部分，我们现在有用于该场景的 NavigationView（具有左/上模式）。

Navigation View 是一个很重的控件，想要占据整个屏幕。 Sets 也从路线图中消失了，Edge 的 XAML 版本也是如此。

因此，可能需要重新考虑 TabView/Control 以使其在未来更加灵活和有用。

如果 TabView 控件能够隐藏添加和关闭按钮，则这些场景在 UWP XAML 应用程序中是可能的。

但也有 Pivot 控件，但它只支持顶部的枢轴标题，并且选项卡可以在顶部、底部、左侧或右侧...

在我们支持的工具包中没有关闭按钮，添加按钮也是实现者必须自己添加的东西。 这就是为什么我们有TabWidthBehavior属性来帮助在文档和经典选项卡之间设置这些不同模式的原因。 我们还不支持的主要内容之一是标签定位。

感谢所有精彩的对话！ 绕回来……

关于如何处理拖入内容区域与标题的拖动很有趣，两者都是目标？ 如果应用程序希望允许在选项卡区域中放置其他内容（例如资源管理器中的文件）怎么办？

有趣的问题。 天真地，我认为它们都是相同的（大）目标，因为 TabControl 承载 Tab 条区域和内容区域。 但是，当考虑像 Edge 之类的应用程序时（作为示例），这个模型就崩溃了。 如果 Edge 已最大化并且用户将选项卡拖出选项卡条但仍位于内容上方，因为它是最大大小，则用户希望选项卡创建一个新窗口。

因此，我认为我们应该只将标题区域/标签条作为拖放目标。

“应用程序可以决定标签的位置/大小”是否在谈论 TabStripPlacement 属性？

这是为了描述“TabWidthBehavior”属性和枚举，而不是 TabStripPlacement。 我更新了要求并添加了选项卡放置要求（在下面讨论更多）。

Sets 已从路线图中消失，Edge 的 XAML 版本也是如此。

现在这项工作的主要动力实际上是新的Windows 终端应用程序。 我们将继续扩展/探索其他应用程序以使用 Tab 控件，但我们的主要重点是暂时启用它们的场景。

选项卡放置应在优先级列表中的某个位置与迁移方案的 WPF 奇偶校验匹配。 不过，我们也没有时间在初始 Toolkit 版本中添加这些内容。

选项卡放置是一个很棒的想法，特别是它与 WPF 奇偶校验有关。 然而，根据上述内容，由于我们主要根据终端的需求来确定范围，这最终更像是“可能”而不是“需要”。 也就是说，我将它添加到上面的要求表中。

如果 TabView 控件能够隐藏添加和关闭按钮，则这些场景在 UWP XAML 应用程序中是可能的。

TabControl 支持在选项卡本身上隐藏关闭按钮。 此外，“添加”按钮将由应用程序本身（而不是控件）提供，因此我们希望能够使用上面指定的控件制作属性样式的选项卡场景。

如果添加选项卡按钮不是控件的一部分，我是否建议在控件中包含按钮样式和 XAML 命令，以使人们更容易在使用控件的任何地方一致地实现按钮。

@stmoy对于拖动场景，我认为在某些情况下拖动到标题和区域可以不同或相同。 如果一个示例可以显示拖拽的拖拽效果会很好，但也可以在主要内容区域中放置一个文件以及如何捕捉它（这可能超出了控件本身的范围，但很有用到它的用途）。

按钮样式和 XAML 命令 [用于添加新选项卡]

@mdtauk - 好主意。 我会把它添加到规范中。

如果一个样本可以显示拖拽的拖拽效果会很好，但也可以在主要内容区域放置一个文件以及如何捕捉它

@michael-hawker - 同意，样品值得。 我不知道它是否需要特定于选项卡，因为拖动文件将由内容区域处理。

大家好，只是想让您快速了解一下，我正在迭代目前针对PR的 Tabs规范。 如果您有任何反馈，请在 PR 中添加评论！

手指交叉，他们感觉更像 Chrome 的标签而不是 Edge 的。

手指交叉，他们感觉更像 Chrome 的标签而不是 Edge 的。

我们希望交互设计“感觉良好”，因此请务必提交针对预览版的具体反馈的问题，以便我们可以在发货前正确处理！

不确定像@chigy这样的

我不喜欢关闭按钮悬停/按下状态更改按钮的背景而不是其前景。 改变背景会增加对按钮的强调（并且远离标签标题），而后者也会更加优雅。

例如，请参阅 Edge UWP 中的关闭按钮（仅限前景更改）或 Edge (Chromium) 中的选项卡音频静音按钮。

我确实考虑过坚持使用前景更改，但觉得背景更改将与其他控件和标题栏行为一致 - 但默认情况下它可能只是前景。

@mdtauk - 你摇滚。 感谢您创建这些设计组合。 虽然我们不会为控件的第一滴做侧面放置，但很高兴看到它会是什么样子。

@chigy和我正在合作构建一些符合 Windows 原则的设计组合（包括圆角、标准阴影等），但您提供的设计组合将有助于激发我们的灵感。

我不喜欢关闭按钮悬停/按下状态更改按钮的背景而不是其前景。 改变背景会增加对按钮的强调（并且远离标签标题），而后者也会更加优雅。

我们目前的想法只是改变前景色而不是背景，正如这里所建议的那样。 这有一个额外的好处，那就是更好地适应我们正在考虑的圆角。

Edge 选项卡在关闭字形后面使用背景，但它比我建议的要小 - 但 Edgium 选项卡尚不支持任何触控模式。

当我们在考虑工具包设计的侧选项卡时，我们在使用旋转文本垂直执行它们（如@mdtauk所示）或仍然将它们保持水平并像 OneNote 那样在左侧/右侧占据更大的边距之间左右为难。在他们最新的重新设计之前，类似于 WPF（我们认为这对兼容性很重要）。

所以，我建议像 WPF 那样使用宽边​​距和水平，但也只是让它超级简单地支持两者，如图所示，这是支持 #546 的另一个原因。

@michael-hawker 我赞成在右边有宽边距的垂直标签列表，并且可以像在 Visual Studio 中一样轻松地旋转它们。

它会影响标签点之前和之后的位置，但我会在周一回家时考虑做一个设计模型

它会影响标签点之前和之后的位置，但我会在周一回家时考虑做一个设计模型

我在家，这是那个设计：

我已经改进了控件的设计模型。

_添加了选项卡溢出和选项卡大小_

就像您的选项卡概念看起来更像 Edge UWP 选项卡而不是 Edge Chromium 选项卡。 IMO 选项卡控件的外观应尽可能接近 Edge UWP 中的选项卡控件。 Acrylic 作为 Edge UWP 中的选项卡控件背景也很不错。

我仍然希望选项卡关闭按钮可以像 Edge UWP 中那样制作，其中该按钮仅针对当前选定的选项卡或选项卡鼠标悬停显示。

对于 WinUI 团队： @stmoy显然 Windows 终端团队不能使用丙烯酸作为选项卡控件的背景（请参阅 https://github.com/microsoft/terminal/issues/1375）。 终端团队声称这是由于架构限制。 WinUI 团队可以提供帮助吗？ 在 Edge UWP 中，似乎有不少人喜欢标签控件的丙烯酸背景。

@Felix-Dev 我知道 Edgeium 是新的设计，但我认为 UWP Edge 设计更好一些 - 所以我想尝试弥合这一差距

我仍然希望选项卡关闭按钮可以像 Edge UWP 中那样制作，其中该按钮仅针对当前选定的选项卡或选项卡鼠标悬停显示。

CloseButtonOverlay是我认为可以做到的属性

@mdtauk
为了澄清，我希望看到 CloseButtonOverlay = OnHover 成为选项卡控件的默认值，而不是在所有选项卡上不断显示关闭按钮（不必要地从选项卡标题 imo 中占用空间）。

始终可见最适合触摸用户，因此我认为默认值应尽可能具有包容性

也许关闭按钮的覆盖模式可以取决于用户显示器的功能呢？

不确定这是否会以某种方式成为问题，因为根据显示类型，选项卡控件中会有轻微的视觉差异。

也许关闭按钮的覆盖模式可以取决于用户显示器的功能呢？

不确定这是否可能是一个问题，因为根据显示类型，选项卡控件中会有_slight_视觉差异。

这适用于弹出窗口之类的事情，因为它可以检测触发它的输入类型，如果被触摸输入召唤，则提供更大的触摸目标。

这不适用于始终可见的控件，因为某些触摸设备还会连接鼠标。

开发人员当然可以更改默认选项，如果应用收到大量反馈，要求关闭按钮仅在悬停时显示 - 那么他们可以选择更改它。

我为 Tab 溢出添加了一个想法

喜欢这个。

只是一件小事。 当有阴影和圆角时，我们可能希望在选定的选项卡项和背景边缘之间留一点间隙。

喜欢这个。

只是一件小事。 当有阴影和圆角时，我们可能希望在选定的选项卡项和背景边缘之间留一点间隙。

好奇为什么需要这样做......阴影不会被 Window 框架裁剪吗？ 这只是一种审美选择，所以阴影在上方可见吗？

标签尺寸

@mdtauk ：我喜欢看这些设计！ 我有几个试探性的问题：

• 紫色是重点色吗？
• 溢出屏幕截图的目的是显示保险杠吗？ 我只是想确保我正确地阅读了图片。
• 标签的圆角半径是多少？
• 标签的高度是多少？
• 使用了什么字体大小？

我将使用这些设计在终端上与我们的朋友交谈，看看他们的想法。 这些设计包括我们当前方向的一些增量，但我们将使用这些来帮助促进对话。

@Felix-Dev：感谢您的反馈； 在下面解决您的一些观点。

就像您的选项卡概念看起来更像 Edge UWP 选项卡而不是 Edge Chromium 选项卡。 IMO 选项卡控件的外观应尽可能接近 Edge UWP 中的选项卡控件。 Acrylic 作为 Edge UWP 中的选项卡控件背景也很不错。

我们正在积极与各个团队（包括终端和边缘团队）进行迭代，以尝试在这些应用体验中调整选项卡。 随着我们继续迭代（并实现#524 之类的项目），Tab 控件设计将与更新后的控件更加一致。

我仍然希望选项卡关闭按钮可以像 Edge UWP 中那样制作，其中该按钮仅针对当前选定的选项卡或选项卡鼠标悬停显示。

在短期内，我们将专注于实现终端需要的场景并在适当的情况下调整 API 表面。 对于 v1，我们将仅支持 Persistent。 也就是说，我最初也指定了悬停行为，因为我认为这是一个好主意。 我正在跟踪这些类型的请求（例如 x-on-hover、选项卡放置等），以便我们可以在控件的下一个版本中重新评估。

对于 WinUI 团队： @stmoy显然 Windows 终端团队不能使用亚克力作为选项卡控件的背景（参见 microsoft/terminal#1375）。 终端团队声称这是由于架构限制。 WinUI 团队可以提供帮助吗？ 在 Edge UWP 中，似乎有不少人喜欢标签控件的丙烯酸背景。

我们正在积极与终端团队合作。 不幸的是，这种情况是 Xaml Islands 而不是 Tabs 的已知限制的结果。 如果应用程序将 TabControl.Background 设置为丙烯酸画笔，我们预计非终端应用程序应该能够使用丙烯酸背景作为“选择加入”功能。

紫色是重点色吗？

是的 - 我不想将我的设计与官方设计组合混淆

溢出屏幕截图的目的是显示保险杠吗？ 我只是想确保我正确地阅读了图片。

是的，正在显示左右按钮的外观，以及标签的剪裁方式。

标签的圆角半径是多少？

4 epx - 我知道指导是 2epx，但所选指标的 4epx 高度在 4 时看起来更好

标签的高度是多少？

40 人

使用了什么字体大小？

14 用于选项卡标题文本，16 用于 MDL2 图标

在 Edge Canary 中有一个名为New tab-loading animation的标志 - edge://flags#new -tab-loading-animation

部分规范应包括主题和/或隐式动画，例如：

• 标签添加动画
• TabRemove动画
• TabSwitchToAnimation
• TabSwitchFromAnimation
• TabSelectedSwitchToAnimation
• TabSelectedSwitchFromAnimation
• TabDragOut动画
• TabPlacedAnimation

@stmoy

我们正在积极与终端团队合作。 不幸的是，这种情况是 Xaml Islands 而不是 Tabs 的已知限制的结果。

是否有可能在 Xaml Island 的未来版本中解决此限制？ 例如，在 Windows 终端应用程序中似乎对背景丙烯酸有强烈的需求。 请参阅https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390，尤其是该帖子中的最后一张图片（标题栏中带有背景丙烯酸）。 另请注意该帖子获得的许多赞成票😉。 另一个有很多赞的帖子： https ://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

更广泛地谈论选项卡 UI 设计，还要注意对用户评论的支持性反应，他们更喜欢 Edge UWP 选项卡而不是 Edge Chromium 选项卡外观： https ://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 和直接在它下面发帖。

如果 Edge Chromium 选项卡旨在代表（现代）Windows 选项卡的未来外观，那么那些压倒性的用户反应可能是重新考虑 Edge Chromium 和 WinUI 中使用的选项卡外观的原因。 （还在这里添加@chigy ，这样她就可以注意到 Windows 终端存储库中的那些选项卡 UI 反应。）

编辑：还提请@marb2000关注这个话题，因为 Windows 终端团队刚刚重申他们“无法解决”这个问题。 WinUI 团队如何看待 Windows 终端出现丙烯酸标题栏（强烈要求！）的机会？ @stmoy

@ marb2000 @stmoy请在以下问题的评论：

还呼吁@ marb2000注意这个话题，因为Windows终端队只是重申他们“将无法修复”这个问题[（在末端丙烯酸标题栏）。 WinUI 团队如何看待 Windows 终端出现丙烯酸标题栏（强烈要求！）的机会？

@marb2000 @SavoySchuler @jesbis @jevansaks

从最近的社区电话中联系了你们中的每个人😁
关于 Xaml Islands（Windows 终端）中的技术丙烯酸标题栏支持，请参阅我上面的帖子， @stmoy已经部分回答了这些帖子

以下是我的帖子和上面的回复中的三个要点：

对于 WinUI 团队：显然 Windows 终端团队不能使用亚克力作为选项卡控件的背景（参见 microsoft/terminal#1375）。 终端团队声称这是由于架构限制。 WinUI 团队可以提供帮助吗？ 在 Edge UWP 中，似乎有不少人喜欢标签控件的丙烯酸背景。

由@stmoy回复：

我们正在积极与终端团队合作。 不幸的是，这种情况是 Xaml Islands 而不是 Tabs 的已知限制的结果。 如果应用程序将 TabControl.Background 设置为丙烯酸画笔，我们预计非终端应用程序应该能够使用丙烯酸背景作为“选择加入”功能。

我的问题：

还请@marb2000关注这个话题，因为 Windows 终端团队刚刚重申他们“无法解决”这个问题 [（终端中的丙烯酸标题栏）]。 WinUI 团队如何看待 Windows 终端出现丙烯酸标题栏（强烈要求！）的机会？

谢谢回复😁