chore: update version to 6.5.38

[wyu71]

• bump version to 6.5.38

Log : bump version to 6.5.38

[sourcery-ai]

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

Please try again later or upgrade to continue using Sourcery

[github-actions]

TAG Bot

TAG: 6.5.38
EXISTED: no
DISTRIBUTION: unstable

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已经仔细审查了你提供的Git Diff输入。

本次提交主要包含两部分内容：

1. 版本号升级：将 deepin-font-manager 的版本从 6.5.37 升级到 6.5.38，并同步更新了 debian/changelog 和 linglong.yaml。
2. Bug修复：根据 debian/changelog 的描述，修复了在取消删除操作时未重置 m_fIsDeleting 标志位的问题，通过监听 DFDeleteDialog::rejected 信号来实现。

由于本次Diff仅包含版本号和Changelog的变更，未包含实际的C++代码改动，我将基于Changelog中描述的修改意图，为你提供针对该逻辑的代码审查和改进建议。

1. 语法与逻辑

• 状态重置的完整性：监听 rejected 信号来重置 m_fIsDeleting 是正确的逻辑方向。但请确保考虑了所有可能导致对话框关闭的非正常路径。例如，如果对话框被直接关闭（如按下 Esc 键或点击窗口的 X 关闭按钮），Qt 的 QDialog 默认会触发 rejected 信号，这通常没问题；但如果你的代码中重写了 closeEvent 或有其他特殊处理，需确保这些路径也能正确重置状态。
• 信号连接的时机：确保在对话框创建后、显示前（exec() 或 show() 之前）就建立好 rejected 信号的连接，防止出现竞态条件，导致早期的取消操作未被捕获。
• accepted 信号的处理：如果删除操作成功完成（触发了 accepted），m_fIsDeleting 是在 accepted 的槽函数中被重置，还是在删除的异步回调中被重置？需要确保无论成功、失败还是取消，该标志位都能被正确重置，否则可能导致界面卡死或无法再次触发删除操作。

2. 代码质量

• 变量命名规范：变量名 m_fIsDeleting 中的 f 前缀通常在MFC或旧版C++中用来表示 float 类型，但此处显然是一个布尔值。建议遵循现代C++或Qt的命名规范，改为 m_isDeleting 或 m_bIsDeleting（如果项目规范要求布尔值用 b 前缀），以提高代码的可读性。
• 资源管理与生命周期：确保 DFDeleteDialog 的生命周期管理得当。如果是栈对象（如 DFDeleteDialog dlg; dlg.exec();），对话框关闭后自动销毁，信号连接无需特殊处理；如果是堆对象（new DFDeleteDialog），需注意在取消或完成后适时 delete，或者设置 Qt::WA_DeleteOnClose 属性，防止内存泄漏。
• Changelog格式：debian/changelog 的日期格式 Tue, 19 May 2026 21:03:45 +0800 看起来是标准的，但年份是 2026年，请确认这是否是笔误（通常应该是当前年份如2023或2024），虽然不影响编译，但可能违反发行版的打包规范。

3. 代码性能

• 信号槽连接方式：建议使用 Qt 5/6 推荐的新式信号槽连接语法（编译期检查），并且如果对话框是短生命周期的局部对象，连接时可以不用特别担心性能；如果是频繁创建销毁的对象，确保连接在对象销毁时自动断开（Qt 的默认行为已保证这一点）。
• 标志位操作：布尔标志位的读写是原子级别的高性能操作，此处无性能瓶颈。

4. 代码安全

• 状态不一致风险：m_fIsDeleting 通常用于防止重入（例如防止用户在删除过程中再次点击删除按钮）。如果 rejected 触发时，底层的删除线程或异步任务实际上已经被启动且无法立即停止，仅仅重置 m_fIsDeleting 可能会导致用户再次触发删除，从而引发并发冲突或数据损坏。建议：确认取消操作是否真正中断了后续的删除流程；如果无法中断，应考虑使用更稳健的状态机（如 Idle, Deleting, Cancelling）代替简单的布尔值。
• 空指针解引用：如果在监听 rejected 信号的槽函数中访问了其他类成员，请确保这些成员在对话框关闭时仍然有效，避免潜在的空指针或悬垂指针问题。

---

💡 代码改进示例（基于推测的实现）

虽然没看到你的实际C++代码，但基于上述分析，一个健壮的实现应该类似这样：

// 推荐的变量命名：去掉容易引起歧义的 'f' 前缀
bool m_isDeleting = false;

// 在触发删除的函数中
void DFontPreviewListView::onDeleteAction() {
    if (m_isDeleting) {
        return; // 防止重入
    }
    
    m_isDeleting = true;
    DFDeleteDialog dlg(this);
    
    // 监听取消/拒绝信号，使用新式 Qt 语法，编译更安全
    connect(&dlg, &DFDeleteDialog::rejected, this, [this]() {
        m_isDeleting = false; // 取消时重置状态
    });
    
    // 监听确认信号
    connect(&dlg, &DFDeleteDialog::accepted, this, [this]() {
        // 注意：如果删除是异步的，这里可能不应该立刻重置 m_isDeleting
        // 而是应该在异步删除完成的回调中重置
        // m_isDeleting = false; 
    });
    
    if (dlg.exec() == QDialog::Rejected) {
        // exec 返回后，如果是 rejected，槽函数已经将 m_isDeleting 重置
        // 此处可以处理其他 UI 逻辑
    }
}

总结

本次Diff的版本控制和修复方向是正确的。主要关注点应放在实际C++代码中状态重置的时序以及防止异步操作与布尔标志位状态不同步的问题上。另外，请核实 debian/changelog 中的年份（2026）是否正确。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lzwind, wyu71

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-bot]

TAG Bot

✅ Tag created successfully

📋 Tag Details

• Tag Name: 6.5.38
• Tag SHA: 538b11316932b2affd2c86524c268e97c6e49f97
• Commit SHA: f12c894a4efdc7aed27333844d4c1872d86b717e
• Tag Message:

  Release deepin-font-manager 6.5.38
  
  

• Tagger:
  • Name: wyu71
• Distribution: unstable