feat: add splash screen close method to protocol

[wineee]

No description provided.

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: wineee

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

deepin pr auto review

这段代码修改主要涉及 Wayland 协议的扩展，用于处理启动画面的关闭逻辑。以下是对该 diff 的审查意见，分为语法逻辑、代码质量、代码性能和代码安全四个方面：

1. 语法逻辑

• 版本号一致性:

  • CMakeLists.txt 中的版本号从 0.5.3 升级到了 0.5.5。
  • treeland-prelaunch-splash-v1.xml 中的接口 treeland_prelaunch_splash_manager_v1 版本从 1 升级到了 2。
  • 意见: 逻辑正确。引入了新的 close_splash 请求，因此协议版本必须升级。同时，项目版本号的升级也符合发布新功能的惯例。

• 协议定义逻辑:

  • 新增了 close_splash 请求，标记为 since="2"，与接口版本号对应。
  • 参数包含 app_id 和 sandbox_engine_name，这与创建 splash 的逻辑是对应的。
  • 意见: 逻辑清晰。通过 app_id 和 sandbox_engine_name 作为键值来定位需要关闭的 splash 界面，这是合理的。

2. 代码质量

• 文档注释:

  • <description> 标签详细描述了 close_splash 的用途（应用退出或崩溃时关闭）。
  • 明确指出了调用者必须提供创建时使用的非空 sandbox_engine_name。
  • 意见: 文档质量很高，清楚地说明了使用场景和约束条件。

• 参数命名与类型:

  • app_id 和 sandbox_engine_name 使用了与创建请求相同的名称和类型（string），保持了接口的一致性。
  • 意见: 命名规范，易于理解。

• 潜在的改进建议:

  • 在 close_splash 的描述中提到了 "Callers MUST provide the same non-empty sandbox_engine_name"，但在 XML 定义中，参数并没有像某些严格定义的协议那样显式标记为 required（虽然 Wayland 协议通常默认非空即为有效，但在描述中强调是很好的做法）。
  • 建议: 考虑在 summary 中也简要加上 (required, non-empty)，以保持与 create_splash 参数描述的风格一致。例如：

    <arg name="sandbox_engine_name" type="string" summary="the sandbox engine / security context name (required, non-empty)"/>

3. 代码性能

• 影响: 这部分是协议定义（XML）和构建配置（CMake），不涉及运行时代码逻辑，因此对性能没有直接影响。
• 逻辑考量: close_splash 是一个请求操作，通常由客户端发起。服务端需要通过字符串（app_id 和 sandbox_engine_name）查找对应的 splash 实例。
  • 意见: 从协议层面看，这是必要的开销。建议服务端实现时，使用哈希表（Hash Map）等高效数据结构来存储和查找 splash 实例，以最小化字符串匹配带来的性能损耗。

4. 代码安全

• 输入验证:

  • 协议文档强调了 sandbox_engine_name 是 "required, non-empty"。
  • 意见: 这是一个很好的安全提示。服务端实现时必须严格校验 sandbox_engine_name 不为空字符串，否则可能导致逻辑错误或潜在的安全绕过（例如，通过空字符串匹配到意外的资源）。

• 权限与竞态:

  • 意见: 服务端在实现 close_splash 时，应检查调用者是否有权限关闭指定的 app_id 对应的 splash。通常情况下，只有创建该 splash 的客户端（或特定的管理器）才应该能关闭它。
  • 竞态条件: 如果应用在崩溃后，由监控进程调用 close_splash，需要确保不会因为多次调用或与创建请求的竞态而导致资源泄漏或双重释放。协议本身定义清晰，但实现端需注意。

总结

这段 diff 逻辑清晰，文档完善，符合 Wayland 协议的扩展规范。

主要改进建议：
为了保持代码风格的高度一致性，建议将 close_splash 中 sandbox_engine_name 参数的 summary 属性补充完整，明确标注其非空要求。

修改后的 XML 片段建议：

<request name="close_splash" since="2">
    <description summary="close an existing splash screen">
        <!-- ... description content ... -->
    </description>
    <arg name="app_id" type="string" summary="the application ID"/>
    <arg name="sandbox_engine_name" type="string" summary="the sandbox engine / security context name (required, non-empty)"/>
</request>

[zccrs]

如果AM是使用方，它应该不知道window is mapped，所以这里加上这个要求对于使用方来说难以接受。其实只要这个splash对象在，AM里就可以调用这个接口来关闭它，不用关心main window的状态。

[zccrs]

可以在create_splash里加一个new_id返回一个 treeland_prelaunch_splash_v1 的对象，这样就不用加一个 close_splash了，要close直接调用 treeland_prelaunch_splash_v1 的destroy方法，而且有了对象以后，还方便添加一些event给AM做通知，比如splash超时关闭了。

最后很重要的一点，不是所有应用都是单例的，对于非单例应用，create_splash应该允许调用多次，但是create_splash里只有 app_id 等参数，这些跟程序运行的实例无关，无法做区分，因此close_splash时并不知道应该关闭具体哪个闪屏，所以添加 treeland_prelaunch_splash_v1 对象就变得有意义了，AM可以用这个对象跟具体的实例对应到一起。反之，create_splash中应该添加一个 instance_id 参数，便于AM告诉Treeland是为哪个实例创建的slpash，可以让treeland侧将某个闪屏与具体的AM实例关联到一起。

[wineee]

#45