【提案】Desk的一些紧迫的优化

[Gaubee]

1. 我发现，大部分人不会去点击展开“taskbar”。
   1. 而是会去点击右下角的“取消窗口最大化”的按钮，
   2. 然后再去点击“关闭”窗口的按钮，
   3. 从而看到桌面，
   4. 然后再去操作桌面按钮
2. 即便是我们内部开发者，即便打开了 taskbar，也很少回去点击“home”按钮来显示桌面去做进一步的操作。
   1. 更多是点击“窗口最小化”或者“窗口关闭”的按钮去隐藏窗口，从而做进一步的动作

---

“home”按钮的主要职责是“显示桌面”，任何要和桌面直接交互的行为，“home”按钮要成为用户最自觉的路径

因此这里有几个点需要去优化：

• [x] “home”按钮需要始终显示，即便是最大化的情况下
• [ ] “home”按钮需要显示得更加的直观易用，这需要新的设计
• [x] “取消窗口最大化”的按钮很容易跟 IOS 的底部 taskbar 冲突，误触率非常高，因此 windowBottomBar 的高度的算法应该继续改进优化

[waterbang]

优化三步走

• 动画的反馈，icon的反馈，加载的反馈，震动的反馈将极大的提升用户体验，可以让整个app体验上一个台阶。

  1. 比如点击app的震动，长按app的震动，点击browser图标的震动
  2. 加载的进度条，错误的处理。
  3. 桌面背景，桌面搜索的优化，原生语言的编写，能极大的提升流畅程度和发挥各个平台优势。

• 隔绝app的请求异常，防止内置app 影响整个app，以及对整个网络错误对用户的反馈 见 #105

• 我们整个应用为dweb_browser,因此对内置browser的优化也很重要，经过测试语言大模型llama-7b微调完差不多在17mb, 内置还是能接受，但是还需要进一步的调试，最好的效果是让用户把dweb_browser设置为默认app.

这样整个dweb_browser算是站稳了脚跟，打好了地基，这样我们模块的搭建会更加的得心应手。

接下去就是网络层对接，这是背靠我们整个底层的，当做完网络层的时候，整个dweb_browser的灵魂也就有了。

[Gaubee]

优化三步走

• 动画的反馈，icon 的反馈，加载的反馈，震动的反馈将极大的提升用户体验，可以让整个 app 体验上一个台阶。

  1. 比如点击 app 的震动，长按 app 的震动，点击 browser 图标的震动
  2. 加载的进度条，错误的处理。
  3. 桌面背景，桌面搜索的优化，原生语言的编写，能极大的提升流畅程度和发挥各个平台优势。

• 隔绝 app 的请求异常，防止内置 app 影响整个 app，以及对整个网络错误对用户的反馈 见 【增强】内部的 app 不应该去影响整个 dweb_browser 的行为  #105

• 我们整个应用为 dweb_browser,因此对内置 browser 的优化也很重要，经过测试语言大模型 llama-7b 微调完差不多在 17mb, 内置还是能接受，但是还需要进一步的调试，最好的效果是让用户把 dweb_browser 设置为默认 app.

这样整个 dweb_browser 算是站稳了脚跟，打好了地基，这样我们模块的搭建会更加的得心应手。

接下去就是网络层对接，这是背靠我们整个底层的，当做完网络层的时候，整个 dweb_browser 的灵魂也就有了。

这些提议都很不错，很有价值。 具体的工程化方面，我觉得，首选实现一整套“高定组件”（高度定制化的组件库）是很有必要的, 并且使用原生的绘制技术，这也至少可以解决 UI 标准化开发的问题。这个工作其实很困难，也很难找到成品参考，原因如下：

1. 因为我们希望在每个平台上用每个平台的最佳实践来做，而每个平台都有很大的差异
2. 跨平台这个技术总体来说经历了这几个阶段：
   1. “画布组件+脚本代码”代表：Web
   2. “原生组件+脚本代码”代表：ReactNative、NativeScript、Weex
   3. “画布组件+原生代码”代表：Flutter、ComposeMultiPlatform
   4. “原生组件+原生代码”代表：MAUI、Kotlin？、Rust？
3. 目前我们的追求就是“原生组件+原生代码”，而这方面微软自己也海没完全搞明白，Kotlin 只是技术上理论可行，而我们需要短期落地，就不可能是类似 MAUI 那种“框架化”的技术路径，而仅仅只能是“高度定制化”的成品组件，不能有太多的可微调的空间。
4. 目前我们 Desktop 用的是 Web 来做跨平台，这是一种短期妥协，未来随着我们架构的进步以及 Kotlin 的完善，我更希望能真正意义上做出原生级别的体验。那么也就意味着平台的差异性会进一步撕裂我们的高定组件的设计。

---

另外，以我目前的认知，可能把这些高定组件的“指令”封装成 Compose-DwebUI ，就像 Compose-Web 那样，并没有 Modifier，而仅仅只有我们开发的少量属性，对我们来说是目前最好的选择。理由有两点：

1. 它真的能短期落地
2. 对于 Web 平台来说，可以有效实现在 nodejs 层开发 browser 层的界面

---

另外 随着 DwebUI 的完善， 我希望可以开放给 jmm 开发者，它们也能享用这套“原生组件”。 我之前有聊过很多关于 DwebUI 的幻想，比如想用 SVG 来做底层技术来打通从产品到设计师到开发者的链路等，但归根结点，想要有竞争力，短期内还得是“原生组件”这个路径

---

关于语言模型，我的建议是我们内置执行器，但不内置模型。一方面节省空间；另一方面有更加开放自由度，用户可以去共享自己的微调模型，桌面用户也可以使用更大的模型。 另外我们可能还得参考 OpenAI 的 API 风格来提供接口。 同时我也希望开发者能真正用得上这个接口，正如我之前所想的，AIGC 应该作为一个操作系统接口提供给开发者，我们的责任只是“垫片”+“标准化”。 有了这两者，Dweb 生态就能孵化出 AI 应用。至于底层实现，可能是用户自己下载的模型，也有可能是连接到自己的个人电脑，也有可能是连接到第三方比如 OpenAI。