Fluent Design System 以来微软设计和 Windows 11 以来第一方 Windows 程序 UX 和 UI 的变迁

文件资源管理器工具栏的宽度终于正常了

题外话，关于文件管理器现代化，你们认为如何处理树状视图功能的现代化？起因是这样的，我看到了 Files 项目里关于树形视图方案产生了严重的分歧，我自己看着也觉得这个东西需要更多的讨论与内容（于是乎索性搬了个大概的过来反正 Explorer 未来大概率也会遇见）。树形视图就是以文件树的方式显示文件夹的层级，一般而言有两个方案：

1. 一个是 Explorer 的导航侧栏方案，这个方案把树状导航做到了侧面，提供导航（展开、收起）和可能的拖拽功能等。
2. 一个是 Finder 的嵌入文件内容的方案，这个方案将文件目录树与文件夹内容结合到了一起，保留了侧边栏的快捷方式。

很多人认为，Explorer 的侧边栏树形视图会导致屏幕的一侧过于拥挤，在不同目录导航和使用时让屏幕利用率和留白时上时下，想要舒适的显示密度（也就是侧边栏宽度）还需要手动调整或者干脆关闭，这样做会导致混乱与降低效率。

（图直接来自 Github，打不开就开点魔术）

更多人倾向于 Finder 的方案，这也是近年很多 Linux 选择的方案，但也有 Explorer 的死忠粉觉得这不符合 Windows inbox app 的逻辑，对于只使用 Windows Explorer 的用户而言不太习惯。

（图直接来自 Github，打不开就开点魔术）

这是一个很现实的问题，因为如果用户需要一次性在多个层级间查看，管理、移动文件夹，文件夹树是一个很符合直觉且高效的功能。
WinAppSDK 1.7 将会上 TabieView，这可能标志着 Explorer 现代化文件查看区域开始（至少也是一步了），未来侧边栏的现代化也一定会展开，在此之前，我想问问论坛里的用户（重度软粉）：

• 你们是否使用树形目录的功能？在什么样的环境下？
• 你们对于 Explorer 与 Finder 的树形视图各有什么样的看法和观点？
• 你们认为如果未来 Explorer 进行大规模现代化改造，应该如何处理树形视图？

当然，如果你对 Files 的开发和规划感兴趣，也欢迎去原帖看看。

Stakarilky 实际上 Explorer 的树形方案争议我记得很早就有了，在 2018 年推出 FDS 的时候，当时微软放出很多文件管理器现代化的图片，都没有侧栏树形方案，当时在推特上还引起过争议，不过现在也都找不到了。

Stakarilky Explorer的树状图只显示文件夹，不显示文件……

Stakarilky 安装不了

Stakarilky 这里下载？
https://archive.org/details/wlsetup-all_201802

Stakarilky 卡44%

Stakarilky Menubar 和 caption 合并，menubar 置于 app icon 的右侧，caption text 居中，右边是三个窗口控制(Edit 控制按键)，这种合理利用空间的布局让应用看起来更舒适。

VSCODE类似

Stakarilky 我还注意到微软在规划 TableView，听名字应该是类似 DataGrid 的控件（此前 WinUI Community Toolkit 里移除了 DataGrid），这或许是为 Explorer 现代化的文件显示区域铺路？

CommunityToolkit也搞了一个轻量化的DataTable，而且支持uwp/winui2

Betta_Fish 感觉这个更像是 iPad OS 的 Column，Explorer 的列是可以按条件筛选的，当前我更倾向于第三方的 TableView

好像没人提，微软的 React Native 库已经用上了类似 Windows 11 原生设计的 Fluent 2，看 Gallery。

这玩意是真的丝滑，比 WinUI Gallery 丝滑了很多，不愧跟 Metro UI 一样是 JavaScript Powered。

Stakarilky 开发 Windows 11 设计规范的现代程序从来没有这么多框架，光是官方的就有：

WinUI 3、WinUI 2、Xaml Island、WPF UI、React Native
---

彩蛋内容：当 WASDK 重归桌面端发展时，React Native 依旧保持了 XBox 支持

Stakarilky 虽然老实说XAML Islands是WinUI 2/3的一部分

何木槿 主要 Xaml Islands 可以糊到 WinForms 上去

MS甚至不愿遵守自己的设计规范...
Wasdk 1.6的TitleBar控件: