feat: add hasInWindowBlur property to DQMLGlobalObject

[18202781743]

Summary

• Add hasInWindowBlur property to DQMLGlobalObject QML singleton
• InWindowBlur QML component checks D.DTK.hasInWindowBlur before enabling blur
• Add version dependencies for dtkgui and dtkcommon in debian/control

Issue

https://pms.uniontech.com/task-view-390117.html

Dependencies

• dtkgui: HasInWindowBlur attribute (>> 6.7.42 / >> 5.7.42)
• dtkcommon: disableInWindowBlur config key (>> 6.7.42 / >> 5.7.42)

Test Plan

• Test hasInWindowBlur property returns correct value
• Test InWindowBlur component disables blur when hasInWindowBlur is false

[sourcery-ai]

Sorry @18202781743, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已仔细审查了你提供的 Git Diff。本次修改主要涉及三个方面：Debian 包依赖版本约束更新、版权声明年份更新，以及为 DTK 新增 hasInWindowBlur 属性并在 QML 中使用该属性来控制窗口模糊效果。

整体来看，代码逻辑清晰，修改意图明确。但为了确保代码的健壮性、安全性和可维护性，我针对语法逻辑、代码质量、代码性能和代码安全四个方面提出以下审查意见和改进建议：

1. 语法与逻辑

• Q_PROPERTY 信号缺失绑定 (关键问题)：
  在 dqmlglobalobject_p.h 中，新增了 Q_PROPERTY(bool hasInWindowBlur READ hasInWindowBlur NOTIFY hasInWindowBlurChanged)，并且声明了 hasInWindowBlurChanged() 信号。但是，该信号从未被发射。
  对比其他属性（如 hasComposite、hasAnimation），它们通常会在主题切换、系统属性变化时被触发。如果 HasInWindowBlur 是一个运行时可能发生变化的属性（例如用户在系统设置中开/关模糊效果），不发射信号将导致 QML 绑定无法更新，UI 状态失效。

  • 建议：如果该属性运行时会变，需在 DGuiApplicationHelper 相关属性变化的回调中 emit hasInWindowBlurChanged();。如果该属性在应用生命周期内恒定不变，则应像 isSoftwareRender 一样，使用 CONSTANT 关键字，并移除 NOTIFY hasInWindowBlurChanged。

• Debian 依赖版本运算符使用不规范 (潜在逻辑风险)：
  在 debian/control 中，使用了 libdtk6gui-dev (>> 6.7.42)。>> 在 Debian 版本控制中表示严格大于。这通常用于过渡期，避免依赖特定的已知错误版本。但在常规开发中，更标准的做法是使用 >=（大于或等于）。如果 6.7.42 是引入该功能的最低版本，使用 >> 意味着如果有人编译了 6.7.42 的精确版本，反而会不满足依赖。

  • 建议：确认是否真的需要排除 6.7.42 精确版本。如果不需要，建议改为 libdtk6gui-dev (>= 6.7.42)，这更符合 Debian 打包的常规惯例。

2. 代码质量

• QML 逻辑表达式可读性：
  在 InWindowBlur.qml 中，blitterEnabled 的赋值变更为 !D.DTK.isSoftwareRender && D.DTK.hasInWindowBlur。逻辑本身没问题，但当条件逐渐增多时，单行逻辑会降低可读性。

  • 建议：如果未来还有更多条件，建议考虑在 C++ 端（如 DQMLGlobalObject）封装一个综合判断的 isInWindowBlurAvailable 属性，或者在 QML 中适当换行：

    blitterEnabled: !D.DTK.isSoftwareRender
                    && D.DTK.hasInWindowBlur

• 版权声明年份更新规范：
  修改将 2023 改为 2023 - 2026。包含未来的年份在开源协议中是不推荐的。SPDX 和 FSF 建议版权年份应为作品实际发布或修改的年份，而不是未来的年份。

  • 建议：如果这是为了自动生成或占位，请确认构建系统是否会替换。如果是手动填写，建议改为实际发布年份，如 2023 - 2024，或 2023, 2024。

3. 代码性能

• hasInWindowBlur() 的调用开销：
  在 C++ 实现中，hasInWindowBlur() 调用了 DGuiApplicationHelper::testAttribute()。在 QML 中，它作为属性绑定，任何引起 QML 引擎重新评估的上下文变化都可能导致该函数被频繁调用。
  对比同文件中的 isSoftwareRender()，它使用了 static bool isSoftware = ... 来缓存结果以提升性能。
  • 建议：如果 HasInWindowBlur 在应用启动后不会改变（即属于硬件/环境能力检测），建议像 isSoftwareRender() 一样，在 hasInWindowBlur() 内部使用 static 缓存结果，避免重复调用 testAttribute() 带来的开销：

    bool DQMLGlobalObject::hasInWindowBlur()
    {
        static bool hasBlur = DGuiApplicationHelper::testAttribute(DGuiApplicationHelper::HasInWindowBlur);
        return hasBlur;
    }

    (注意：如果做了 static 缓存，则该属性值必定是 CONSTANT 的，需同步修改 Q_PROPERTY 声明)。

4. 代码安全

• Debian 依赖版本过于严格可能导致构建环境破坏：
  正如语法逻辑中提到的，>> 6.7.42 是强依赖。在 Linux 发行版的持续集成环境中，如果依赖库的版本号由于重置或回退产生变化，过于严格的版本约束可能导致原本可以兼容的构建失败（供应链构建安全性问题）。
  • 建议：使用 >= 除非有确切的证据表明 6.7.42 版本存在破坏 ABI 的 Bug 必须被排除。

---

总结与修改示例

如果你确认 hasInWindowBlur 是一个运行时不会改变的属性（通常窗口模糊能力在程序启动时确定），我建议对 C++ 部分做如下优化：

dqmlglobalobject_p.h:

// 修改为 CONSTANT，移除 NOTIFY
Q_PROPERTY(bool hasInWindowBlur READ hasInWindowBlur CONSTANT)
// ...

// 移除信号声明
// void hasInWindowBlurChanged(); 

dqmlglobalobject.cpp:

bool DQMLGlobalObject::hasInWindowBlur()
{
    // 使用 static 缓存，提升性能，与 isSoftwareRender 保持一致
    static bool hasBlur = DGuiApplicationHelper::testAttribute(DGuiApplicationHelper::HasInWindowBlur);
    return hasBlur;
}

debian/control:

# 建议将 >> 改为 >=，除非明确要排除 6.7.42 版本
libdtk6gui-dev (>= 6.7.42),
libdtkcommon-dev (>= 6.7.42),

希望这些审查意见对你有所帮助！如果有任何疑问，欢迎继续探讨。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743, 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