Skip to content

fix: fix touchscreen drag issue with hidden items#707

Merged
18202781743 merged 1 commit intolinuxdeepin:masterfrom
18202781743:master
Mar 2, 2026
Merged

fix: fix touchscreen drag issue with hidden items#707
18202781743 merged 1 commit intolinuxdeepin:masterfrom
18202781743:master

Conversation

@18202781743
Copy link
Contributor

@18202781743 18202781743 commented Feb 12, 2026

  1. Changed visibility control from visible property to opacity
    property in AppListView.qml and FreeSortListView.qml
  2. This prevents drag interruption when items are hidden during drag
    operations
  3. The issue occurred because setting visible: false during drag would
    interrupt the drag gesture on touchscreens
  4. Using opacity instead maintains the visual hiding effect while
    keeping the item technically visible to the touch system

Log: Fixed touchscreen drag issue where dragging would abnormally
interrupt when items were hidden

Influence:

  1. Test touchscreen drag operations on both app list and free sort views
  2. Verify that dragging items no longer interrupts when items become
    hidden
  3. Check that visual appearance during drag is correct (items should be
    invisible but not disrupt drag)
  4. Test mouse drag operations to ensure they still work correctly
  5. Verify that tooltips and other interactive features still function
    properly

fix: 修复触摸屏拖拽时隐藏项导致的问题

  1. 在 AppListView.qml 和 FreeSortListView.qml 中将可见性控制从 visible
    属性改为 opacity 属性
  2. 这防止了在拖拽操作期间隐藏项目时拖拽被中断的问题
  3. 问题发生在拖拽过程中设置 visible: false 会中断触摸屏上的拖拽手势
  4. 使用透明度替代可以保持视觉隐藏效果,同时让项目在触摸系统中保持技术上
    的可见性

Log: 修复了触摸屏拖拽问题,当项目隐藏时拖拽不再异常中断

Influence:

  1. 测试应用列表和自由排序视图上的触摸屏拖拽操作
  2. 验证拖拽项目时不再因项目隐藏而中断
  3. 检查拖拽期间的视觉外观是否正确(项目应不可见但不中断拖拽)
  4. 测试鼠标拖拽操作确保仍能正常工作
  5. 验证工具提示和其他交互功能是否仍能正常使用

PMS: BUG-346077

Summary by Sourcery

Bug Fixes:

  • Ensure list items remain draggable on touchscreens even when visually hidden during drag operations in AppListView and FreeSortListView.

@sourcery-ai
Copy link

sourcery-ai bot commented Feb 12, 2026

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Replaces visibility toggling with opacity changes for list item labels during drag operations in touchscreen contexts to prevent drag interruption while preserving the visual hiding behavior and existing interactions.

Sequence diagram for touchscreen drag interaction with opacity-based hiding

sequenceDiagram
    actor User
    participant Touchscreen
    participant AppListView
    participant ListItem
    participant DragHandler

    User->>Touchscreen: touchDown on list item
    Touchscreen->>AppListView: emitPressEvent
    AppListView->>ListItem: startDrag
    ListItem->>DragHandler: Drag.active = true

    Note over ListItem,DragHandler: New behavior using opacity
    DragHandler->>ListItem: updateDragState
    ListItem->>ListItem: set opacity = 0 (item visually hidden)
    Touchscreen->>DragHandler: continueDragEvents
    DragHandler->>AppListView: updateItemPosition

    User-->>Touchscreen: touchMove continues
    Touchscreen->>DragHandler: dragMove events uninterrupted

    User-->>Touchscreen: touchRelease
    Touchscreen->>DragHandler: dragEnd
    DragHandler->>ListItem: Drag.active = false
    ListItem->>ListItem: set opacity = 1 (item visible)

    Note over Touchscreen,DragHandler: Drag gesture remains active because item stays visible to input system
Loading

File-Level Changes

Change Details Files
Switch label hiding during drag from the visible property to opacity so touch drags are not interrupted while items appear hidden.
  • In the app list item delegate, replace visible: !Drag.active with opacity: !Drag.active ? 1 : 0 to keep the label logically present but visually hidden while dragging.
  • In the free-sort list item delegate, replace the combined visible condition with an equivalent opacity expression, preserving the existing conditions for when the label should appear while avoiding touch gesture cancellation.
qml/windowed/AppListView.qml
qml/windowed/FreeSortListView.qml

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

Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've left some high level feedback:

  • Switching from visible to opacity means these controls are still hit-testable when fully transparent; consider explicitly tying enabled/hoverEnabled (and tooltip activation if needed) to the same condition so invisible labels don’t unexpectedly receive input.
  • The previous visible: false also removed these items from layout/size calculations, while opacity: 0 does not; double-check any anchoring or implicit size dependencies and, if necessary, gate layout-affecting properties (like Layout.* or implicitHeight) on the same condition used for opacity.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Switching from `visible` to `opacity` means these controls are still hit-testable when fully transparent; consider explicitly tying `enabled`/`hoverEnabled` (and tooltip activation if needed) to the same condition so invisible labels don’t unexpectedly receive input.
- The previous `visible: false` also removed these items from layout/size calculations, while `opacity: 0` does not; double-check any anchoring or implicit size dependencies and, if necessary, gate layout-affecting properties (like `Layout.*` or `implicitHeight`) on the same condition used for opacity.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@deepin-bot
Copy link

deepin-bot bot commented Feb 27, 2026

TAG Bot

New tag: 2.0.27
DISTRIBUTION: unstable
Suggest: synchronizing this PR through rebase #714

@deepin-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

1. Changed visibility control from `visible` property to `opacity`
property in AppListView.qml and FreeSortListView.qml
2. This prevents drag interruption when items are hidden during drag
operations
3. The issue occurred because setting `visible: false` during drag would
interrupt the drag gesture on touchscreens
4. Using opacity instead maintains the visual hiding effect while
keeping the item technically visible to the touch system

Log: Fixed touchscreen drag issue where dragging would abnormally
interrupt when items were hidden

Influence:
1. Test touchscreen drag operations on both app list and free sort views
2. Verify that dragging items no longer interrupts when items become
hidden
3. Check that visual appearance during drag is correct (items should be
invisible but not disrupt drag)
4. Test mouse drag operations to ensure they still work correctly
5. Verify that tooltips and other interactive features still function
properly

fix: 修复触摸屏拖拽时隐藏项导致的问题

1. 在 AppListView.qml 和 FreeSortListView.qml 中将可见性控制从 `visible`
属性改为 `opacity` 属性
2. 这防止了在拖拽操作期间隐藏项目时拖拽被中断的问题
3. 问题发生在拖拽过程中设置 `visible: false` 会中断触摸屏上的拖拽手势
4. 使用透明度替代可以保持视觉隐藏效果,同时让项目在触摸系统中保持技术上
的可见性

Log: 修复了触摸屏拖拽问题,当项目隐藏时拖拽不再异常中断

Influence:
1. 测试应用列表和自由排序视图上的触摸屏拖拽操作
2. 验证拖拽项目时不再因项目隐藏而中断
3. 检查拖拽期间的视觉外观是否正确(项目应不可见但不中断拖拽)
4. 测试鼠标拖拽操作确保仍能正常工作
5. 验证工具提示和其他交互功能是否仍能正常使用

PMS: BUG-346077
@deepin-ci-robot
Copy link

deepin pr auto review

这份代码修改主要涉及两个 QML 文件:AppListView.qmlFreeSortListView.qml。修改的核心逻辑是将拖拽过程中隐藏元素的属性从 visible: false 改为 opacity: 0

以下是对这段 Diff 的详细审查和改进意见:

1. 语法逻辑审查

  • 版权年份更新:两个文件均更新了 SPDX-FileCopyrightText 中的年份范围(2023 -> 2023-2026,2024 -> 2024-2026),这是符合常规做法的。
  • 属性变更逻辑:代码将 visible: !Drag.active(或类似逻辑)修改为 opacity: ... ? 1 : 0
    • 从语法上看,这是合法的 QML 属性绑定。
    • 逻辑意图是:当项目被拖拽时,不直接将其从布局中移除(visible: false),而是使其透明(opacity: 0)。

2. 代码质量审查

  • 改进点:保留布局空间
    • 原代码 (visible: false):当 Drag.active 为真时,元素被隐藏。在 QML 的布局系统(如 ListViewRowColumnFlow)中,visible: false 通常会导致该元素不占用布局空间。这会导致列表中的其他元素发生位移("跳动"),填补被拖拽元素留下的空缺。这在拖拽操作中通常是不希望看到的,因为这会破坏用户对"原位置"的视觉记忆。
    • 新代码 (opacity: 0):当 Drag.active 为真时,元素变为完全透明,但仍然占用布局空间。这意味着列表中的其他元素不会移动,原位置保持为一个"空槽"。这通常是拖拽排序(Drag and Drop)功能中更优的交互体验,视觉上更稳定。
  • 潜在问题:鼠标事件穿透
    • opacity 设置为 0 时,元素在视觉上不可见。根据 QML 的默认行为,opacity 为 0 的元素通常不再接收鼠标事件(鼠标事件会穿透到下层元素)。
    • 风险:如果这个透明元素下方有其他可交互元素,且用户在拖拽过程中鼠标意外移动到该位置,可能会触发下层元素的事件。
    • 建议:如果这个透明元素在拖拽过程中需要作为"放置目标"(Drop Target)来接收鼠标释放事件,仅仅设置 opacity: 0 可能不够。但在常规的拖拽实现中,拖拽代理(Drag Image)通常跟随鼠标,原位置的透明元素主要用于占位,因此通常不需要接收鼠标事件。目前的修改在大多数场景下是安全的。

3. 代码性能审查

  • 渲染性能
    • visible: false 会完全跳过元素的渲染管线,性能开销最小。
    • opacity: 0 仍然会进行渲染计算(尽管最终不可见),会有轻微的 GPU 开销。
    • 结论:对于应用列表这种轻量级 UI,这种性能差异完全可以忽略不计。为了更好的交互效果(避免跳动),牺牲这一点点是值得的。
  • 布局计算
    • 由于元素仍然占据布局空间,布局引擎不需要重新计算周围元素的位置。在某些情况下,这反而比 visible 变化引起的布局重排更高效。

4. 代码安全审查

  • 安全性:此修改仅涉及 UI 表现层,不涉及数据处理、权限控制或网络通信,因此没有明显的安全风险。

5. 综合改进建议

虽然目前的修改解决了"跳动"问题,但为了代码的健壮性,可以考虑以下微调:

建议:显式禁用透明状态下的交互
如果为了防止极少数情况下的鼠标事件穿透干扰,或者为了明确表达"此元素当前不可交互"的意图,可以在 opacity 变化的同时,控制 enabled 属性。

修改后的代码示例(以 AppListView.qml 为例):

// 原代码
// visible: !Drag.active

// 建议改进代码
enabled: !Drag.active  // 拖拽时禁用交互,防止意外触发
opacity: !Drag.active ? 1 : 0 // 拖拽时透明,保留布局空间

总结:
这是一个优秀的修改。它通过将 visible 改为 opacity,成功解决了拖拽过程中列表元素跳动的问题,提供了更平滑的用户体验。只要确认不需要在该透明元素上处理鼠标事件,目前的实现是完全可行的。显式添加 enabled: !Drag.active 可以使代码意图更加清晰,但不是必须的。

@18202781743 18202781743 merged commit f575fcc into linuxdeepin:master Mar 2, 2026
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants