feat: add window maximize and unmaximize methods

[fly602]

Added MaximizeActiveWindow and UnMaximizeActiveWindow methods to the window manager D-Bus interface. These new methods provide separate controls for maximizing and restoring windows, complementing the existing toggle functionality. The implementation includes D-Bus interface definitions in the XML file, Go language bindings in auto.go, and corresponding mock implementations for testing in auto_mock.go.

This change enables more precise window management control by allowing applications to specifically maximize or restore windows without relying solely on the toggle behavior. The separate methods provide better programmatic control over window states.

Log: Added window maximize and unmaximize controls to window manager

Influence:

1. Test MaximizeActiveWindow method to verify it maximizes the active window
2. Test UnMaximizeActiveWindow method to verify it restores maximized windows
3. Verify both methods work correctly with different window types
4. Test interaction with existing ToggleActiveWindowMaximize method
5. Verify D-Bus interface stability and error handling
6. Test mock implementations in unit tests

feat: 添加窗口最大化和取消最大化方法

在窗口管理器 D-Bus 接口中添加了 MaximizeActiveWindow 和
UnMaximizeActiveWindow 方法。这些新方法提供了单独的最大化和恢复窗口控
制，补充了现有的切换功能。实现包括 XML 文件中的 D-Bus 接口定义、auto.go
中的 Go 语言绑定以及 auto_mock.go 中对应的模拟实现用于测试。

此更改通过允许应用程序专门最大化或恢复窗口而不依赖切换行为，实现了更精确
的窗口管理控制。单独的方法提供了对窗口状态更好的程序化控制。

Log: 新增窗口最大化和取消最大化控制功能
PMS: BUG-302527
Influence:

1. 测试 MaximizeActiveWindow 方法验证其能最大化活动窗口
2. 测试 UnMaximizeActiveWindow 方法验证其能恢复最大化窗口
3. 验证两种方法在不同窗口类型下正常工作
4. 测试与现有 ToggleActiveWindowMaximize 方法的交互
5. 验证 D-Bus 接口稳定性和错误处理
6. 在单元测试中测试模拟实现

[deepin-ci-robot]

deepin pr auto review

这段代码主要是在 Deepin 窗口管理器（DDE WM）的 DBus 接口中添加了两个新方法：MaximizeActiveWindow（最大化活动窗口）和 UnMaximizeActiveWindow（取消最大化活动窗口），并生成了相应的 Go 语言绑定代码和 Mock 对象。

以下是对这段代码的审查意见，分为语法逻辑、代码质量、代码性能和代码安全四个方面：

1. 语法逻辑

• 正确性：代码逻辑正确。新增的方法与现有的 BeginToMoveActiveWindow 或 ToggleActiveWindowMaximize 等方法保持了完全一致的实现模式。
  • Wm.xml 中正确声明了 DBus 方法。
  • auto.go 中的 wm 接口正确添加了方法签名。
  • auto.go 中的 interfaceWm 实现正确调用了底层的 DBus Go_ 方法。
  • auto_mock.go 中的 Mock 实现符合 gomock 的规范。
• 命名一致性：方法命名遵循了 Go 的命名规范（大写开头）以及现有代码的风格（如 Maximize vs UnMaximize）。虽然 Go 语言中 Unmaximize（驼峰式）可能更常见，但为了保持与 DBus 接口（XML）及现有代码（如 UnMaximizeActiveWindow）的一致性，当前命名是合理的。

2. 代码质量

• 代码生成：这些文件（auto.go, auto_mock.go）看起来是由工具（如 dbus-codegen 或类似工具配合 mockgen）自动生成的。生成的代码结构清晰，格式规范。
• 注释：auto.go 中为新方法添加了 // method MaximizeActiveWindow 这样的注释，虽然简单，但对于区分代码块是有帮助的。
• 一致性：新代码完美地复制了现有代码的模式。这确保了代码库的统一性，降低了维护成本。

3. 代码性能

• 同步调用开销：在 MaximizeActiveWindow 和 UnMaximizeActiveWindow 的实现中：

  func (v *interfaceWm) MaximizeActiveWindow(flags dbus.Flags) error {
  	return (<-v.GoMaximizeActiveWindow(flags, make(chan *dbus.Call, 1)).Done).Err
  }

  每次调用都会创建一个新的缓冲 channel (make(chan *dbus.Call, 1))。对于高频调用的场景，这会产生轻微的内存分配开销。
  • 建议：如果这是性能极度敏感的路径，可以考虑使用 dbus.NoFlag 相关的优化或复用 channel（但在并发场景下复用 channel 极其复杂且容易出错）。鉴于这是窗口管理操作（通常由用户交互触发，频率很低），当前的实现是完全可接受的，符合 DBus 调用的标准做法。

4. 代码安全

• 参数校验：代码直接透传了 flags 参数给 DBus 调用。由于这是自动生成的绑定代码，通常不在此层进行业务逻辑校验。安全性依赖于 DBus 服务端（窗口管理器）对参数的验证。
• Mock 中的 Panic：在 auto_mock.go 中，如果 Mock 设置的返回值类型不正确，代码会 panic：

  if !ok {
      panic(fmt.Sprintf("assert: arguments: 0 failed because object wasn't correct type: %v", mockArgs.Get(0)))
  }

  这是 gomock 的标准行为，有助于在开发测试阶段尽早发现类型不匹配的 bug，是可以接受的。

总结与改进建议

总体而言，这段代码质量很高，完全符合 DBus 接口定义和 Go 语言的最佳实践。

改进建议：

1. XML 文档补充（可选）：在 Wm.xml 中，虽然不是必须的，但建议为新增的 <method> 添加 doc 注释，说明该方法的具体行为。例如：

   <method name="MaximizeActiveWindow">
     <arg direction="in" type="u" name="flags"/>
     <annotation name="org.freedesktop.DBus.Deprecated" value="false"/>
     <!-- Add documentation here if possible -->
     <doc:doc>
       <doc:description>Maximize the currently active window.</doc:description>
     </doc:doc>
   </method>

   这有助于生成更完善的 API 文档。

2. 接口幂等性考虑：逻辑上，如果对一个已经最大化的窗口调用 MaximizeActiveWindow，或者对未最大化的窗口调用 UnMaximizeActiveWindow，应当是幂等的（即不应报错或产生副作用）。这需要确保 DBus 服务端（C++或其他语言实现的 WM）实现了这种幂等性，Go 端的代码只需负责传递调用即可。

3. GoChannel 缓冲区大小：代码中使用 make(chan *dbus.Call, 1) 创建缓冲为 1 的 channel。这是正确的做法，可以防止在发送者（异步 DBus 回调）和接收者（同步等待）之间产生死锁。请确保后续维护时不要将其改为无缓冲 channel。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fly602, mhduiy

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