fix: start notification expire timer only after bubble is displayed

[Ivy233]

1. Move the pending-timeout machinery from NotificationManager to a frontend ExpireTimer singleton, keeping one shared QTimer and absolute deadlines in a single QMultiHash while removing all server-side timer state
2. Start a countdown only when a notification is actually inserted into the bubble model or the visible staging model, so queued, hidden and overflow notifications no longer expire before being displayed
3. Make ExpireTimer::push idempotent for the same entity (same id + cTime), so the bubble and the staging area share the first deadline instead of restarting it, and cancel the old bubble-slot countdown when a replacement arrives
4. Move hover blocking into ExpireTimer::setBlockId with a short grace period, without spinning the shared timer at a zero interval
5. Keep the server authoritative for the notification lifecycle: expiration is reported to NotificationManager::notificationClosed via a queued invocation, and countdowns are stopped from the server's NotificationStateChanged instead of frontend model removal; notificationClosed now reports a close only once per notification
6. Derive effective timeouts from NotifyEntity (timeout 0 or Critical urgency never expires, -1 falls back to the 5000 ms default) and carry bubbleId in the expired signal
7. Match staging-area replacements by bubble id (the key preserved across a replace), like BubbleModel::replaceBubbleIndex
8. Remove the obsolete pending-timeout code from NotificationManager/NotifyServerApplet and its outdated tests
9. Also fix taskbar icons not updating when the Icon field of the desktop file changes (forward dataChanged in DockGlobalElementModel, fix refresh of multi-mapped rows in RoleCombineModel)

Log: Start the notification expire countdown only after the notification is displayed

Influence:

1. A displayed notification disappears after its expire timeout (default 5 seconds); queued notifications no longer expire while hidden
2. Hovering a bubble keeps it on screen, and it lingers about 1 second after the hover ends
3. The same notification shown in the bubble and the staging area shares one countdown and is not timed twice
4. Run the notification server and taskmanager unit tests

fix: 通知显示后才启动过期计时

1. 将 NotificationManager 中的 pending-timeout 机制整体迁移到前端 ExpireTimer 单例：保留单个共享 QTimer 与按绝对截止时间组织的 QMultiHash，移除服务端全部定时器状态
2. 仅在通知真正插入气泡模型或可见的暂存区模型时才启动倒计时，排队、隐藏和溢出的通知不再提前过期
3. ExpireTimer::push 对同一通知（相同 id + cTime）幂等：气泡与暂存区共享首次截止时间、不重复计时；替换通知按 bubbleId 取消旧槽位倒计时后再启动新计时
4. 悬停阻断逻辑下沉到 ExpireTimer::setBlockId，移开悬停后有短暂宽限期，共享 QTimer 不会以 0 间隔空转
5. 生命周期仍由服务端统一管理：到期经 queued 调用转入 NotificationManager::notificationClosed，前端根据服务端 NotificationStateChanged 停止计时而非自行移除；notificationClosed 增加去重，避免同一通知重复上报关闭
6. 有效超时时间由 NotifyEntity 推导（timeout 为 0 或 Critical 紧急级别永不过期，-1 回退默认 5000ms），expired 信号携带 bubbleId
7. 暂存区替换匹配改用 bubbleId（替换时唯一不变的键），与 BubbleModel::replaceBubbleIndex 保持一致
8. 删除 NotificationManager/NotifyServerApplet 中过时的 pending-timeout 代码及其旧测试
9. 同时修复 desktop 文件 Icon 字段变化后任务栏图标不更新的问题（DockGlobalElementModel 转发 dataChanged，RoleCombineModel 修复多对一映射行的刷新）

Log: 通知显示后才启动过期计时

Influence:

1. 气泡显示后默认 5 秒消失；大量通知排队时不再在显示前提前过期
2. 鼠标悬停气泡时不消失，移开后停留约 1 秒
3. 同一通知在横幅与暂存区共用同一倒计时，不会重复计时
4. 运行通知服务端与任务管理器单元测试

PMS: BUG-372279

Summary by Sourcery

Start notification expiration when notifications become visible and centralize countdown management across presentation models.

Bug Fixes:

• Start notification expiration only after a notification is displayed, preventing queued, hidden, and overflow notifications from expiring prematurely.
• Keep displayed notifications alive while hovered and provide a brief grace period after hover ends.
• Ensure taskbar icons refresh when desktop-file Icon values change.

Enhancements:

• Centralize frontend expiration tracking with shared, idempotent countdowns across bubble and staging views while preserving server-authoritative notification lifecycle handling.
• Derive expiration behavior from notification timeout and urgency, support replacement matching by bubble ID, and prevent duplicate close reports.

Tests:

• Add ExpireTimer unit coverage for expiration, duplicate pushes, hover blocking, replacements, and non-expiring critical notifications.
• Update notification server tests after removing obsolete timeout and hover APIs.

Chores:

• Remove obsolete server-side pending-timeout state and handling.

[deepin-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Ivy233

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

[sourcery-ai]

Reviewer's Guide

This PR defers starting the notification expiration timer until a bubble is actually inserted into the UI model, wiring a new bubbleDisplayed signal through BubblePanel to NotificationManager, which now schedules timeouts based on the stored client expire timeout only when notifications are displayed, with thread-safe forwarding from the applet and added unit tests.

Sequence diagram for deferred notification timeout start when bubble is displayed

sequenceDiagram
    participant BubbleModel
    participant BubblePanel
    participant NotifyServerApplet
    participant NotificationManager

    BubbleModel->>BubbleModel: insertBubble / replaceBubble
    BubbleModel-->>BubblePanel: bubbleDisplayed(id)
    BubblePanel->>NotifyServerApplet: notificationDisplayed(id)
    NotifyServerApplet->>NotificationManager: notificationDisplayed(id)
    NotificationManager->>NotificationManager: fetchEntity(id)
    NotificationManager->>NotificationManager: pushPendingEntity(entity, entity.timeout())

Loading

File-Level Changes

Change	Details	Files
Start notification expiration only when the bubble is displayed instead of on receipt.	Removed immediate scheduling of pending notification timeouts in Notify() based on hints expireTimeout. Added a notificationDisplayed(qint64) slot in NotificationManager that fetches the entity, checks validity/urgency, reads its timeout(), and calls pushPendingEntity only for non-critical, expiring notifications. Introduced a timeout() accessor on NotifyEntity to expose the stored expire timeout instead of passing it around separately.	panels/notification/server/notificationmanager.cpp panels/notification/server/notificationmanager.h panels/notification/common/notifyentity.cpp panels/notification/common/notifyentity.h
Signal when a bubble is actually shown and propagate that to the notification server with correct threading semantics.	Added a bubbleDisplayed(qint64) signal to BubbleModel and emit it when inserting or replacing bubbles in the model. Connected BubbleModel::bubbleDisplayed in BubblePanel to forward the ID to the notification server via notificationDisplayed using a direct connection. Implemented NotifyServerApplet::notificationDisplayed to forward the call into NotificationManager::notificationDisplayed using Qt::QueuedConnection so the timeout QTimer starts on the worker thread.	panels/notification/bubble/bubblemodel.h panels/notification/bubble/bubblemodel.cpp panels/notification/bubble/bubblepanel.cpp panels/notification/server/notifyserverapplet.h panels/notification/server/notifyserverapplet.cpp
Add unit coverage for the new notificationDisplayed path to ensure robustness for various IDs.	Added a basic NotifyServerApplet test that calls notificationDisplayed with a valid ID to ensure no crashes. Added edge-case tests that call notificationDisplayed with 0, -1, and max qint64, verifying the applet handles these IDs without throwing.	tests/panels/notification/server/notifyserverapplet_test.cpp

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

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

Please try again later or upgrade to continue using Sourcery

[Ivy233]

回复 auto review 提出的多线程竞态问题：经逐一核实，ExpireTimer 的所有调用点均在主线程，不存在跨线程访问 m_pendingEntities 的路径，该问题为误报，无需加锁。

1. BubbleModel::insertBubble/replaceBubble、BubblePanel::setHoveredId、NotifyStagingModel::push/replace 均为 UI 侧调用，运行在主线程；
2. NotifyServerApplet::init() 中连接 NotificationStateChanged 的 lambda（内部调用 ExpireTimer::remove）使用 Qt::QueuedConnection，接收者为 applet 本身（主线程创建），因此该 lambda 也在主线程执行（panels/notification/server/notifyserverapplet.cpp:65）；
3. 唯一的跨线程调用是 expired → m_manager->notificationClosed，通过 Qt::QueuedConnection 投递到 worker 线程（notifyserverapplet.cpp:74-77），该路径不触碰 ExpireTimer 内部状态；
4. 单例首次构造发生在 init()（主线程），QTimer 与哈希表同属主线程，符合 QTimer 的线程亲和性要求。

另外，示例中在持锁状态下调用 m_timer->start() 并不能解决跨线程问题——QTimer 只能在其所属线程启动，真正跨线程时需要 QMetaObject::invokeMethod 投递；本实现已确保全部访问在主线程，故无此问题。

[Ivy233]

/test github-pr-review-ci

[deepin-bot]

TAG Bot

New tag: 2.0.53
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1702

[deepin-bot]

TAG Bot

New tag: 2.0.54
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1733

[deepin-bot]

TAG Bot

New tag: 2.0.55
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1752

[deepin-bot]

TAG Bot

New tag: 2.0.56
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1753

[18202781743]

NotificationStateChanged 这个不需要吧，在其它close里的路径里处理，

[Ivy233]

已按建议调整：删除了新增的 NotificationStateChanged → ExpireTimer::remove 连接，改为在 NotifyServerApplet::notificationClosed() 主线程槽内直接调用 ExpireTimer::remove(id)。气泡按钮与通知中心的关闭路径都汇入该槽，在这里停表时机最早——先于 queued 投递给 manager 的关闭请求，也缩小了此前注释中提到的竞态窗口；自然到期路径无需 remove（条目在 expired 发出时已删除，remove 为幂等空操作）。

这里删除的是新增的计时器清理连接；init() 中原有的
NotificationStateChanged → NotifyServerApplet::notificationStateChanged
连接仍需保留。它负责把服务端的处理状态转发给前端，BubblePanel 依赖该信号移除已处理或已关闭的通知，并不属于 ExpireTimer 的清理逻辑。

不经过 notificationClosed() 槽的关闭路径（如第三方通过 D-Bus 调用 CloseNotification）无法在自身路径上停表：该调用经 adaptor 直接落在工作线程的 manager 上，而 ExpireTimer 及其 QTimer 具有主线程亲和性，就地调用属于跨线程访问。这类路径由 notificationClosed() 中 processedType != NotProcessed 的守卫兜底：滞留的倒计时条目到期后只会触发一次被守卫拒绝的空跑，不会对同一通知重复发出 NotificationClosed。

[deepin-ci-robot]

deepin pr auto review

🤖 AI 代码审查报告

总体评分： 97 分 (通过阈值: 70分)

---

📊 总体评价

项目	结果
审查结论	代码审查通过
评分详情	总体评分 97 分，大于 70 分通过阈值，代码质量优秀。本次 PR 将通知过期计时器逻辑从服务端移至前端展示层，修复了计时器在气泡显示前就启动的核心问题，同时改进了线程安全性和竞态条件处理。

---

🔍 详细分析

1. 语法逻辑 ✅

评价： 优秀 ✅ 通过

潜在问题：

1. panels/notification/common/expiretimer.cpp:378 - static_cast转换可能对极大timeout值溢出，建议增加上限保护

建议： 建议在timer间隔转换处增加上限保护，如 qMin(interval, INT_MAX) 防止极端情况下的溢出

---

2. 代码质量 ✅

评价： 优秀 ✅ 通过

潜在问题：

1. panels/notification/bubble/bubblemodel.cpp:103 - BubbleModel::clear()方法被移除，需确认无残留调用方

建议： 代码注释质量优秀，设计决策文档化程度高。建议确认clear()移除后无编译期遗漏的调用方

---

3. 代码性能 ✅

评价： 优秀 ✅ 通过

潜在问题：

1. panels/notification/common/expiretimer.cpp:463 - onTimeout()中std::sort可优化为std::min_element以降低复杂度

建议： 对于通知系统典型的小规模数据(通常<20个)，当前O(n)性能完全可接受。单QTimer设计配合最近截止时间驱动是高效的方案

---

4. 代码安全 🔒

评价： 优秀 ✅ 通过

🔐 发现 0 个安全漏洞

安全漏洞详情：
✅ 未发现安全漏洞

建议： 线程安全性通过将Qt::DirectConnection改为Qt::QueuedConnection得到改善。notificationClosed中新增的processedType()守卫有效防止了竞态条件下的重复关闭问题。无用户输入注入、无硬编码凭证、无缓冲区溢出风险。

---

💡 改进建议代码示例

// expiretimer.cpp - 建议在timer间隔转换处增加上限保护
void ExpireTimer::onTimeout()
{
    // ... 处理过期实体 ...

    if (m_pendingEntities.isEmpty()) {
        m_timer->stop();
        m_lastPoint = std::numeric_limits<qint64>::max();
        return;
    }

    auto points = m_pendingEntities.keys();
    // 优化：使用 std::min_element 替代 std::sort，O(n) vs O(n log n)
    m_lastPoint = *std::min_element(points.begin(), points.end());
    
    // 增加上限保护，防止极端timeout值导致int溢出
    auto rawInterval = qMax<qint64>(0, m_lastPoint - QDateTime::currentMSecsSinceEpoch());
    int safeInterval = static_cast<int>(qMin<qint64>(rawInterval, std::numeric_limits<int>::max()));
    m_timer->start(safeInterval);
}

---

本报告由 AI 代码审查工具自动生成