【讨论】 🎉 `dweb+protocol://splashscreen.window.std.dweb/`

[Gaubee]

✨ 这是一个渲染器，一般用于提供启动屏的渲染功能，它提供了类似 css-background-image 的声明式渲染，并且接口的设计上也进行了一定的借鉴
参考资料 Web-CSS-Background

1. /render?query=*&color=*&image=*&position=*&size=*

   🔊 增加 MicroModuleManifest.mainWindow 字段，可以配置应用启动的时候默认视图的 URI，从而可以将视图委托给第三方模块来渲染，为此可以可以实现将快速将一个 Web 打包成一个 App 的功能

   1. CSS-Background 中，它可以提供多个 background（使用,分隔），正常情况下，这些 background 是叠加在一起的
   2. 这里额外提供了一个 query 字段，参考 container-query，同样我们也使用,分割，并将匹配的 background 进行显示，如果不提供默认为匹配成功
   3. 🔊 我们是否要直接使用 js-disabled 的 webview 进行渲染（我们自己进行 html+css 的翻译），还是用原生实现只提供一个子集？

另外还需要探讨的是，如何将它与 window.std.dweb 进行合理的集成，从协议层面应该怎么设计，从代码层面应该怎么设计，如何将它们有序地进行串联。

[waterbang]

1. 在首次渲染的时候去弹出splashscreen，其他隐藏窗口的时候就不弹出了，因为内容渲染很快。
2. 在首次创建窗口的时候，会去windowAdapterMenager调用createWindow 认为可以在beforeCreateWindow的时候，去处理这个启动屏，并且用户可控。
3. 认为这个启动屏渲染协议可以写入到plaoc.json的配置文件里(或者manifest.json但是规范里没有，plaoc.json会好些，因为启动屏都是 plaoc应用在使用)，在用户代码还没有被渲染的时候去处理。进而我们只需要去读取配置文件的时候去处理。
4. 如果我是开发者，我第一眼看到 /render?query=*&color=*&image=*&position=*&size=* 是没有办法第一时间构思出我这个启动页面的，如果能有一个工具，能帮我把ui给的启动页设计图，直接变成我需要的，或者直接而言，偷懒的方法，使用一张svg去渲染，所见即所得，不用再去编码这个启动屏。
5. 认为用webview进行渲染，当前可以先使用原生的一个子集，当这个承载不住了，我们也可以自己进行html+css翻译，去获得我们要的效果。弊端是如果太复杂，感觉可能导致这个启动屏渲染也不及时。
7. 回归启动屏的本质，开发者想要的，是快，炫，方便，并且能在前端白屏的时候去当作loading去使用。

[Gaubee]

1. 启动屏幕的渲染需要有一个明确的配置项，就是关于它的关闭机制：自动、手动。
   1. 自动关闭意味着只要有渲染器提供过来了，那么就直接切过去
   2. 手动关闭意味着，需要调用标准接口来手动对启动屏进行关闭才行，这对于那些启动缓慢的 webapp 应用有利好
2. 启动屏幕的协议直接与 window 的 manifest 强关联，作为一个标准给出。
   1. 我希望做到的是类似 Adobe 软件，比如 Photoshop 那样的启动屏幕的效果，此时没有窗口边框，只是一张海报。
   2. 但这样做的效果具体如何还需商榷。目前我看大部分市场上的人，它们并不会懂得可以长按来关闭应用，更多只是通过窗口左上角的“✖️”来进行关闭
   3. 可以考虑单击 frameless 的启动屏幕后，显示出 windowframe，从而可以回归用户的常规操作。
   4. 但是需要考虑开发者可能提供的是一个透明图片，或者直接主动声明：主窗口的初始化状态是隐藏，而不是浮动显示。这样我们自己很多系统级别的应用都需要这样的风格。比如 jmm/permission 的 bottomsheet 显示的时候不应该弹出主窗口再隐藏，这太浪费渲染资源。
3. 同意你对于启动屏幕快速渲染的需求。因此启动屏幕直接使用最原始的图片渲染技术来做，并且明确表明只支持 svg、png、jpeg。看平台支持的情况，未来逐步加入 bmp、gif、ico、wbmp 的支持。
   1. 需要明确支持暗色模式，参考 themeColor，它也有一个明确的 themeDarkColor

      暗色模式、i18n、高对比度模式 等这些将一个应用多元化定义的属性，目前只有暗色模式是我们需要刚性支持的，因为它是客观存在的，随着太阳下山而自然存在的，而至于 i18n 与高对比度等多元化，它是与人相关的主观模式，目前来说，这些模式需要应用自己去适配。未来我们的平台主要是给一个用户偏好，更希望看到的结果是用户直接下载特定的静态应用程序包，而不是动态程序包。比如说你需要英文，那么就直接下载英文版的程序。
      以上是一个关于如何区分什么时候需要将“多元化”字段固定成标准化 还是只给出一个 偏好信息。

[kingsword09]

Document_Picture-in-Picture 目前只支持 Chrome 116 以上的版本，如果在移动端做个类似功能来做启动屏是否可行？

[Gaubee]

Document_Picture-in-Picture 目前只支持 Chrome 116 以上的版本，如果在移动端做个类似功能来做启动屏是否可行？

你是指显示效果使用类似pip来做吗？

[Gaubee]

现在这个讨论需要决策的关键点在于，要不要使用 web-like 技术来做？

1. 如果用 web-like 技术，就意味着依赖于 http-like 协议来加载相关文件。

   要做到这样的话，得先实现“模块静态文件”的提案，这样才能在后端没有启动的情况下，直接访问静态资源文件来加载相关的 html+css。

2. 如果不用 web-like 技术的话，那么就得基于某一配置来做标准。

[kingsword09]

web-like方式会不会好点，灵活性高，可以做出比较有趣的启动屏

[Gaubee]

web-like方式会不会好点，灵活性高，可以做出比较有趣的启动屏

如果是 web-like 方案的话，可以考虑先支持单文件（url-base）的模式: #227