fix: show dock context menu on long press release

[fly602]

1. Add isLongPressing property to track long press state
2. Defer dock context menu display until long press is released for mouse input
3. Refactor touch long press to use same deferred release pattern
4. Add debug logging for both mouse and touch long press events

Previously the dock context menu opened immediately on the longPressed signal, which could cause unexpected behavior while the user was still pressing. Now the menu only appears after the long press is released, providing a more natural and predictable interaction.

Log: Changed dock long press behavior to show context menu on release instead of immediately

Influence:

1. Test mouse long press on dock - verify context menu appears on release not during press
2. Test touch long press on dock - verify context menu appears on release not during press
3. Test short click/tap on dock - verify context menu does NOT appear
4. Test right-click on dock - verify normal context menu behavior is unaffected
5. Test long press and drag - verify no unexpected menu activation
6. Test rapid long press/release cycles - verify isLongPressing flag resets correctly

fix: 修复任务栏长按上下文菜单在松开时才显示

1. 添加 isLongPressing 属性用于跟踪长按状态
2. 鼠标输入的长按上下文菜单延迟到松开时显示
3. 重构触摸长按逻辑，使用相同的延迟松开模式
4. 为鼠标和触摸长按事件添加调试日志

此前任务栏上下文菜单在 longPressed 信号触发时立即打开，可能导致用户仍在
按压时出现意外行为。现在菜单仅在长按松开后显示，提供更自然和可预测的交互
体验。

Log: 修改任务栏长按行为，上下文菜单在松开时显示而非立即显示

Influence:

1. 测试鼠标长按任务栏 - 验证上下文菜单在松开时而非按压时显示
2. 测试触摸长按任务栏 - 验证上下文菜单在松开时而非按压时显示
3. 测试短按/轻点任务栏 - 验证上下文菜单不会出现
4. 测试右键点击任务栏 - 验证正常的上下文菜单行为不受影响
5. 测试长按并拖动 - 验证不会意外激活菜单
6. 测试快速长按/松开循环 - 验证 isLongPressing 标志正确重置

PMS: BUG-358827
Change-Id: I23597cf45ae2c4cea634eb525a6ad09bde5fc89a

[sourcery-ai]

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

Please try again later or upgrade to continue using Sourcery

[deepin-bot]

TAG Bot

New tag: 2.0.39
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1580

[deepin-bot]

TAG Bot

New tag: 2.0.40
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1592

[deepin-bot]

TAG Bot

New tag: 2.0.41
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #1596

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已仔细审查了你提供的Git Diff代码。本次修改主要是将QML中的 MouseArea 替换为了更现代的 TapHandler，并分离了鼠标点击和触摸屏点击的逻辑。

以下是我从语法逻辑、代码质量、代码性能和代码安全四个维度提出的详细审查意见和改进建议：

1. 语法与逻辑

• 信号参数不匹配（重要）：TapHandler 的 onTapped 信号的参数签名是 onTapped(eventPoint, button)，其中 button 是单数，表示触发事件的那个按键（如 Qt.LeftButton）。你代码中写的是 buttons（复数），这在QML中虽然不会直接报错（JS的弱类型特性），但语义不准确，且如果后续有人误以为它是位掩码组合（如 Qt.LeftButton | Qt.RightButton）就会产生逻辑Bug。
• 触摸屏TapHandler的冗余逻辑：你为触摸屏单独写了一个 TapHandler，并设置了 acceptedButtons: Qt.NoButton。实际上，TapHandler 默认就会接受触摸屏的 Tap 事件。如果你只是为了区分鼠标和触摸，或者防止触摸屏长按触发右键菜单，这种写法可以接受，但 Qt.NoButton 的语义有些模糊。
• 右键点击逻辑丢失：原 MouseArea 虽然没有显式处理 Qt.RightButton，但它会拦截右键事件。新的鼠标 TapHandler 声明了 acceptedButtons: Qt.LeftButton | Qt.RightButton，但在 onTapped 中只处理了左键。如果右键点击，事件被该 Handler 拦截但未做任何处理，可能会导致原本期望的右键菜单（如Dock栏图标的上下文菜单）失效。

2. 代码质量

• 对象冗余：目前使用了两个 TapHandler 来分别处理鼠标和触摸。虽然Qt Quick允许挂载多个Input Handler，但在这个场景下，完全可以合并为一个 TapHandler，通过判断设备类型来执行逻辑，这样代码更简洁，也更符合Qt官方推荐的做法。
• 属性冗余：gesturePolicy: TapHandler.WithinBounds 是 TapHandler 的默认值，显式写出虽然增加了可读性，但略显冗余。如果团队规范要求显式声明默认值则保留，否则可以移除。

3. 代码性能

• 事件处理开销：使用两个 TapHandler 意味着每次点击事件到达时，QML引擎都需要遍历并计算两个Handler的 acceptedDevices 和 acceptedButtons，这比单个Handler带来了微小的额外开销。在嵌入式或低端设备上，合并为一个Handler性能表现更好。

4. 代码安全

• 事件拦截安全（逻辑漏洞）：如前文所述，鼠标 TapHandler 设置了接受右键但未处理右键，这属于“事件吞没”，会破坏UI的交互完整性，导致用户右键无响应。
• 输入校验：QML的Handler底层由C++驱动，传入的 eventPoint 和 button 都是安全的，不存在注入风险，这方面没有问题。

---

💡 改进建议与重构代码

建议将两个 TapHandler 合并为一个，利用 eventPoint.device 来区分输入设备，并修复参数命名和右键拦截的问题。

改进后的代码：

    TapHandler {
        id: tapHandler
        // 只接受鼠标左键和右键（触摸屏的Tap不依赖button，会被自动识别）
        acceptedButtons: Qt.LeftButton | Qt.RightButton 
        
        onTapped: function (eventPoint, button) {
            // 1. 处理鼠标左键 或 触摸屏点击
            if (button === Qt.LeftButton || eventPoint.device === PointerDevice.TouchScreen) {
                Applet.openWorkspace()
                toolTip.close()
            } 
            // 2. 如果需要保留右键菜单功能，不应该在这里拦截右键
            // 如果确定不需要右键菜单，当前逻辑是安全的；否则需要移除 Qt.RightButton
        }
    }

如果你坚决需要隔离鼠标和触摸屏的逻辑（例如触摸屏需要特殊防抖处理），改进后的双Handler代码应为：

    TapHandler {
        id: mouseTapHandler
        acceptedDevices: PointerDevice.Mouse | PointerDevice.TouchPad // 明确只接受鼠标/触控板
        acceptedButtons: Qt.LeftButton // 只接受左键，右键事件放行给其他组件（如菜单）
        
        onTapped: function (eventPoint, button) {
            if (button === Qt.LeftButton) {
                Applet.openWorkspace()
                toolTip.close()
            }
        }
    }

    TapHandler {
        id: touchTapHandler
        acceptedDevices: PointerDevice.TouchScreen // 明确只接受触摸屏
        // 触摸屏Tap不需要判断button
        
        onTapped: function (eventPoint, button) {
            Applet.openWorkspace()
            toolTip.close()
        }
    }

总结： 最推荐第一种（单Handler）方案，它更简洁、性能更好，且避免了事件吞没的问题。请根据你的实际业务需求（特别是右键菜单是否需要存在）调整 acceptedButtons。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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