fix: resolve hotspot device not updating when network interface changes

[caixr23]

Changed from QTimer to counter mechanism for handling network configuration updates
Removed QTimer and replaced with integer counter to track update cycles Fixed issue where hotspot devices were not properly updated when network interfaces changed
The previous timer approach could miss updates if network changes occurred rapidly
New counter mechanism ensures proper sequencing of configuration updates

Log: Fixed hotspot device update issue when network interfaces change

Influence:

1. Test hotspot functionality after network interface changes
2. Verify hotspot configuration updates properly
3. Check that password retrieval works correctly after network changes
4. Test multiple rapid network interface changes
5. Verify user active state handling remains functional

fix: 修复网卡变化时热点设备未更新问题

从 QTimer 改为计数器机制处理网络配置更新
移除 QTimer 并使用整数计数器跟踪更新周期
修复当网络接口变化时热点设备未能正确更新的问题
之前的定时器方法在快速网络变化时可能错过更新
新的计数器机制确保配置更新的正确顺序

Log: 修复网卡变化时热点设备更新问题

Influence:

1. 测试网络接口变化后的热点功能
2. 验证热点配置是否正确更新
3. 检查网络变化后密码获取功能是否正常
4. 测试多次快速网络接口变化
5. 验证用户活跃状态处理保持正常

PMS: BUG-303389

Summary by Sourcery

Replace the hotspot configuration update timer with a counter-based mechanism to ensure hotspot devices and configuration are correctly refreshed when network interfaces or connection secrets change.

Bug Fixes:

• Ensure hotspot devices and configuration are correctly updated when network interfaces change, avoiding missed updates during rapid network changes.

Enhancements:

• Simplify hotspot configuration update sequencing by replacing the QTimer-based debounce logic with a lightweight integer counter.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Replaces the previous QTimer-based debounce/sequencing mechanism in NetHotspotController with a simple integer counter to reliably gate hotspot configuration updates when network interfaces and secrets change, addressing missed hotspot device updates under rapid network changes.

Sequence diagram for hotspot configuration updates with counter-based gating

sequenceDiagram
    participant NetHotspotController
    participant NetworkController
    participant Connection
    participant WirelessSecuritySetting

    NetHotspotController->>NetworkController: hotspotController()
    activate NetworkController
    NetworkController-->>NetHotspotController: HotspotController
    deactivate NetworkController

    Note over NetHotspotController: Initial hotspot data/config setup
    NetHotspotController->>NetHotspotController: updateData()
    NetHotspotController->>NetHotspotController: updateEnabled()
    NetHotspotController->>NetHotspotController: updateEnabledable()
    NetHotspotController->>NetHotspotController: updateConfig()
    alt m_userActive is false or m_updateCount > 0
        NetHotspotController->>NetHotspotController: m_updateCount-- (if m_updateCount > 0)
        Note over NetHotspotController: Config update deferred
    else
        NetHotspotController->>Connection: secrets(name)
        Connection-->>NetHotspotController: secrets map
        NetHotspotController->>WirelessSecuritySetting: secretsFromMap(secrets)
    end

    Note over Connection: conn->secrets triggers itemChanged twice
    loop For each itemChanged signal
        Connection-->>NetHotspotController: itemChanged
        NetHotspotController->>NetHotspotController: updateData()
        NetHotspotController->>NetHotspotController: updateEnabled()
        NetHotspotController->>NetHotspotController: updateEnabledable()
        NetHotspotController->>NetHotspotController: updateConfig()
        alt First secrets handling branch
            NetHotspotController->>NetHotspotController: m_updateCount = 2
        else Subsequent calls while m_updateCount > 0
            NetHotspotController->>NetHotspotController: m_updateCount--
            Note over NetHotspotController: Skip duplicate config updates
        end
    end

Loading

Class diagram for updated NetHotspotController debounce mechanism

classDiagram
    class NetHotspotController {
        - bool m_hotspotEnabled
        - bool m_enabledable
        - bool m_deviceEnabled
        - bool m_userActive
        - int m_updateCount
        - QStringList m_shareDevice
        - QStringList m_optionalDevice
        - QStringList m_optionalDevicePath
        + NetHotspotController(QObject *parent)
        + void updateData()
        + void updateConfig()
    }

    class NetworkController {
        + static NetworkController* instance()
        + HotspotController* hotspotController()
    }

    class HotspotController {
    }

    NetHotspotController --> NetworkController : uses
    NetworkController --> HotspotController : returns instance

Loading

File-Level Changes

Change	Details	Files
Replace QTimer-based gating of hotspot configuration updates with an integer counter to better handle rapid network/interface changes and repeated itemChanged signals.	Remove QTimer member used to delay/configure hotspot updates and its initialization in the constructor Introduce an integer member m_updateCount initialized to -1 to track remaining deferred update cycles Update the configuration gating condition to check and decrement m_updateCount instead of relying on QTimer::isActive Set m_updateCount to 2 instead of starting the timer when wireless security secrets updates are expected to emit itemChanged twice Invoke updateConfig() directly at the end of updateData() so configuration stays in sync when hotspot data changes	net-view/operation/private/nethotspotcontroller.cpp net-view/operation/private/nethotspotcontroller.h

---

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]

Hey - I've found 1 issue, and left some high level feedback:

• The m_updateCount logic in updateConfig() is a bit opaque; consider replacing the magic value 2 with a named constant and adding a short comment describing the intended number of skipped itemChanged events to make the sequencing behavior clearer.
• In updateConfig(), m_updateCount-- is executed even when !m_userActive, which can drive the counter negative and change behavior once the user becomes active; it may be safer to only decrement when you actually intend to consume an update (e.g., when m_userActive is true).

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `m_updateCount` logic in `updateConfig()` is a bit opaque; consider replacing the magic value `2` with a named constant and adding a short comment describing the intended number of skipped `itemChanged` events to make the sequencing behavior clearer.
- In `updateConfig()`, `m_updateCount--` is executed even when `!m_userActive`, which can drive the counter negative and change behavior once the user becomes active; it may be safer to only decrement when you actually intend to consume an update (e.g., when `m_userActive` is true).

## Individual Comments

### Comment 1
<location> `net-view/operation/private/nethotspotcontroller.cpp:138-139` </location>
<code_context>
 {
     // 用户不为Active状态时，获取密码需要认证
-    if (!m_userActive || m_updatedTimer->isActive()) {
+    if (!m_userActive || m_updateCount > 0) {
+        m_updateCount--;
         return;
     }
</code_context>

<issue_to_address>
**issue (bug_risk):** Avoid decrementing m_updateCount when the user is inactive; split the conditions.

Previously, when `!m_userActive` the function returned without changing any state. Now, every inactive call decrements `m_updateCount`, which can drive it negative or wrap over time. Please separate the checks so inactivity only returns, and decrement happens only when active, e.g.:

```cpp
if (!m_userActive) {
    return;
}
if (m_updateCount > 0) {
    m_updateCount--;
    return;
}
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[deepin-ci-robot]

deepin pr auto review

这段代码主要是针对 NetHotspotController 类中处理热点配置更新逻辑的重构。主要改动是用计数器（m_updateCount）替代了定时器（QTimer）来处理 itemChanged 信号的防抖或合并逻辑。

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

1. 语法逻辑

• 版权年份修改：
  • 观察：将版权年份从 2024 - 2027 改为 2024 - 2026。
  • 意见：这通常是行政或法律层面的修正，不影响代码逻辑，但在逻辑上属于回退或修正，需确认业务意图。
• 成员变量替换：
  • 观察：将 QTimer *m_updatedTimer 替换为 int m_updateCount，并在构造函数中初始化为 0。
  • 意见：语法正确。逻辑上从“基于时间的延迟执行”转变为“基于计数的信号过滤”。
• 信号连接变更：
  • 观察：将 itemChanged 信号的连接槽从 updateConfig 改为新增的 onItemChanged。
  • 意见：逻辑合理。引入中间层 onItemChanged 来拦截信号并控制是否调用 updateConfig。
• updateConfig 逻辑修改：
  • 观察：删除了 m_updatedTimer->isActive() 的判断。
  • 意见：逻辑正确，因为不再使用定时器。
• onItemChanged 逻辑：
  • 观察：

    if (m_updateCount > 0) {
        m_updateCount--;
    } else {
        updateConfig();
    }

  • 意见：这里的逻辑意图是“忽略前 N 次信号，第 N+1 次执行更新”。
    • 在 updateConfig 中，当需要获取 secrets 时，设置 m_updateCount = 2。
    • 注释说明 conn->secrets 会触发两次 itemChanged 信号。
    • 潜在逻辑风险：如果 conn->secrets 触发的信号次数不固定（例如网络波动导致额外触发），或者两次信号之间插入了其他真实的 itemChanged 信号，这种硬编码计数器逻辑可能会漏掉真实的更新请求，或者导致状态不同步。

2. 代码质量

• 代码可读性与注释：
  • 观察：代码保留了 // conn->secrets会触发两次itemChanged信号 的注释。
  • 建议：建议在 m_updateCount 成员变量声明处也添加注释，说明该变量的用途（例如：用于忽略因获取密钥而产生的额外信号）。
• 魔法数字：
  • 观察：m_updateCount = 2。
  • 建议：虽然代码有注释解释了为什么是 2，但为了代码质量，建议定义一个常量，例如 static const int kSecretsSignalCount = 2;，或者至少在代码中体现这个数字的含义。
• 构造函数初始化：
  • 观察：m_updateCount(0) 初始化正确。
  • 建议：由于 m_updateCount 是基本类型 int，相比 QTimer* 指针，减少了内存分配和释放的开销，简化了资源管理，这是一个改进。

3. 代码性能

• 性能提升：
  • 观察：移除了 QTimer。
  • 意见：这是一个明显的性能提升点。
    • 减少资源消耗：不再创建定时器对象，减少了堆内存分配。
    • 降低延迟：原方案需要等待 50ms（setInterval(50)）才会执行 updateConfig，新方案在信号到达时直接通过计数器判断，如果是有效信号则立即执行（在 onItemChanged 中调用 updateConfig），响应速度更快。
• 信号处理开销：
  • 观察：onItemChanged 函数非常轻量，仅包含简单的整数比较和递减操作。
  • 意见：性能开销极低，优于定时器的事件循环调度。

4. 代码安全

• 线程安全：
  • 观察：m_updateCount 是一个普通的 int 成员变量。
  • 意见：代码中使用了 Qt::QueuedConnection 连接信号。这意味着 onItemChanged 会在接收者（NetHotspotController）所在的线程执行。如果 NetHotspotController 依附于主线程（通常情况），且所有信号都在同一线程触发，则是安全的。如果存在多线程并发修改 m_updateCount 的情况，则需要加锁或使用 QAtomicInt。考虑到这是 UI/控制层代码，通常在主线程运行，目前的实现是安全的。
• 状态一致性：
  • 观察：如前文逻辑部分所述，硬编码计数器依赖于 conn->secrets 严格触发 2 次信号。
  • 风险：如果底层库行为改变（例如触发 1 次或 3 次），或者在高频信号场景下，计数器逻辑可能失效，导致 updateConfig 不被调用（计数未归零）或在不该调用时被调用。
  • 建议：虽然移除定时器解决了延迟问题，但也失去了定时器对信号“合并”的功能（即短时间内多次信号只触发一次处理）。新方案是“忽略特定次数的信号”。如果业务场景中除了 secrets 外还存在其他高频干扰信号，新方案可能不如旧方案稳健。建议确认 itemChanged 的触发场景是否仅限于 secrets 导致的重复。

总结与改进建议

这段代码通过移除定时器并引入计数器，优化了响应速度和资源占用，属于一次不错的性能优化。但在逻辑健壮性上略有牺牲（从“时间防抖”变成了“次数过滤”）。

改进建议：

1. 增加常量定义：
   在类中定义常量代替魔法数字，提高可维护性。

   private:
       static const int IGNORED_SIGNAL_COUNT_FOR_SECRETS = 2;

   使用时：

   m_updateCount = IGNORED_SIGNAL_COUNT_FOR_SECRETS;

2. 完善成员变量注释：
   在头文件中为 m_updateCount 添加详细注释。

   // 用于过滤因获取热点密钥(secrets)而产生的重复itemChanged信号
   // 当调用conn->secrets时，底层会发送多次itemChanged信号，通过此计数器忽略这些干扰信号
   int m_updateCount;

3. 逻辑防御（可选）：
   如果担心 conn->secrets 触发次数不稳定，或者为了防止计数器逻辑错误导致 UI 永久不更新，可以在 onItemChanged 中增加保护措施。例如，如果 m_updateCount 过大（异常情况），强制重置并更新。

   void NetHotspotController::onItemChanged()
   {
       // 防御性编程：如果计数器异常大，可能逻辑出错，强制更新并重置
       if (m_updateCount > 100) { 
           m_updateCount = 0;
           updateConfig();
           return;
       }
   
       if (m_updateCount > 0) {
           m_updateCount--;
       } else {
           updateConfig();
       }
   }

   (注：此条建议视具体业务对稳定性的要求而定，如果底层非常稳定，则不需要。)

4. 版权年份：
   再次确认将 2027 改为 2026 是否符合公司的版权政策。

总体而言，代码修改是可行的，且在性能上有所提升，只要确保底层 itemChanged 信号的行为是确定性的即可。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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